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.