We are developing a SCIM / Okta integration and encountered issues while checking our integration’s compatibility with Okta’s.
It seems like the way Okta handles the removal of a user from a group has two possible code paths:
if the user still has at least another group membership, Okta sends a PATCH to the group endpoint to remove the user from the group it was removed from. That is what we would always expect and that works well.
if the user is removed from all groups, Okta sends a a PATCH to the user endpoint to mark the user as active: false. This is not logical from our perspective as the group membership is still present, the user is merely disabled/unable to login. This resulted in validation issues from your side saying that when listing the group, that user is still in the list of members, but that is for us an incorrect expectation as it was never removed from the group members.
It would be much better from a SCIM compliance point of view if Okta would send a PATCH to the group endpoint as well to remove the user like in the first code path above, and then would issue a DELETE /scim/v2/Users/[user-id] request to disable/delete the user, or PATCH to set active:false, same same, but the group removal should be done first.
This is a known limitation and documented in this link.
The following are the known Group Push limitations:
Okta doesn’t support using the same group for app assignment and Group Push. To maintain consistent group membership between Okta and the downstream app, you must create a separate group that’s configured to push to the target app. See App assignments and Group Push.
Sorry I am not sure how that is related to my query. When a user gets unassigned from all groups they get their access removed, ok that makes sense and I have no problem with that limitation. But the way the Okta SCIM client communicates this to the SCIM server could still be improved I would say.
This limitation is why you would want a group not part of push group so that you can first remove memberships and then deactivate the user.
As far as changing how SCIM client is implemented, we definitely value your feedback. We would appreciate adding your suggestion in Okta Ideas portal - Okta Help Center (Lightning)