hi, i am trying to setup SCIM integration to my project with Okta (as detailed in the documentation https://docs.descope.com/manage/scim/), and i'm not sure why, i am getting the following error in Okta when I'm testing the connector config. i went over the docs several times, but i am not sure what i am missing / doing wrong. i have SSO configured, and working for me. can anyone offer some assistance to point out what i should be doing to fix it? Thank you 🙏

Hi, can you share a screenshot on how SCIM is configured in Okta? (Blur sensitive information)

sure the screenshot of how SCIM is configured in Okta below. anything else?

And the authorization header is with the projectId:key format right?

you're right. that seemed to have been the issue. the projectId was incorrect 😖 sorry for the false alarm and thank you for the fast reply!

All good! Thanks

i have a follow up question if you may. the SCIM config. seems to be working, and when i log in with a user that belongs to an assigned group of people in my Okta, a new user is being created in Descope. great! my question is this, when I remove that same user from the group in Okta that is assigned to the application, i expected the user to be also removed from Descope. But that doesn't seem to be happening for some reason, what am i missing?

In case removing a user from a group in the IdP, the user is getting update in Descope according to the group/roles mapping. So if the user is not longer belongs to group A which is mapped to Role X, the user will be unassigned from Role X. And next session refresh will get this update.

i see. is that done intentionally (not deleting the user in Descope) if it's removed from a group in the IdP? i'm asking bc one of our clients asked if we're providing with "de-provisioning" for inactive accounts or if we have an API we can provide them to remove those users, and from what i could tell Descope is not providing with such API either. it seems like i would need to provide that API myself for the client and removing those users using management keys, am i right?

The user is still in the Okta directory so we can’t delete it according to the protocol, otherwise we will have mismatch and out of sync with the IdP. The user might be part of several groups, so if the user is removed from admins group but still in maintainers group for example, we should keep the user and update their groups and roles in our end.

The user is still in the Okta directory so we can’t delete it according to the protocol, otherwise we will have mismatch and out of sync with the IdP.

The user might be part of several groups, so if the user is removed from admins group but still in maintainers group for example, we should keep the user and update their groups and roles in our end.

I see. what i was expecting to see though, is that the user is no longer listed in Descope. just like it wasn't listed before I made the initial login (and after creating the SCIM integration and syncing it). as an evidence, I have 2 other users in my group in Okta which never signed in using Descope, and are also not listed in the UI. I'd expect the same for the removed user from the group. regarding the client's use case - this is part of our client's demands, to clean up any inactive users of their org on our side, so we don't keep those users in our DB (or Descope's in this case). i assume it's a matter of an inside org policy, i don't know for sure why they demand it

The thing is that we follow the scim 2.0 protocol, and we can delete a user only in the delete user operation. But in any case, the user will no longer have any roles assigned to it, so you can check that and do not let the user any access. We can think of removing the user from the tenant if not having roles at all after groups update.