Azure Active Directory v2.0 Email Address Verification

Question

I'm trying to add a "Sign in with Microsoft" button to an Angular App with the MSAL library and the V2 endpoint. The app needs to work with both personal and organizational accounts which will then be cross referenced with existing users in my database. i.e. the Microsoft login is just a convenience on top of my existing login system.

The flow I've adopted so far is:
1. User requests a JWT id token via implicit flow in the browser, using the graph scope openid email profile.
2. Browser posts the id token back to server.
3. Server verifies the token (I'm allowing multiple tenants and do NOT check the issuer field of the JWT).
4. Server first looks for email in the email claim.
5. If no email claim is present then check the preferred_username.
6. If the email matches one of our registered addresses then user is signed in. If no match or no email then error is returned.

So far, so good. I've checked this with both a personal account and an organizational account and it works.

However, this whole approach relies heavily on the email address of the user being verfied.

In the token docs I've read that preferred_username is mutable and "must not be used to make authorization decisions". I can see the logic, but in this case I'm only using the email for authentication not resource authorization.
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-tokens

So my question is. Is there any way that a spoofed (non-verified) email could be present in either the "email" or "preferred_username" fields in a V2 id token?

If yes, is there anyway I can cross check using graph API to see if it has been verified?

My potential workaround is to send my own verification email to link the MS account with our own accounts, but I would like to avoid that if possible.

Answer 1

I doubt those could be spoofed. A bigger problem is if the user principal name/email changes. As you can see in the Token reference, there are 2 claims which would work much better for identifying the user:

• Subject (sub)
  • The principal about which the token asserts information, such as the user of an app. This value is immutable and cannot be reassigned or reused. It can be used to perform authorization checks safely, such as when the token is used to access a resource, and can be used as a key in database tables. Because the subject is always present in the tokens that Azure AD issues, we recommend using this value in a general-purpose authorization system. The subject is, however, a pairwise identifier - it is unique to a particular application ID. Therefore, if a single user signs into two different apps using two different client IDs, those apps will receive two different values for the subject claim. This may or may not be desired depending on your architecture and privacy requirements.
• Object ID (oid)
  • The immutable identifier for an object in the Microsoft identity system, in this case, a user account. It can also be used to perform authorization checks safely and as a key in database tables. This ID uniquely identifies the user across applications - two different applications signing in the same user will receive the same value in the oid claim. This means that it can be used when making queries to Microsoft online services, such as the Microsoft Graph. The Microsoft Graph will return this ID as the id property for a given user account. Because the oid allows multiple apps to correlate users, the profile scope is required in order to receive this claim. Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they are considered different accounts, even though the user logs into each account with the same credentials.

Since the subject is "always present in the tokens that Azure AD issues", it might be the best choice. Object id is good if you need to identify the user in Microsoft Graph API for example.