Best practice for unique identifier

Our SaaS app integration keys off of the Okta username/nameid and creates their account in our app based off of that. e.g. Okta passes the nameid = mary@domain.com and we create an account based off of that with a field in our db.

We also assert firstname, lastname, and email.

The user can be created with SAML w/ JIT or SCIM, depending on their config.

However, I keep running into an issue where a customer says they want to change their email address, but when they update the Okta profile and then try and sign in — it creates a duplicate account — as our app has never seen this newly added name, and therefore sees that as a new user.

One of my customers told me that he doesn’t have to worry about this with other apps.

We get variations of this request:

  • if they only change the actual email address in the Okta profile, that is fine and gets pushed down to our app and we update the email address.
  • Sometimes they change both the Okta username and the email address, and then it creates a new account.

So, I guess the question is - Is there ever a reason why an existing user record in okta should have its username / userId changed, and if so, how are we supposed to handle that on the SP side if we are using that as the unique identifier?

Also, how do most Okta admins perform a change? Do you go into the users profile record and update both the username and email?

Just looking for some best practices on this.
Thanks!

Any tips for best practices?

TIA

Hello,
For this case I suggest opening a support case.
I did a quick test with an App that integrates with SCIM 2. Within Okta when I modify both username/primary email Okta does a GET to SCIM using the external ID, then a PUT with the modified username/email again using the same external ID. So in a case like this I would suspect SCIM servers to not create a new account. With SAML it could be different, I have not worked SAML JIT.
There are many factors that could come in with various integrations I think opening a ticket with support where one of your environments exhibiting this behavior can be addressed would be best. Assuming other integrations are similar the changes could most likely also be carried over to those.

1 Like

Thanks, that’s a good idea, I’ll try and open up a ticket.