New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any updates on when the amr claim will be available in v2.0? #85021
Comments
@tom-fredricksonDM Thank you for bringing this to our notice. We will investigate and update the thread. |
@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. |
🥺
…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
<#85021 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWIOIMQT2W5ATKGJ45PTUZ3UQD5Q5ANCNFSM5JU4L2GA>
.
|
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. |
#reassign:nickludwig |
Closing due to no status change. Hirsch's previous message still applies. I'll re-open if necessary. |
#please-close |
#please-open ? :D B2C doesnt appear to work with v1 |
Invalid command: '#please-open'. Only Microsoft employees can use this command. |
Any updates on this? Seems to have been in the backlog for a long while? |
It's interesting support for this was removed then this comment was closed without referring us somewhere else or any explanation.. |
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 For example, for this issue specifically, Salesforce wants to be able to ensure that the user performed MFA when signing in. Instead of using If |
#please-open |
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. Can you shed some more light what we can expect in there? |
@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 We'd definitely like to add more values in the future for additional strengths such as "phishing resistant", etc. As for right now, however, |
According to the docs, the https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#payload-claims |
@onionhammer - right, neither As for v2.0 access tokens, When you find the
|
The id_token does contain 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. |
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: Another question I have is would it be possible to have an application specific .well-known/openid-configuration metadata? 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. |
@onionhammer - apologies, I was mistaken. You're correct. |
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. |
@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. |
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 |
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: |
I've been running into this issue and have been trying to figure it out for a while now. 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 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 This feels like a dirty hack, but I don't know about any other workarounds. All I wanted was an |
Hey @NZKobra - Thanks for the feedback.
Yeah, that's because neither 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. |
Appreciate it, thanks @nickludwig |
Thanks @nickludwig, Your effort on this issue is much appreciated. |
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. |
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 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. |
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 @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! |
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. In essence, we just want to respect the "upstream" identity provider's |
You've captured the crux of the issue well @nickludwig |
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. |
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
|
Any updates on this? |
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.
The text was updated successfully, but these errors were encountered: