I’m comparing values sent by Okta for OIDC (auth code flow) and SCIM (creating/updating users) and was surprised to see the OIDC sub claim is the user’s Okta internal ID, while userName provided by SCIM is the userName field from Okta’s user profile.
What is considered best practice for services looking to an app to the OIN that has OIDC and SCIM support?
For first-party integrations, it seems keeping track of which customers are using Okta as their IdP would be an option. And for those SCIM API calls use the externalId value instead of userName to unique identifier for the user for login. However, when we start letting customer self-onboard it would mean sniffing the user-agent for SCIM API calls. Less than ideal. Hopefully, I’m missing some option.
Yes @warren, I’m not suggesting I’ve found a bug going against Okta’s docs.
But the way they’ve chosen to implement the two specs means different values are used to uniquely identify users across the two flows. So as the service provider, I’ll have to implement Okta specific logic to map the login request against provisioned users. I refuse to believe I’m the first service provider to have this pain. The purpose of my post is ask if Okta has suggestions for best practices when handle this mapping.
My first assumption is I’ll be forced to have logic in our SCIM server that handles “if the IdP is Okta, then ID the user by externalId instead of userName”. However, knowing the client is Okta is easier said than done.
We happen to be multi-tenant, but that isn’t really related to my topic. As for OIDC, just using the iss claim is plenty to handle multi-tenant.
Importantly, our service does not use only Okta for identity providers.