Any updates on when the amr claim will be available in v2.0?

[tom-fredricksonDM]

It looks like this has been brought up for awhile. #62154

I'm raising this issue again because in a few months it will affect any Azure instance that uses v2.0 SSO to log into Salesforce. Beginning February 1, 2022, Salesforce will require customers to use MFA in order to access Salesforce products. When logging in with SSO, Salesforce checks the headers of OpenID and SAML assertions for an attribute that shows that when the user logged into Azure, they used MFA. If they have, then Salesforce will not force them to go through a 2nd MFA check.

Is there an estimate on when the amr optional claim will be available for use? Or a workaround until it is available?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 2471c08b-befe-8e1a-df08-f13e116c231e
• Version Independent ID: 0d827d33-2906-6352-9398-13863def9354
• Content: Microsoft identity platform access tokens - Microsoft identity platform
• Content Source: articles/active-directory/develop/access-tokens.md
• Service: active-directory
• Sub-service: develop
• GitHub Login: @hpsin
• Microsoft Alias: hirsin

[shashishailaj]

@tom-fredricksonDM Thank you for bringing this to our notice. We will investigate and update the thread.

[vipulsparsh]

@tom-fredricksonDM Thanks for the feedback. We will engage the content development team for further investigation, they will verify and perform necessary changes in the document as needed.

[wealthz01]

🥺

On Thu, Dec 9, 2021 at 8:12 PM anaypurohit @.***> wrote:

IRT

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/azure-docs/issues/85021#issuecomment-990143789, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWIOIMQT2W5ATKGJ45PTUZ3UQD5Q5ANCNFSM5JU4L2GA .

[hpsin]

Salesforce can continue using the v1 token at this time to get this data - they should control their token format and associated validation. While we know this is a priority gap to fill, we don't have anything on the public roadmap to comment with at this time.

[nickludwig]

reassign:nickludwig

[nickludwig]

Closing due to no status change. Hirsch's previous message still applies. I'll re-open if necessary.

[nickludwig]

please-close

[onionhammer]

please-open ? :D

B2C doesnt appear to work with v1

[prmerger-automator[bot]]

Invalid command: '#please-open'. Only Microsoft employees can use this command.

[perttulaurila]

Any updates on this? Seems to have been in the backlog for a long while?

[onionhammer]

It's interesting support for this was removed then this comment was closed without referring us somewhere else or any explanation..

[nickludwig]

Hey folks, re-opening this.

This is definitely an ask we've heard frequently in the past. Our response so far has been that we suggest using acr, which is in v2.0 tokens. We feel that acr is more appropriate than amr for the majority of scenarios as, from what we've heard, folks typically care more about how secure the authentication (i.e., mfa, etc) and less about what method was used.

For example, for this issue specifically, Salesforce wants to be able to ensure that the user performed MFA when signing in. Instead of using amr and keeping track of all auth methods that qualify as MFA, they can use acr instead which explicitly tells them whether MFA was used or not.

If acr doesn't work for you, can I ask why? Curious to get some scenarios documented for why knowing the specific auth method is more valuable than knowing the security level of that auth method. More than happy to discuss this further

[nickludwig]

please-open

[perttulaurila]

Hi,

we would be interested in testing acr claim, but its values are not clear. The only information I can find is that the value is that "0" indicates the end-user authentication did not meet the requirements of ISO/IEC 29115.

https://github.com/uglide/azure-content/blob/master/articles/active-directory/active-directory-token-and-claims.md#id_tokens

Can you shed some more light what we can expect in there?

[nickludwig]

@perttulaurila - ah, I see. Yeah, that's pretty unclear. We definitely need to update the docs there. Thanks for pointing that out.

From my understanding, if the value of acr is... 0 -> then MFA wasn't used 1 -> MFA was used

We'd definitely like to add more values in the future for additional strengths such as "phishing resistant", etc. As for right now, however, acr only shows whether MFA was used or not.

[onionhammer]

@nickludwig

According to the docs, the acr is not available on id_tokens, only v1.0 access_tokens. acr being 1 or 0 would work fine for our usecase, but it's not available on the id_token.

https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#payload-claims

[nickludwig]

