0

From the service providers documents. Access or bear token is mentioned. It does not say what is the token grant type needed….

jetpack
  • 169
  • 1
  • 9

1 Answers1

1

I work with SCIM but know some of the auth stuff as a side effect of that. My best effort at answering this is:

Typical implementations of SCIM either provide long-lived bearer tokens or leverage OAuth 2.0.

For long-lived bearer tokens (typically JWT), which can be issued however you prefer - I see them issued via customers making API calls directly or through some form of admin UI.

For OAuth 2.0, typically it'd be either Authorization Code Grant flow or Client Credentials Grant flow.

Keep in mind that "typical" here is in the context of interoperability of applications connected to a major IDP's SCIM client (AAD, Okta, OneLogin, etc). Given the tags on this post mention all of those IDPs, it seemed like a contextual hint.

Zollnerd
  • 725
  • 4
  • 5
  • Azure AD Scim validator seems to accept Oauth2 tokens with grant types Authorization Code, Password, and implicit......I have tried client credentials but it wont work.....checking on documents with SCIM service providers, it seems JWT and Client credentials are general grant types used by these – jetpack Oct 07 '22 at 07:55
  • 2
    I believe the Azure AD SCIM validator only accepts bearer tokens, and that the token value provided will be passed as the value for the HTTP Authorization header. My understanding is that OAuth 2.0 tokens can be utilized in the Authorization header, but the grant type isn't necessarily relevant there. FYI, I work at Microsoft on the Azure AD Provisioning team. I'll share this post with a peer of mine who is the product owner of the SCIM validator as well. – Zollnerd Oct 07 '22 at 16:49
  • i think i got your point...bearer token it is and grant types are irrelevant...the client credentials I mentioned that is not working is the fault of my program and not azure scim validator – jetpack Oct 11 '22 at 08:22