Continuous Access Evaluation (CAE) doesn't seem to be working for device code flow

[baywet]

Hi from the Microsoft Graph SDKs team 👋

We're in the process of implementing CAE in our SDKs, which rely on Azure identity.

First, the GetTokenOptions interface doesn't expose a "claims" property, when the dotnet equivalent does as well as the Java equivalent. This is a limitation for us as we're only taking a dependency on core-auth in an effort to release only as often as needed and to give more control to customers over which azure-identity version they want to use. It's only defined in CredentialFlowGetTokenOptions which as far as I understand is only meant to be used by azure identity to interface with MSAL.

Now, if we force set the claim by doing something like (options as any).claims = claimsValue; the client with a device code flow still doesn't get a new challenge prompt when the session is revoked.

As per the claims value, from reading the code I understood the claims value expects the JSON representation (base64 decode the claim value from the response header, but do not JSON parse it).

Here are my questions:

• Can you confirm CAE with device code flow works with this JS lib? (it does for Java and dotnet)
• Can you confirm we're passing the right value? (base64 decoded, but not JSON parsed)
• Could you move the claims property to the GetTokenOptions interface?
• Could you validate the following repro is correctly configured?

const getClaimsFromResponse = (response: Response ) => {
  if (response.status === 401) {
    const rawAuthenticateHeader = response.headers.get("WWW-Authenticate");
    if (rawAuthenticateHeader && /^Bearer /gi.test(rawAuthenticateHeader)) {
	const rawParameters = rawAuthenticateHeader.replace(/^Bearer /gi, "").split(",");
	for (const rawParameter of rawParameters) {
		const trimmedParameter = rawParameter.trim();
		if (/claims="[^"]+"/gi.test(trimmedParameter)) {
			return trimmedParameter.replace(/claims="([^"]+)"/gi, "$1");
		}
	}
     }
   }
  return undefined;
};
const tokenCredentials = new DeviceCodeCredential(
{
  tenantId: '<tid>',
  clientId: '<cid>',
  userPromptCallback: (info) => console.log(info.message),
});
let previousClaims: string | undefined = undefined;
while(true) {
      const token = await tokenCredentials.getToken(["User.Read"], {claims: (previousClaims ? Buffer.from(previousClaims, "base64").toString(): undefined)} as any as GetTokenOptions)
      const previousResponse = await fetch("https://graph.microsoft.com/v1.0/me", {headers: {Authorization: `Bearer ${token.token}`}});
      previousClaims = getClaimsFromResponse(previousResponse);
      console.log("result", await previousResponse.text());
      await new Promise(resolve => setTimeout(resolve, 10000));
    }

[azure-sdk]

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Azure.Core:0.47996175,Azure.Identity:0.2467415,IoT:0.03852034'

[jeremymeng]

The identity doc seems to suggest to base64-decode the claims from the response, url-encode it then add it to the claims parameter of the authorization request

[jeremymeng]

I think it makes sense to have claims on GetTokenOptions for consistency with other languages. @KarishmaGhiya @mpodwysocki

[baywet]

Thanks for the reply @jeremymeng After adding encodeURIComponent (after the base64 decode), this is still not working as expected.
I also added setLogLevel("info"); to get a better understanding of what's happening, and it seems the library is ignoring the claims property all together. Here are the logs

claims: eyJhY2Nlc3NfdG9rZW4iOnsibmCHANGEDAFEWCCHARACTERS2VudGlhbCI6dHJ1ZSwgInZhbHVlIjoiMTY1MzQ4NTQ0OSJ9fX0=
azure:identity:info DeviceCodeCredential => Attempting to acquire token silently
azure:identity:info DeviceCodeCredential => getToken() => SUCCESS. Scopes: User.Read.
result {"error":{"code":"InvalidAuthenticationToken","message":"Continuous access evaluation resulted in claims challenge with result: InteractionRequired and code: TokenIssuedBeforeRevocationTimestamp","innerError":{"date":"2022-05-25T13:30:59","request-id":"b61f7ba2-8ded-4666-8a55-aaf3ee9cd577","client-request-id":"b61f7ba2-8ded-4666-8a55-aaf3ee9cd577"}}}

I'd expect Azure Identity to either fail on the silent token acquisition and fallback on a full acquisition using the claims, or for it to "see the claims" and start a full acquisition from the get go.

[baywet]

after some more investigation I can confirm that the claims goes all the way here, but msal replies with the same access token that it already returned, from the cache.

azure-sdk-for-js/sdk/identity/identity/src/msal/nodeFlows/msalNodeCommon.ts

Line 278 in dd0b9d9

this.logger.info("Attempting to acquire token silently");

[baywet]

After more investigation, azure identity 2.0.4 (current version at the time of writing) uses msal node 1.3.0

MSAL node 1.7.0 has a bugfix specific to claims and tokens caching.

For sanity, the dependency should be updated on the next patch/minor.

Also the claims need to be base64 decoded but not URI encoded, MSAL does the latter part for you.

[xirzec]

After more investigation, azure identity 2.0.4 (current version at the time of writing) uses msal node 1.3.0

Since we depend on ^1.3.0, which is compatible with 1.8.0, we actually do use 1.8.0 currently:

azure-sdk-for-js/common/config/rush/pnpm-lock.yaml

Line 1009 in f5de119

'@azure/msal-node': 1.8.0

We could still bump up the minimum version to be higher in order to force folks to get the bugfix, though. @KarishmaGhiya can you take care of this?

I'm a bit confused about the scenario here, since I believe we handle CAE challenges in a pipeline policy rather than in the token credentials individually: https://github.com/Azure/azure-sdk-for-js/blob/c76126f3dac544df9c2801b67cbdae64aa18b647/sdk/core/core-client/src/authorizeRequestOnClaimChallenge.ts

[baywet]

The Microsoft graph sdks are not using the same http pipeline azure sdks are. They are however using the same authentification layer.

[xirzec]

The Microsoft graph sdks are not using the same http pipeline azure sdks are.

Would you be willing to try it out? You can configure your own pipeline with all custom policies or pick and choose which of our policies make sense for you.

[baywet]

That original decision predates my time on the team. I believe @darrelmiller had conversations with your architects at the time.

[KarishmaGhiya]

@baywet We will be releasing a new GA 2.1.0 for Identity within the next two weeks, which will have dependency on the latest version of MSAL node. Would that work for you or would you prefer a bug fix for 2.0.x version instead?

[baywet]

@KarishmaGhiya thanks for the follow up. This would be enough for us, no need for an intermediate release.

[KarishmaGhiya]

@baywet Heads up! Our GA 2.1.0 has been delayed to July. Let me know if you have any questions/ concerns.

[KarishmaGhiya]

@baywet We have released our GA 2.1.0 - https://www.npmjs.com/package/@azure/identity

Let me know if this solves your issue or if you have any questions/ concerns.

[baywet]

Thanks for the follow up. Nothing else required from our side. Closing