Bug: Azure SSO uses 'unique_name' for 'sid', should be 'oid' or 'sub'

[mstrhakr]

The Azure SSO section appends the unique_name attribute to the end of ~azure: to give you your user ID.

Azure User-Object Creation:

var user = { sid: '~azure:' + userex.unique_name, name: userex.name, strategy: 'azure' };

However it seems there are issues using unique_name claim according to the documentation:

Only present in v1.0 tokens. Provides a human readable value that identifies the subject of the token. This value is not guaranteed to be unique within a tenant and should be used only for display purposes.

The sub claim seems to be the most appropriate:

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. The subject is a pairwise identifier - it is unique to a particular application ID. 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 wanted depending on your architecture and privacy requirements.

However oid could also be used:

The immutable identifier for an object in the Microsoft identity system, in this case, a user account. 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. 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 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're considered different accounts, even though the user logs into each account with the same credentials. The oid claim is a GUID and cannot be reused.

So maybe this could be updated, although we would have to still pull in unique_name to provide backwards compatibility or check the db for that style of sid and run a conversion to the new way.

The Only present in v1.0 tokens line in the documentation for the unique_name claim is what concerns me the most, as I think that means if we were to move to OIDC or SAML authentication for Azure over the current OAUTH2, we would not be able to see that claim anymore, potentially further complicating the changeover.

Related Microsoft Azure AD Documentation

[CornHead764]

Adding onto this fairly stale bug, another downside to using the unique name attribute is in scenarios where users can login with alternate login id's (https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-use-email-signin). With this configured, a user could login with [email protected], or [email protected] or [email protected] - all of which could result in the same Azure account, but in mesh central, would result in 3 different accounts.

It may make sense to expose the claim used for this function in the config file so the administrator can choose what to use. I'm not sure a 1-size fits all approach is the best option here.