Add OpenTelemetry support for passkey operations, Fixes AB#3412004

[p3dr0rv]

This pull request introduces OpenTelemetry tracing to the passkey (WebAuthN) flow, ensuring that all interactions with the JavaScript reply channel and WebView client are properly traced for observability. It also refactors error handling in the passkey reply channel to use exceptions rather than plain strings, and propagates the tracing context (SpanContext) throughout the relevant classes. Additionally, the pull request cleans up and simplifies some internal logic and improves test coverage.

AB#3412004

[Copilot]

Pull Request Overview

This PR adds telemetry instrumentation to the Passkey/WebAuthn authentication flow and improves code organization by caching span context in the WebView client.

Key changes:

• Added telemetry support with new span name (PasskeyWebListener) and attributes (passkey_operation_type, passkey_dom_exception_name)
• Refactored AzureActiveDirectoryWebViewClient to cache SpanContext as a field, eliminating repeated conditional checks
• Enhanced error handling in passkey flows with new ClientException error codes (UNSUPPORTED_OPERATION, REQUEST_IN_PROGRESS)

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 15 comments.

Show a summary per file

File	Description
common4j/src/main/com/microsoft/identity/common/java/opentelemetry/SpanName.java	Added PasskeyWebListener enum value for passkey operation telemetry spans
common4j/src/main/com/microsoft/identity/common/java/opentelemetry/AttributeName.java	Added passkey_operation_type and passkey_dom_exception_name attributes for passkey telemetry classification
common4j/src/main/com/microsoft/identity/common/java/exception/ClientException.java	Added UNSUPPORTED_OPERATION and REQUEST_IN_PROGRESS error code constants for passkey validation
common/src/main/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClient.java	Cached SpanContext as field mSpanContext and added getter; refactored span creation methods to use cached context instead of repeated conditional checks
common/src/main/java/com/microsoft/identity/common/internal/providers/oauth2/PasskeyWebListener.kt	Added spanContext parameter and propagated it to PasskeyReplyChannel instances; replaced string error messages with structured ClientException instances
common/src/main/java/com/microsoft/identity/common/internal/providers/oauth2/PasskeyReplyChannel.kt	Added spanContext parameter; instrumented postSuccess() and postError() with telemetry spans, attributes, and status codes; removed separate send() method by inlining span logic
common/src/test/java/com/microsoft/identity/common/internal/providers/oauth2/PasskeyReplyChannelTest.kt	Updated test to handle postError() signature change (now accepts Throwable instead of String); added test coverage for Get* credential exception types; improved test naming for clarity

Comments suppressed due to low confidence (1)

common/src/test/java/com/microsoft/identity/common/internal/providers/oauth2/PasskeyReplyChannelTest.kt:304

• Missing test coverage for telemetry span creation and attribute setting in PasskeyReplyChannel. The PR adds telemetry instrumentation to postSuccess() and postError() methods (creating spans, setting attributes, recording status), but the existing tests don't verify any of this telemetry behavior.

Issue: The tests at lines 58-304 verify message formatting and exception handling but don't check:

1. Whether spans are created with the correct name (SpanName.PasskeyWebListener)
2. Whether passkey_operation_type attribute is set correctly
3. Whether passkey_dom_exception_name attribute is set for errors
4. Whether span status is set to OK for success or ERROR for failures
5. Whether spans are properly ended

Impact: Telemetry regressions could go undetected, impacting observability and debugging capabilities.

Recommendation: Add test cases that mock the telemetry infrastructure to verify:

• Span creation with parent context
• Attribute setting with correct values
• Status code setting (OK/ERROR)
• Exception recording
• Span ending in all code paths

Example test structure:

@Test
fun `postSuccess sets telemetry attributes correctly`() {
    // Mock OTelUtility and Span
    // Verify span created with PasskeyWebListener name
    // Verify passkey_operation_type attribute set
    // Verify StatusCode.OK set
    // Verify span.end() called
}

    @Test
    fun `send throws exception when postMessage fails`() {
        // Given
        val testJson = """{"key": "value"}"""
        val expectedException = RuntimeException("PostMessage failed")
        every { mockReplyProxy.postMessage(any<String>()) } throws expectedException

        // When/Then - Should throw the exception
        val thrownException = assertThrows(RuntimeException::class.java) {
            passkeyReplyChannel.postSuccess(testJson)
        }

        assertEquals("PostMessage failed", thrownException.message)
        verify { mockReplyProxy.postMessage(any<String>()) }
    }

[github-actions]

❌ Invalid work item number: AB#3412004
. Work item number must be a valid integer.

Click here to learn more.

[github-actions]

✅ Work item link check complete. Description contains link AB#3412004 to an Azure Boards work item.

[melissaahn]

Just to make sure, we should not expect to see the type be authentication until support is extended on the ESTS side to allow authentication, right? auth will be represented by the telemetry set for the legacy fido classes?

[p3dr0rv]

Yes, all operations should remain of type "registration" until ESTS decides to update their code to include authentication as well. At that point, a new type will be introduced. The idea of defining it now is simply to be prepared for when it’s needed. All authentication requests will continue to stay within the Fido span.