NameIdentifier vs ObjectIdentifier

Question

I have a multitenant ASP.NET application using OpenIdConnect and Azure AD as an Identity provider for Office 365. When the user is authenticated I receive my claims in ClaimsPrincipal.Current.

I wanted to identify a user and store this id reference in my database. I asked this question. It was replied that

When trying to identify a user uniquely [NameIdentifier] should be your go-to choice.

But it seems that the NameIdentifier claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier depends on the application. Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user. Keep in mind that the we may have to create another Azure AD manifest (because we could need other scopes) and we should be able to find back the same end-users.

Meanwhile, I remarked another claim: ObjectIdentifier http://schemas.microsoft.com/identity/claims/objectidentifier

It seems that ObjectIdentifier, is the same for all Azure AD-secured application for a given Office 365 user.

Can you explain precisely the difference between those two claims? And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.

Levalloisian

Answer 1

Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user.

I made a quick test as following:

Register a multi-tenant-webapp and single-tenant-webapp in AD Contoso.

Log in with [email protected] and get the name identifier in both web applications, it turns out the name identifier are the same in both applications. So the name identifier should be able to identify users cross applications, but it can not be used to identify the user in Azure AD.

For the object identifier, it is a GUID which you can used to identify a user in Azure AD. For example, you can use object identifier to query the user in Azure AD.

Powershell:

$msolcred = get-credential
connect-msolservice -credential $msolcred
get-msoluser -ObjectId "{guid:object_identifier}"  

And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.

Based on my understanding, the object identifier is a GUID which can identify for a user in Office 365 subscriptions.

Bolan

Hi Jeffrey, thank you for your answer. I can confirm that, from my side, I receive different NameIdentifier. Both my apps are MultiTenant and they differ from scopes: one of them is using Groups.ReadAll (read all groups in Graph API). Do you want these apps manifests? – Levalloisian

@Benoit, thanks for your details information. I will try to do more test on name identifier. But for the object identifier, it is the actual id in Azure AD, you can use this id to query user in Azure AD by using Powershell. – Bolan

It's also worth noting that you don't have access to NameIdentifier inside the On-premises ECMA App Provisioning mappings. So ObjectId's your only choice if you want to implement provisioning like that. – Pilgarlic

Answer 2

Or to put it another way:

The NameIdentifier is the GUID of the Application which is registered in Azure AD. This won't change whether it's a single or multi-tenant application. It won't matter if you are using client credentials (i.e. AppId and AppSecret) to authenticate AS the application or using logging using real user credentials (i.e. delegated), the NameIdentifier will remain the same.

The ObjectIdentifier is the User Principal Name (UPN) for the user when using delegation or Service Principal Name (SPN) of the application when using client creds.

The reason you see different ObjectIdentifier values when an application is multi-tenant is that there is a separate and unique SPN in EACH TENANT which points back to the ApplicationGUID in the tenant where the application is registered. This SPN is used to assign rights to the application against resources in each tenant.

Aerophone

NameIdentifier is not the guid of the application. It's the unique Id of a user REGARDING the application accross which he's authenticated (in implicit flow). It's guaranteed to be unique, but only in the scope of the application. That's the reason why, if you recreate the application, you will get a different NameIdentifier for the same user. The ObjectIdentifier, in the case of the implicit flow, is the ObjectId of the user in it's tenant. It' guaranteed to always be the same, as long as the user is not re-created in the tenant. To me, the most reliable is the ObjectIDentifier. – Amerson

But in the context of a multi-tenant application, I don't know if the ObjectId of the user is guaranteed to be unique accross all tenants... – Amerson

Just found the answer to my question :-). You can have a look here: [learn.microsoft.com/en-us/azure/active-directory/develop/…. The sub claim is actually the NameIdentifier claim, and the oid claim is the the ObjectIdentifier, and it's guaranteed to be unique accross all Azure tenants. So I think that a good candidate for a key in database, that will persist application re-creation, is a one compound of the provider Id (idp) and the object Id (oid). – Amerson

yep NameIdentifier is not the guid of the application. its the identifier of that user in that application objectId is that user's id in Azure (across all apps) object Id is not the UPN as this can be set as the actual user account... (at least they have done it that way in my org) – Gaiseric