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.

Looking forward to hearing your thoughts on this.