Where is the UPN claim for a guested user?

Question

We have a secondary AAD with guested users from a primary AAD. The token generated for the guest user appears to be missing the upn claim, but we are relying on the fact that the upn claim exists as that is what we are using to map users across systems.

I understand that the upn may be missing for guested Microsoft Live accounts, but these are full AAD accounts, just in another AAD. Microsoft’s documentation also suggests the unique_name claim may not actually be unique!!

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims

Could you tell me what determines the value of the unique_name claim?

Is this safe for us to use this claim to fallback to if the upn claim does not exist or is an externally guested user?

Guest user token content

{
    ..,...
    "tid": "xxxxxxxx-7ea7-413c-96bc-3f3aba133732",
    "unique_name": "[email protected]",
    "ver": "1.0"
}

Regular user Token content:

{
    ......
    "tid": "xxxxxxxx-72d8-4715-b14f-990c93843416",
    "unique_name": "[email protected]",
    "upn": "[email protected]",
    "ver": "1.0"

}

I know you would probably like us to use the “oid” but this would cause us issues between environments as the same user will be a different value in each AAD.

Answer 1

Tokens (well, tokens where ver==1.0) representing guest users in Azure AD will indeed be missing the upn claim, but will contain the unique_name claim, as you've discovered. This applies equivalently to guest users from other Azure AD tenants, as well as guest users from external identity providers.

The value of the unique_name claim for guest users from other Azure AD tenants will be the user's UPN, if available, or otherwise falls back to the user's email address. For other types of guest users, the unique_name will take other formats & values. The idea is that the unique_name is the best-effort human-readable identifier for the guest user.

In any case, the unique_name value can be changed, and in rare cases, collisions might occur. That's why the documentation recommends against using it as a primary user identifier. The recommended user identifier in the Azure AD system is the object ID, or oid.

Yes, the oid will be different for the same human across different tenants. But that's sort of the point of the Azure AD tenanted model. A guest user in another tenant is meant to appear as a completely different user to the application than the user in its "home" tenant. If you want to map these two users together, the best you can do is use heuristics, like the unique_name.

I'd recommend that you file requests on feedback.azure.com for a couple things:

1. A reliable user identifier that can identify users across tenants.
2. Better documentation on how to handle guest accounts in AAD.