Azure-docs: V2 OIDC userinfo endpoint returns sub claim only, for personal Microsoft accounts.

[danielhcx]

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.

• ID: 628db02d-345a-5dc4-17f0-3d6ff76d7fe5
• Version Independent ID: 524b460d-47b7-72c9-e994-ea94b3a9dd2b
• Content: Azure Active Directory v2.0 and the OpenID Connect protocol
• Content Source: articles/active-directory/develop/v2-protocols-oidc.md
• Service: active-directory
• Sub-service: develop
• GitHub Login: @CelesteDG
• Microsoft Alias: celested

[neeleshray]

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

[MohitDhingra-MSFT]

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.

I hope this solves your issue.

Thank you.

[danielhcx]

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]

@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?

[eframsergio]

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]

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.

[eframsergio]

Awesome, thanks!

[arun-a-nayagam]

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]

My sincerest for just now getting to this issue.

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

[CelesteDG]

pri2

[szisti]

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]

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).

[rozpalacz]

@hpsin
Any progress on
*Adding sub to /me is a great idea - I'll suggest it internally. CC @dkershaw10 *

?

[hpsin]

Not at this time I'm afraid.

[hpsin]

As a note - we're in the final stretches of fixing this. Currently, Userinfo now returns the following for MSA:
"sub": "AAAAAAAAAAAAAAAAAAAAAAAc3MZ7ZKKpELMYTircG4",
"Name": "Hirsch Singhal",
"Given_name": "Hirsch",
"Family_name": "Singhal",
"Preferred_username": "h*@gmail.com",
"Email": "h*@gmail.com",
"Email_verified": true,
"picture": "https://graph.microsoft.com/v1.0/me/photo/$value"

The capitalization is incorrect, and we should not return the verified claim until we support it across the platform. We will update here when it is fully correct. (Edit: sub claim is correct)

[rozpalacz]

And what about adding "sub" to graph - "/me" ? Any news?

[hpsin]

@dkershaw10 - what's a good place to accrue this feature request on /me?

[VQuery]

@hpsin Changes published for this API? . Still unable to get the user claims for personal account login
https://graph.microsoft.com/oidc/userinfo

[hpsin]

@VQuery - are you requesting a token on v2 using scope=openid+profile+email? Without the latter two you will not get information about the user per spec.

[VQuery]

@hpsin yes I'm using all these scope in my call.

{
              "UserInformationEndpoint": "https://graph.microsoft.com/oidc/userinfo",
              "AuthorizationEndpoint": "https://login.microsoftonline.com/common/oauth2/v2.0/authorize",
              "TokenEndpoint": "https://login.microsoftonline.com/common/oauth2/v2.0/token",
              "Scope": [ "openid", "profile", "email" ]
}

[hpsin]

please-close !

The fix for this is now officially rolled out. The userinfo endpoint for MSAs now returns correct data that matches AAD:
{
"sub": "AAAAAAAAAAAAAAAAAAAAAK0rc3MZ7ZKKpELMYTircG4",
"name": "Hirsch Singhal",
"given_name": "Hirsch",
"family_name": "Singhal",
"email": "h*@gmail.com",
"picture": "https://graph.microsoft.com/v1.0/me/photo/$value"
}

@VQuery - please open a new issue and tag me in it, since it's not related to this one.