Skip to content
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

V2 OIDC userinfo endpoint returns sub claim only, for personal Microsoft accounts. #28317

Open
danielhcx opened this issue Mar 29, 2019 · 12 comments
Open

Comments

@danielhcx
Copy link

@danielhcx danielhcx commented Mar 29, 2019

According to Fetch the OpenID Connect metadata document, the oidc userinfo endpoint is https://graph.microsoft.com/oidc/userinfo. However, this endpoint returns different results for the work accounts and personal Microsoft accounts.

An application has been created in App registrations (Preview). Its supported account types are accounts in any organizational directory and personal Microsoft accounts. The scope is set to openid, profile, email, https://graph.microsoft.com/user.read.
For a work account, the userinfo endpoint returns something like:

{
    "sub": "xxxxx",
    "name": "xxxxx",
    "family_name": "xxxxx",
    "given_name": "xxxxx",
    "picture": "xxxxx",
    "email": "xxxxx"
}

For a personal Microsoft account, only the sub claim gets returned:

{
    "sub": "xxx"
}

I also noticed that the access token of a work account is quite different from the access token of a personal account. The former is a JWT, but the latter is not.

No explanation for above in any Azure AD docs.

Document Details

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

@neeleshray

This comment has been minimized.

Copy link

@neeleshray neeleshray commented Mar 29, 2019

@danielhcx
Thanks for your feedback! We will investigate and update as appropriate.

@MohitDhingra-MSFT

This comment has been minimized.

Copy link

@MohitDhingra-MSFT MohitDhingra-MSFT commented Mar 29, 2019

Hi @danielhcx,

For personal Microsoft account like outlook.com, the authentication request is processed by the Identity Provider like live.com. The Idp like Live.com does not return first name, last name and multiple other attributes and that is why you do not have this information automatically populated on the guest account with your azure AD. So if you need this information within your directory, you would have to manually fill these details for the guest accounts or create a script which will update all the Guest user's basic information.

To check all the users information, login with admin/global administrator account and get the jwt token and use that jwt token to hit the below url
https://graph.microsoft.com/v1.0/users.

In the below screenshot, for guest user the surname, givenname are null. After that I updated the jobTitle, so it is populating.

image

I hope this solves your issue.

Thank you.

@danielhcx

This comment has been minimized.

Copy link
Author

@danielhcx danielhcx commented Apr 1, 2019

Thanks, @MohitDhingra-MSFT .

Creating guest accounts can't be a solution for my case, because I can't predict which live.com account will be used for the "Connect With Microsoft" in my app. Anyway, according to the OIDC spec, the sub claim is the only one required in a userInfo response. https://graph.microsoft.com/oidc/userinfo doesn't break it.

With a live.com user's consent, my app can get more attributes about the user from the endpoint https://graph.microsoft.com/v1.0/me/. However, it's not a standard OIDC userInfo endpoint. To integrate with Azure AD OIDC, it will definitely make our life easier if the /oidc/userinfo endpoint can return the same information from /v1.0/me for a personal account. Do you know if there are any plans for that?

@shashishailaj shashishailaj added assigned-to-author and removed cxp labels Apr 1, 2019
@shashishailaj

This comment has been minimized.

Copy link
Contributor

@shashishailaj shashishailaj commented Apr 1, 2019

@CelesteDG Could you please help get this checked with engineering teams if we have any plans so that /oidc/userinfo endpoint returns the same information as the /v1.0/me for a personal account?

This comment has been minimized.

Copy link

@eframsergio eframsergio commented Jun 11, 2019 — with docs.microsoft.com

Hi y'all! So is there an update regarding this issue? Like danielhcx said, the user info endpoint (https://graph.microsoft.com/oidc/userinfo) returns this {"sub":"AAAAAAAAAAAAAAAAAAAAA..."} instead of the full user info. I used a personal 'msn' account for testing. How does one obtain a valid user info payload (similar to the gmail one: {"sub", "name", "given_name", "family_name", "picture", "email", "email_verified", "hd"})? Thanks!

@satterly

This comment has been minimized.

Copy link

@satterly satterly commented Jun 12, 2019

For now, you can get some of the information in the id_token JWT returned from the /token endpoint. ie. name, preferred username and email.

This comment has been minimized.

Copy link

@eframsergio eframsergio commented Jun 12, 2019 — with docs.microsoft.com

Awesome, thanks!

This comment has been minimized.

Copy link

@arun-a-nayagam arun-a-nayagam commented Jun 15, 2019 — with docs.microsoft.com

Comparing the common (https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) and a tenant specific (https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration) jwks_uri, it looks like the same set of private keys is used to generate an id_token.
Isn't this a security risk?
I understand the JWT validator should verify the "aud" but you would think Azure maintains different key sets for different tenants (if not for the apps)?

@CelesteDG

This comment has been minimized.

Copy link
Contributor

@CelesteDG CelesteDG commented Aug 14, 2019

My sincerest for just now getting to this issue.

#reassign:@hpsin - Hi @hpsin - Can you please review and advise? Thank you very much.

@PRMerger20 PRMerger20 assigned hpsin and unassigned CelesteDG Aug 14, 2019
@PRMerger20 PRMerger20 added the Pri1 label Aug 14, 2019
@CelesteDG

This comment has been minimized.

Copy link
Contributor

@CelesteDG CelesteDG commented Aug 14, 2019

#pri2

@PRMerger20 PRMerger20 added Pri2 and removed Pri1 labels Aug 14, 2019
@szisti

This comment has been minimized.

Copy link

@szisti szisti commented Jan 10, 2020

Is there any update on this?
I can see 2 very simple solutions:

  • add full $select support for oidc/userinfo endpoint
  • add support for sub on the /me endpoint

Either of these would allow to get details of the users
the full point of having the sub, is that it ensures that it's the correct user
so if i have to implement another call to get more details of the user, where this validation is not in place, than i cannot guarantee that the information relates to the same user

@hpsin

This comment has been minimized.

Copy link
Contributor

@hpsin hpsin commented Jan 10, 2020

Hey folks - a couple points on /me and /userinfo.

  1. /me returns a set of data that is both beyond what userinfo is allowed to return per spec, and not in the correct format. So we can't just proxy /userinfo to /me, which would be simplest.

  2. The team working on getting /userinfo support for personal accounts (MSA) is still working to get the userinfo endpoint hooked up. Once complete, it will just return the subset of information found in the userinfo response for AAD users.

  3. Adding sub to /me is a great idea - I'll suggest it internally. CC @dkershaw10

  4. @arun-a-nayagam - we may switch to tenant specific keys in the future, but have no plans at this time. It would create significant strain on large applications to have to download and possibly cache tens of thousands of jwks responses as they got tokens from multiple tenants. It's not clear the security risk though - all the keys are held in the same (extremely secure) place. If your concern is cross-tenant attacks allowed via the same signature, you're already assuming that the application is ignoring the actual tenant information inside the token - which means they're already vulnerable to such an issue.

  5. The access token for MSA users is an internal, encrypted format that MSA services understand. It's expected (and documented in many of the v2 docs).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.