[Feature Request] MSAL libraries provide routing information to CCS

[henrik-me]

Feature 1333541: [MSAL.NET] MSAL libraries provide routing information to CCS

CCS MSAL routing hint one pager - info available in epic

Stories:

• ROPC and IWA - send username [M]
• AcquireTokenSilent - send client_info [S]
• AcquireTokenInteractive - send login_hint [S]
• Expose a WithExtraHttpHeaders(IDictionary<string, string>) that allows confidential clients to send client_info for AcquireTokenByAuthorizationCode and OBO [M]
• MS Id web work [S] to use WithExtraHttpHeaders - included in 1.14 release
• Confirm that headers sent are in the right format etc.
• Make sure to cover B2C and ADFS in E2E testing.

[bgavrilMS]

The gist of it is to add 2 headers:

X-AnchorMailbox:”Oid:<userObjectId>@<userTenantID>” or X-AnchorMailbox: “UPN: <userUpn>”

We need to understand

• What auth flows should this cover? A: all of them, best effort.
• Token endpoint and authorize endpoint ? How can CCS cache the authorization code, as it is protected by PKCE and cannot be redeemed multiple times? A: it doesn't. a code from CCS is not useable on ESTS or the other way around.
• Client credentials flow (daemon scenario) ? What should we send? We don't have OID, only tenant ID if the user didn't use common A: nothing.
• How can we test this feature? A: contact CCS team who can validate via telemetry.

[jennyf19]

• going to the /authorize endpoint for this doesn't make sense. We can't store the auth code, not only because of PKCE, but also because it has state, so holding for a period of time will make the auth code unusable. Also, we don't have that information about the signed in user at that point.. so only makes sense on the /token endpoint.

A: it's fine, request will still be routed correctly, but it will take a bit longer.

• also, privacy concerns w/sending the UPN on the header?

A: I would say no, because they are encrypted by SSL and the username is anyway included in the payload (e.g. login_hint), but we can check with Privacy experts.

• Does B2C support this or be impacted by the extra header info?

A: not currently supported, but may be in the future.

• I would think the spec writers would need to come up w/the s2s scenarios, as there is no user, as you mention.

A: not supported.

[bgavrilMS]

We can split this as follows:

Public Client	AcquireTokenInteractive	/authorize request and authorization_code grant	cache?	Can send the login_hint as UPN if the user configures it (not a common scenario)
	AcquireTokenByUsernamePassword	password	no	Can send the username as UPN
	AcquireTokenByIntegratedWindowsAuth	urn:oasis:names:tc:SAML:1.0:assertion	no	MSAL detects the current Windows user. Can send that as UPN.
	AcquireTokenByDeviceCode	device_code	no	Cannot send anything.
	AcquireTokenSilent	refresh_token	yes	Can send oid@tenant_id
Confidential Client	AcquireTokenByAuthorizationCode	authorization_code	no	Cannot send anything*
	AcquireTokenForClient	client_credentials	yes	No UPN exists and oid is not known, since we don't have ID Token. Do you want MSAL to send smth else?
	AcquireTokenOnBehalfOf	urn:ietf:params:oauth:grant-type:jwt-bearer	yes	Can likely send oid@tenand_id

[trwalke]

Waiting for CCS to provide test environment

[trwalke]

Adding CCS routing info to /token endpoint after acquiring client info from the /authorize endpoint during auth code flow

[trwalke]

Tested end to end and it works as expected.
Documentation
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/CCS-Routing-Hint