@onionhammer - right, neither acr nor amr is available for either v1 or v2 id_tokens. Can I ask, what scenario do you need these claims in id_tokens for?

As for v2.0 access tokens, acr is actually available in them but it's not explicitly documented in our optional claims documentation since it isn't exposed as one of the options listed in the Azure Portal. If you want acr to show up in v2.0 access tokens, you'll need to configure that via the application manifest. The optional claims doc provides guidance on how to configure optional claims via the application manifest. You'll want to use the same structure as what's mentioned there, which is:

When you find the optionalClaims object in the app manifest, set the accessToken optional claim array to this:

"optionalClaims": {
    "idToken": [],
    "accessToken": [
        {
            "name": "acr",
            "source": null,
            "essential": true,
            "additionalProperties": []
        }
    ],
    "saml2Token": []
},

[onionhammer]

@nickludwig

right, neither acr nor amr is available for either v1 or v2 id_tokens. Can I ask, what scenario do you need these claims in id_tokens for?

The id_token does contain amr here

The scenario we're trying to handle is essentially this one; we have a mandate to ensure every user coming through our IDP (we've gone with B2C) is using MFA, but we want federated users not to have double-mfa; so I've essentially followed the link (above) except that it doesn't work for v2.0.

So the way it would work is if the user is coming from an IDP that indicates the user has MFAd, we let them through, otherwise we force them to set up MFA for the internal B2C user account.

The claims that come from the TechnicalProfile that come back from federated AAD to B2C are from the id_token, not the access token.

[perttulaurila]

Our use case is with OIDC authentication from Ping Federate, which uses only the claims from the id token to evaluate the authentication. The access token is only used for querying the userinfo endpoint and we cannot evaluate the claims in it.

So we would like to have the acr and amr both available in V2.0 id tokens. Any other claims which would indicate the device security posture would be very interesting as well, for example something corresponding to the below SAML2 claims: http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant

Another question I have is would it be possible to have an application specific .well-known/openid-configuration metadata? At the moment this is generic to the tenant and does not list the additional claims configured for the application.

This results in confusion on what claims are actually available for each application, and forces us to manually align the claims between client and AAD.

[nickludwig]

The id_token does contain amr here

@onionhammer - apologies, I was mistaken. You're correct.

[nickludwig]

@onionhammer / @perttulaurila

Thanks for sharing the scenarios. This gives me some good context to bring back to folks on my end to discuss. Off the top of my head, I'm not aware of any plans to address this but I'm more than happy to double check. At the very least, I'll see if we can get an item created for this so we can add it to the list of things we consider when determining what gets funded/what doesn't. I'll circle back shortly.

[nickludwig]

Another question I have is would it be possible to have an application specific .well-known/openid-configuration metadata? At the moment this is generic to the tenant and does not list the additional claims configured for the application.

@perttulaurila - we've opted against doing something like this in the past given the OIDC metadata document is intended to the show configuration details of the identity provider, not specific applications. Supporting the ability to query application specific configuration details via the OIDC metadata document would be a non-standard addition. I think this is a discussion worth having, though, as we've heard similar asks from other customers. So, I'll see what I can find out.

[onionhammer]

@nickludwig

Thanks for sharing the scenarios. This gives me some good context to bring back to folks on my end to discuss. Off the top of my head, I'm not aware of any plans to address this but I'm more than happy to double check. At the very least, I'll see if we can get an item created for this so we can add it to the list of things we consider when determining what gets funded/what doesn't. I'll circle back shortly.

Thanks for raising it up. I would love to hear bright alternative ideas to this approach; for our scenario the only options I can think of are

A) Continue avoiding v2.0 B) Enforce MFA via legal contract for federated partners C) Federated users may get double-MFA, which would be a bad user experience

[perttulaurila]

Another question I have is would it be possible to have an application specific .well-known/openid-configuration metadata? At the moment this is generic to the tenant and does not list the additional claims configured for the application.

@perttulaurila - we've opted against doing something like this in the past given the OIDC metadata document is intended to the show configuration details of the identity provider, not specific applications. Supporting the ability to query application specific configuration details via the OIDC metadata document would be a non-standard addition. I think this is a discussion worth having, though, as we've heard similar asks from other customers. So, I'll see what I can find out.

