I'm creating a set of API endpoints that should be compliant with SCIM schemas to work as a SCIM server for Okta platform.
The SCIM schema is clear to me, but I'm having problems understanding the Authorization. According to the SCIM docs, the authorization type should be "Authorization Bearer Token."
Here was my first problem: For me, the authorization token should be the same JWT that I use for OAuth 2.0 authorization, but now, thanks to SO, I know that is not true. The JWT and the use of Password Grant Flow is just a convention and not a rule.
Also, when I tried to create an example SCIM app into Okta platform, the only option available was a static token and not the pair client_id/client_token that I was expecting to use OAuth 2 (Side note: This is possible when using a SAML application and use SCIM for provisioning, but not with SCIM only app).
The problem is: What now? SCIM should be used with some specific type of token? Does it force some Oauth grant type? Which one?
I know that I'm probably making some mess with all these concepts, but is there any simple explanation for the use of tokens with SCIM?
OBS: I'm using Okta for now, but it should comply with any SCIM client.
Most customers who use SCIM w/ Okta, just used a static token for Authentication to SCIM Servers. So, they are not using an token generated via an Oauth grant.
I know the engineers at Okta have done some research, so that Okta Oauth Tokens can be used for a SCIM connection with Okta, but most Cloud/(SAS) services do not support this today, so I would expect it might be a while before we see Okta (and most Cloud IDPs) using Oauth Tokens for SCIM connections.
You are on the right track, in fact your ahead of the curve. You'll likely have to use a static generated token for SCIM today.