I’m trying to implement a simple SCIM client that allows OKTA to delete users in some 3rd party system. Ideally I’d like OKTA to send “deactivate user” event time a user assigned to some specific OKTA app is deactivated or unassigned.
When a user is assigned, OKTA sends /Users?filter=userName userName eq "<user id>" checking whether the user exists. Returning a “fake” user info is the only way for my SCIM client to receive deactivation requests later even. Otherwise OKTA assumes the user doesn’t exist in SCIM client and doesn’t deactivate it. What is the right strategy in this case? Should SCIM client always reply a user even if it still doesn’t exist?
Well, if you think a bit, then you’ll realize that to be able to unassign/delete a user from an app, you first need to assign it to this app, or at least get a confirmation that a user is already assigned.
In your case I’d respond back to the first request (getUser) with an immutable ID of a user in your external system, which later can be used during unassignment.
That’s what I though too. To make the deprovisioning working (to receive delete events from OKTA or any other SCIM server) the client should reply a user (even a fake one) to any “get” operation.