In that case one possible solution would be to include also the optional claims in the claims_supported section of the metadata. This would help us, as then Ping Federate would pick them up and we would not need to manually configure them.

[nickludwig]

In that case one possible solution would be to include also the optional claims in the claims_supported section of the metadata.

@perttulaurila - as in listing all the potential optional claims that could be configured? or listing the optional claims which are configured for a given application?

[perttulaurila]

In that case one possible solution would be to include also the optional claims in the claims_supported section of the metadata.

@perttulaurila - as in listing all the potential optional claims that could be configured? or listing the optional claims which are configured for a given application?

The best solution would that the claims_supported would list claims that are configured to a given application.

However this would require that the .well-known/openid-configuration would be different for each application, and not generic to the tenant the way it is now.

If this is not possible, then listing all claims that could be configured would be an acceptable solution, and in line with the OpenID spec: "claims_supported: JSON array containing a list of the Claim Names of the Claims that the OpenID Provider MAY be able to supply values for. Note that for privacy or other reasons, this might not be an exhaustive list."

[kobynz]

I've been running into this issue and have been trying to figure it out for a while now. No matter what I do, I cannot seem to get any acr, amr, or related claims from the id tokens retrieved via the V2 endpoints. Even manually adding the acr optional claim via the manifest (as @nickludwig suggested) doesn't work for me.

It seems absurd to me that the Microsoft docs are pushing everyone to switch to V2, when basic functionality like this does not work yet. What's more frustrating, is the Microsoft.Identity.Web library I'm using actively tries to force me to use V2 authority endpoints, even when I explicitly set the Authority to the v1 endpoints (the source code shows this).

I have managed to finally get an MFA claim coming through, but I had to intercept the out-going request, and re-point it at the V1 endpoint (strip v2.0 from the ProtocolMessage.IssuerAddress). Then, and only then, I get some extra claims coming through. Including some keyed under http://schemas.microsoft.com/claims/authnmethodsreferences, one of which may contain "mfa".

This feels like a dirty hack, but I don't know about any other workarounds.

All I wanted was an acr claim in the id token. Why is that so hard?

[nickludwig]

Hey @NZKobra - Thanks for the feedback.

No matter what I do, I cannot seem to get any acr, amr, or related claims from the id tokens retrieved via the V2 endpoints.

Yeah, that's because neither amr nor acr are supported for v2 id_tokens. acr, however, is supported for v2 access tokens, which is what I was referring to above. Apologies for the confusion.

As for other potential workarounds which you and @onionhammer have asked for, I'm afraid I'm not aware of any off the top of my head. I agree this is important - parity between v1 and v2 is one of our top priorities, so I'm trying to figure out if there's a reason we aren't supporting 'acr' in v2 id tokens. I've started the conversation with some folks on my end and I'm hoping to have an update for y'all soon.

[onionhammer]

Appreciate it, thanks @nickludwig

[kobynz]

Thanks @nickludwig, Your effort on this issue is much appreciated.

[HakanL]

