Microsoft OpenID connect: Getting verified email

Micha Riser 11 Reputation points

We have an application where users can log in with different SSO providers.

As we automatically merge user accounts across SSO providers based on their email addresses it is important that we can rely on the email address being verified by the account holder. However, Microsoft does not set the 'email_verified' field in the idtoken or user profile. Therefore my question is whether it is safe to assume that the reported email has already been verified (according to the comment on this page, it seems not:

An alternative seems to be to use 'verified_primary_email' from the optional id token claims. Can you recommend using 'verified_primary_email' to make sure we get an email from the user that has been verified? Under what circumstances are these present? It seems even when activating it in the "token configuration" of the App in Azure, the fields are not always set.

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,139 questions
{count} votes

4 answers

Sort by: Most helpful
  1. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    13 deleted comments

    Comments have been turned off. Learn more

  2. Robert Clark 0 Reputation points

    The top answer on this question should really be removed since it is extremely dangerous! Anyone who follows this advice will be opening their site up to account hijacking since the email the comes back from Microsoft is completely unverified. preferred_username seems to be a bit more reliable in my testing, and I've seen a few sites that support Microsoft Sign in using it. It seems that really the proper answer is to require the user to validate they do in fact own the email before signing them in.

  3. Saeed Akhter 5 Reputation points Microsoft Employee

    I'm the lead Product Manager for our authentication libraries at Microsoft. Please never use email or perferred_email for authorization decisions. Emails are unverified in enterprise systems like Azure AD and can be set programmatically to any value by the tenant administrator. If you are looking for a claim that uniquely identifies a user, please use the user's object id (oid). It guaranteed to be unique and persistent.

    We have detailed guidance on how to validate claims in the token here:

    Note that even in social sign in systems (like Facebook, Google), the email claim should not be used for authorization decisions. If they do perform email validation, it is often a one-time validation of the email address. There are many email systems where email addresses get reused (employees leave, new employees sometimes get the same email address, same with students at universities). It is also common for emails to change at companies due to personal situations (marriage, divorce). Emails often change during mergers, divestitures, rebranding of companies. All of these situations will invalidate a "1-time" email validation performed by a social provider. It is an insecure means of validating the user.

    For your scenario of linking accounts, I recommend that your application take the necessary steps to prove ownership of the email before allowing the user to link Azure AD's user object ID (oid) to an existing account.

  4. 2023-05-11T20:33:56.86+00:00

    Hello @Micha Riser , as stated by @Saeed Akhter and the Secure applications and APIs guideline by validating claims, you should never use claims like email, preferred_username or unique_name to store or determine whether the user in an access token should have access to data. Please use values such as oid and sub, those are immutable and thus secure to be used.

    When combining different accounts from different IdPS the safest would be to also rely on immutable claims. For those you will need to check the appropiate IdP documentation. A "verified" email address only means the email address existed during a point of time but does not warranty anything else.

    Let us know if you need additional assistance. If the answer was helpful, please accept it and rate it so that others facing a similar issue can easily find a solution.