We’re implementing our own SCIM server and use userName as the unique identifier field for users. In server implementation, we silently ignore userName updates with PUT/PATCH to keep data consistency. However, we noticed that whenever user updates userName through “Application→Assignments→Edit User Assignment” view from Okta, it always triggers a PUT with active: false to deactivate existing user and then a POST for user creation. This leads to unexpected user recreation that I don’t think it’s justified.
Interestingly, if user updates userName through user profile attributes, Okta only sends a PUT request with updated userName without deactivating the user.
I’m seeing the same issue was raised by other people here Okta Help Center (Lightning) but don’t think there’s an official response yet.
I wonder could your team provide any insights on these distinct behaviors or any guidance on how we could prevent such user recreation? Thanks!
I observe the same behavior and am checking with the team.
What is the use case for changing the username directly in the App User Profile, Is this for testing?
Typically user updates would be done through the UD and let each applications mappings update the application user profile appropriately.
Frankly speaking I’m not sure how different admins prefer to update username and when exactly they will edit through App User Profile directly. We were just testing Okta SCIM integration and noticed that userName update is allowed through App User Profile and will trigger a user recreation.
Actually even if SAML app has configured to only update userName at creation time, updating userName through Edit User Assignment will still recreate the user via SCIM (on the contrary, updating userName through User Profile Directory won’t trigger a SCIM request anymore).
So if this is an intended behavior, we will need to document it and warn our customer about this behavior when they manage users via Okta SCIM.
Looking forward to hearing back from your team, thank you!
I’ve reported this issue to our engineering team for further investigation (for internal ref, OKTA-1069281) and will look to update this thread once I hear more.
I heard back from engineering and they confirmed this is working as intended. There is internal implementation details where updating a username requires different behavior compared to updating other attributes.
If you would like to have the team investigate if this could be changed in the future an enhancement request can be made to https://ideas.okta.com