Perhaps a stupid question, but how can I get the claim (added to the manifest as described above) from the access token? The access token I get is not a JWT format, and the MSAL library doesn't seem to offer a way to parse it. I'm using the Microsoft.Identity.Client (version 4.48) library. In my Winforms app I just need to authenticate a user against AzureAD and make sure their account has MFA enabled (acr claim). I call AcquireTokenInteractive, which returns the access token as a string, but it's not in JWT format and from what I can find doesn't provide a way to parse it (nor am I sure that's the correct approach anyway). I feel like I'm missing a step here.

[nickludwig]

Hey @HakanL - not a stupid question! When you say "the access token I get is not a JWT format", what are you referring to? Like, is it in the base64-encoded format of ey.asOI8sdOJ7WQGDdsaf32...? If so, then that's to be expected. You can test that this decodes into a JWT by pasting the string into https://jwt.ms.

Also, is your Winforms app acting as a client or a resource in this flow? Access tokens are meant to be opaque to the client - meaning, if your Winforms application is acting as the client here, then it shouldn't be concerned with figuring out what's in the access token. It should simply pass the opaque string to the resource. If that's the case, then it seems like you're in a similar position to the other folks in this thread where you need some way to verify that the user has performed MFA based on id token claims.

[nickludwig]

Also, @onionhammer / @perttulaurila / @kobynz - apologies for the late follow-up. I took some time off and am just getting back into the swing of things. I agree that this is a valuable thing, but I haven't been able to secure enough information from folks on my end to determine whether this will be something that makes the funding cut in the immediate future. As such, I'm going down the path of putting together a backlog item to track asks for this - before doing so, I wanted to clarify a few things:

@onionhammer - the scenario you're trying to enable is essentially that you have a B2C environment, and you want to be able to verify that users signing-in and signing-up have previously performed MFA so you can avoid double-prompting them? If my understanding is correct, I'll get this scenario added to the item. In the meantime, federated users will have to continue to double-MFA - which I understand is a poor end-user experience.

@perttulaurila - I think I may need some more context on your use case. I'm not particularly familiar with PingFederate, could you elaborate a little more on your scenario? What kind of environment in AAD do you have (i.e., B2C, regular AAD, etc)? Is the scenario that you have essentially some client application which needs to assess whether the user has performed MFA, and just needs claims from the ID token to assess this instead of the access token (given that access tokens are treated as opaque by the client). Also, what category does this scenario fall in to (i.e., Onionhammer's scenario needs amr to prevent the poor end-user experience of requiring federated users to double-MFA when signing-in/signing-up).

@kobynz - I don't think you mentioned what your scenario is. I'd love to know so I can get that added to the item I'll be tracking this ask with.

Thanks again!

[kobynz]

Thanks for the update @nickludwig.

My scenario seems similar to the one described by onionhammer.

We're building a SaaS product, which includes a sign-in app based on IdentityServer4. Our own direct sign-in flow has an MFA mechanism, and some of our clients require MFA for all of their users. We don't want the user to be "double MFAd" when signing in, as this is a bad UX. (once when signing into MS, and then again after returning to our app)

In essence, we just want to respect the "upstream" identity provider's mfa claim, so we can skip our own one.

[onionhammer]

You've captured the crux of the issue well @nickludwig

[perttulaurila]

@perttulaurila - I think I may need some more context on your use case. I'm not particularly familiar with PingFederate, could you elaborate a little more on your scenario? What kind of environment in AAD do you have (i.e., B2C, regular AAD, etc)? Is the scenario that you have essentially some client application which needs to assess whether the user has performed MFA, and just needs claims from the ID token to assess this instead of the access token (given that access tokens are treated as opaque by the client). Also, what category does this scenario fall in to (i.e., Onionhammer's scenario needs amr to prevent the poor end-user experience of requiring federated users to double-MFA when signing-in/signing-up).

We are using regular AAD. My scenario is very similar to Onionhammer, with the difference that we would like to evaluate both the authentication method (amr claim) and whether the device used to authenticate is managed using Intune.

In our case this is not just a matter of user experience, as the client would base authorization decisions on these claims.

[HakanL]

Thanks for your response! I tested some more, so if I'm using my "business Azure" login, then I get a JWT token (ey...), but if I'm using my personal then I'm getting a token that starts with EwCAA8l, and I can't decode it. My WinForms app is acting as a client, there is no resource (in Azure), we're only using Azure to authenticate users, but we would like to make sure they are using MFA (not necessarily every time, but that the account is "secured" with MFA). Which if I understand it correct, is what the ACR claim can be used for. But the access token with a personal account can't be decoded.

/Hakan

Hey @HakanL - not a stupid question! When you say "the access token I get is not a JWT format", what are you referring to? Like, is it in the base64-encoded format of ey.asOI8sdOJ7WQGDdsaf32...? If so, then that's to be expected. You can test that this decodes into a JWT by pasting the string into https://jwt.ms.

Also, is your Winforms app acting as a client or a resource in this flow? Access tokens are meant to be opaque to the client - meaning, if your Winforms application is acting as the client here, then it shouldn't be concerned with figuring out what's in the access token. It should simply pass the opaque string to the resource. If that's the case, then it seems like you're in a similar position to the other folks in this thread where you need some way to verify that the user has performed MFA based on id token claims.

[emanuel-virca]

Any updates on this?

[jordanmills]

Another year. Any updates on this?