Wire ClientDataInfo through AcquireTokenResult, Fixes AB#3604499#3109
Conversation
|
❌ Work item link check failed. Description does not contain AB#{ID}. Click here to Learn more. |
There was a problem hiding this comment.
Pull request overview
Propagates ClientDataInfo (parsed from x-ms-clientdata response header and clientdata redirect query parameter) through the Common auth result pipeline so callers can access server-side telemetry context via AcquireTokenResult.
Changes:
- Added
ClientDataInfoplumbing toTokenResult,MicrosoftStsAuthorizationResult, andAcquireTokenResult. - Wired
clientdataparsing results intoMicrosoftStsAuthorizationResultFactory(/authorize redirect parsing) andAbstractMicrosoftStsTokenResponseHandler(/token header parsing). - Propagated
ClientDataInfofrom authorization/token results intoAcquireTokenResultin controllers (preferring the token endpoint value when present).
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| common4j/src/main/com/microsoft/identity/common/java/result/AcquireTokenResult.java | Adds nullable ClientDataInfo accessor/mutator to expose server-side telemetry to callers. |
| common4j/src/main/com/microsoft/identity/common/java/providers/oauth2/TokenResult.java | Stores nullable ClientDataInfo parsed from x-ms-clientdata on token responses. |
| common4j/src/main/com/microsoft/identity/common/java/providers/microsoft/microsoftsts/MicrosoftStsAuthorizationResultFactory.java | Captures clientdata redirect param into MicrosoftStsAuthorizationResult. |
| common4j/src/main/com/microsoft/identity/common/java/providers/microsoft/microsoftsts/MicrosoftStsAuthorizationResult.java | Adds nullable ClientDataInfo storage on authorization results. |
| common4j/src/main/com/microsoft/identity/common/java/providers/microsoft/microsoftsts/AbstractMicrosoftStsTokenResponseHandler.java | Sets ClientDataInfo onto TokenResult when header is present/parseable (behind flight). |
| common4j/src/main/com/microsoft/identity/common/java/controllers/BaseController.java | Copies TokenResult.getClientDataInfo() into AcquireTokenResult for ROPC/silent flows. |
| common/src/main/java/com/microsoft/identity/common/internal/controllers/LocalMSALController.java | Wires ClientDataInfo from authorize result, then prefers token endpoint value when available. |
Comments suppressed due to low confidence (1)
common4j/src/main/com/microsoft/identity/common/java/providers/microsoft/microsoftsts/MicrosoftStsAuthorizationResultFactory.java:84
- Test coverage:
parseRedirectUriAndCreateAuthorizationResult()now attachesClientDataInfoto the returnedMicrosoftStsAuthorizationResult(result.setClientDataInfo(clientDataInfo)). The existing factory tests validate span attributes but don’t assert that the parsed data is actually accessible on the result object. Add an assertion (casting toMicrosoftStsAuthorizationResult) thatgetClientDataInfo()is populated with the expected fields when theclientdataquery parameter is present (and null when absent/flight disabled).
ClientDataInfo clientDataInfo = null;
if (CommonFlightsManager.INSTANCE.getFlightsProvider().isFlightEnabled(CommonFlight.ENABLE_SERVER_CLIENT_DATA_TELEMETRY)) {
clientDataInfo = ClientDataInfo.fromPipeDelimited(urlParameters.get(ClientDataInfo.CLIENTDATA_QUERY_PARAMETER));
if (null != clientDataInfo) {
clientDataInfo.emitToSpan();
}
}
dc89211 to
d3c256a
Compare
|
✅ Work item link check complete. Description contains link AB#3604499 to an Azure Boards work item. |
|
❌ Work item link check failed. Description contains AB#3604499 but the Bot could not link it to an Azure Boards work item. Click here to learn more. |
1677007 to
fdae003
Compare
Propagate ClientDataInfo (parsed from the x-ms-clientdata token response header and the clientdata authorize redirect query parameter) through AcquireTokenResult on success paths and through BaseException on failure paths. Includes broker IPC serialization via BrokerResult so the payload reaches the MSAL caller process for both success and error responses. Adds a raw field to ClientDataInfo preserving the original pipe-delimited string for partner teams that want the unparsed payload. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
fdae003 to
694037f
Compare
| ); | ||
| } | ||
|
|
||
| result.setClientDataInfo(clientDataInfo); |
There was a problem hiding this comment.
Good catch — while clientDataInfo is always null when the flight is disabled (making the unconditional call semantically a no-op), it was misleading. Fixed in f849f51 by wrapping the setClientDataInfo call in a null != clientDataInfo guard, so it's only invoked when the flight is enabled and parsing actually succeeded.
…cationResult LocalAuthenticationResult is the single canonical owner of ClientDataInfo (it's the only result type that survives the broker IPC boundary). Remove the redundant mClientDataInfo field/setter from AcquireTokenResult; getClientDataInfo() now delegates to the underlying LocalAuthenticationResult. Update controllers (LocalMSALController, BaseController) and MsalBrokerResultAdapter to write CDI directly to LocalAuthenticationResult, sourcing it from TokenResult (preferred) with fallback to MicrosoftStsAuthorizationResult. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Resolve in order: LocalAuthenticationResult -> TokenResult -> MicrosoftStsAuthorizationResult. This ensures callers can retrieve CDI even on failure paths where LocalAuthenticationResult was never constructed (e.g., token-error or authorize-error responses). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| ); | ||
| } | ||
|
|
||
| result.setClientDataInfo(clientDataInfo); |
There was a problem hiding this comment.
@copilot in this case, ClientDataInfo should not be attached
There was a problem hiding this comment.
Fixed in accc218. ClientDataInfo is now only attached to the result when AuthorizationStatus.SUCCESS — i.e., after state validation passes. For state-mismatch (potential CSRF redirects), it is discarded. Also added two unit tests covering both cases: testClientDataParam_stateMismatch_clientDataInfoNotAttached and testClientDataParam_validState_clientDataInfoAttached.
There was a problem hiding this comment.
@copilot nope, we shouldn't limit it based on authorizationstatus being SUCCESS. if it is a failure we especially want the clientDataInfo, but only if it's coming from a trusted source
There was a problem hiding this comment.
Fixed in f3c3f0b. The guard now excludes only state-mismatch errors specifically (CSRF protection), allowing ClientDataInfo to be attached for all other results including server-error redirects (FAIL with errors like access_denied, login_required, etc.). Added a testClientDataParam_serverError_clientDataInfoAttached test to verify this.
… server-error test Agent-Logs-Url: https://github.com/AzureAD/microsoft-authentication-library-common-for-android/sessions/ce73c752-627d-482f-bf86-4d43eb172fad Co-authored-by: fadidurah <88730756+fadidurah@users.noreply.github.com>
…ng pattern Agent-Logs-Url: https://github.com/AzureAD/microsoft-authentication-library-common-for-android/sessions/ce73c752-627d-482f-bf86-4d43eb172fad Co-authored-by: fadidurah <88730756+fadidurah@users.noreply.github.com>
|
Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
…tion-library-common-for-android into fadi/wire-clientdata-to-acquiretokenresult
When configure-on-demand is enabled, Gradle only configures the projects that are actually in the dependency graph of the requested tasks. Previously building AADAuthenticator triggered configure of broker4j, brokerHost, java-linux-test-app, LinuxBroker, brokerautomationapp etc. — none of which are needed for AADAuthenticator:assembleDistRelease. Logs showed ~16 min spent in unnecessary configure phases. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
@copilot there's a merge conflict in dev, please fix it |
…resolve conflicts keeping both ClientDataInfo IPC and onboarding blob changes Co-authored-by: fadidurah <88730756+fadidurah@users.noreply.github.com>
Resolved in 331dc0c. Four files had conflicts:
|
|
@copilot what's the current status? seems you got stuck |
|
@copilot make sure all of the additions in this PR are gated behind the flight ENABLE_SERVER_CLIENT_DATA_TELEMETRY |
…TELEMETRY flight Agent-Logs-Url: https://github.com/AzureAD/microsoft-authentication-library-common-for-android/sessions/22fcd36c-3156-4450-b90e-9bf04390f62b Co-authored-by: fadidurah <88730756+fadidurah@users.noreply.github.com>
…-guard in LocalMSALController else-if branch Agent-Logs-Url: https://github.com/AzureAD/microsoft-authentication-library-common-for-android/sessions/22fcd36c-3156-4450-b90e-9bf04390f62b Co-authored-by: fadidurah <88730756+fadidurah@users.noreply.github.com>
Done in d0f38bf. All
The parsing entry points ( |
…, Fixes AB#3604499 (#3118) Cherry-picks #3109 (squash commit `26de108`) onto `working/release/24.2.1` for the 24.2.1 hotfix. Propagates the parsed `x-ms-clientdata` (token endpoint) and `clientdata` query parameter (authorize endpoint) data from the response handlers through `TokenResult`, `MicrosoftStsAuthorizationResult`, and ultimately onto `AcquireTokenResult` so callers can access server-side telemetry (error, sub-error, account type, cloud instance, data boundary). All propagation is gated behind the `ENABLE_SERVER_CLIENT_DATA_TELEMETRY` flight. ### Conflict resolution notes The hotfix branch does not contain the onboarding-blob feature (PR #3088 / #3111) that landed on `dev` alongside #3109. To keep this hotfix scoped to ClientDataInfo only, the following PR-side additions were dropped during cherry-pick: - `BrokerResult.ONBOARDING_BLOB` constant (kept only `CLIENT_DATA_INFO`) - `MsalBrokerResultAdapterTests.testOnboardingBlob_*` tests - `AcquireTokenResultTest.onboardingBlob_*` tests - Other `vNext` changelog entries unrelated to #3109 All `ClientDataInfo` plumbing from #3109 is preserved unchanged. [AB#3604499](https://identitydivision.visualstudio.com/fac9d424-53d2-45c0-91b5-ef6ba7a6bf26/_workitems/edit/3604499) --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Propagate the parsed x-ms-clientdata (token endpoint) and clientdata query parameter (authorize endpoint) data from the response handlers through TokenResult, MicrosoftStsAuthorizationResult, and ultimately onto AcquireTokenResult so callers can access server-side telemetry (error, sub-error, account type, cloud instance, data boundary).
AB#3604499