How to key users when using OIDC and SCIM

Matt Wilson 11

I originally posted this question to SO a month ago, but didn't get any response, so I'm trying here.

-------

I'm in the process of updating an internal app with OIDC and SCIM with the goal of having sign-on and provisioning driven by Azure AD.

Looking at the Azure docs for OIDC and SCIM, there seems to be a discrepancy around how to uniquely identify users. Coming into this project, I presumed the user's ObjectId would be made readily available.

Using a test enterprise app, and navigating to user attribute mapping for provisioning: The default mappings include userPrincipalName (upn) mapping to userName with the highest matching precedence. And the inability to modify that mapping.
Also, mailNickname is mapped to externalId, without any matching precedence, but this could be changed to map objectId to externalId and add matching if desired.

Meanwhile, using another test enterprise app for OIDC, the sub claim is not the user's Object Id. I think I read the sub claim is a unique value for the user and the enterprise app (which means it's no good to anyone).
Under Token Configuration, there does not seem to be the option of adding the Object Id as an optional claim at all. There is the option to add the upn as an optional claim, but the description explicitly states not use the value for keying the user.

An identifier for the user that can be used with the username_hint parameter; not a durable identifier for the user and should not be used to key data

This comment makes sense to me. upns can change over time and should not be used to identify users for the same reasons that you shouldn't rely on a user's email not changing.

All that being said; if I want Azure AD to provision users via SCIM and then allow those users to sign in with OIDC, how should I uniquely identify the user record as the service provider?

Sandeep G-MSFT 14,326 Reputation points Microsoft Employee

2022-10-04T03:10:08.3+00:00

@Matt Wilson

I am looking into this thread. I will do research on this and will revert accordingly
Matt Wilson 11 Reputation points

2022-10-24T16:37:46.507+00:00

@JimmySalian-2011 do you have any feedback?
JimmySalian-2011 41,916 Reputation points

2022-10-24T18:33:28.663+00:00

Hi Matt,

Let me read through this and will get back to you.

Regards.
Fradsham, Derek (SNB) 11 Reputation points

2023-01-03T19:05:26.677+00:00
Hi, hoping someone has some time to look into this, its driving me nuts at the moment.

My observations of the situation (I am trying to provision and do SSO to Salesforce):

Setup for app provisioning to Salesforce works fine, and as noted above you can use ObjectID->ExternalID as a unique identifier if you don't want to use UPN.

You cannot use SUB (pairwise hash of user OID and App ID) in the attribute mappings for provisioning - it is not available.

You cannot change the SUB claim in the access token on the Azure side, its protected.

You setup SSO using OIDC on your service provider (Salesforce) to use the OAuth endpoints from your IDP (Azure).

SSO either fails or creates a new user because it requires the SUB claim to be used as the unique identifier, and that is not part of the SCIM provisioned user object.

In this case Salesforce is inflexible when it comes to subject as the unique identifier for OIDC using the built in auth providers, which leaves you with having to write a custom auth provider in order to use the objectID/ExternalID as the unique identifier.

I find it very odd that the sub claim cannot be used in provisioning from Azure given its always in the access token as the default unique identifier (sub).
Klaas van Hagen 0 Reputation points

2023-11-17T16:59:36.12+00:00
Hi Derek,

Have you been able to figure this out yet? I'm in the same predicament. The only way I've been able to get hold of the oid claim is by targeting the v1.0 endpoint

https://login.microsoftonline.com/{tenantId}/

instead of the v2.0

https://login.microsoftonline.com/{tenantId}/v2.0/

In the v1 I get oid both in the ID_Token and from the userInfo endpoint. None of that in the v2.0