I am really fuzzy on how the bearer token is generated when Okta pushes a SCIM request. So the admin logs into Okta, Let’s say he/she updates an Okta user profile for a user that is associated with our SCIM app and Okta now pushes the update to our SCIM server. When and how did the token get generated. Is there something that gives me enough of a picture so I can write the OIN configuration guide? Is there someway to test from the my developer account? I’m hoping someone can point me at some answers
During server development and testing I used the SCIM server Swagger Authorize to generate a bearer token. I used Swagger for initial testing and then I grabbed this token and used it for provisioning the server in the Okta app for final testing. The Swagger client app is OIDC with PKCE verify. Is it this app that would need to be configured when “installing” the SCIM feature?
We have an SSO app but I was not involved in its development. It is not in OIN but the Swagger client is modeled after it just with added PKCE.
TIA to anyone that can point me at a guide or other docs that might give me some direction.
What do you mean by generated? When an admin adds an OIN application to their org that supports SCIM and that uses Bearer tokens as the authentication mode (docs here on the properties required when submitting a SCIM integration to the OIN), that admin will need to provide the Bearer token during configuration.
Are you instead asking about the OAuth 2.0 authentication mode? We support the Authorization Code grant type and will require that a Client Secret be provided (by you, during the submission) so Okta can make requests to your OAuth provider for tokens, which will then be used as authorization against your SCIM server.
Thanks for the quick reply and sorry for the slow response. It was the OIN submittal that threw me for a loop. My SCIM server was written per your blog (How to Manage User Lifecycle with .NET and SCIM | Okta Developer) and authorization is using https://dev-xxxxxxxx.okta.com/oauth2/default (per the okta.aspnetcore middleware) so obviously an Okta generated token. Was this only for development purposes and the SCIM server should be using our IDP and our token? This may be the source of my confusion. Again thanks for your assistance
If your SCIM server is in fact secured by OAuth tokens generated by Okta, then you could use it, but every admin that needs to set up your application will need to be able to auth into your Okta org to get tokens. If you have a different IdP that supports OAuth and whose tokens secure your SCIM server, then yes, you would want to provide it the URLs for your IdP instead of an Okta org.
I imagine the blog wanted to demonstrate how to complete everything within Okta, but if you already have a different Identity Provider in place, you should be able to use that instead. You’d just want to make sure the SCIM server is able to validate these tokens.
@ram.gandhi, do you have any other guidance or tips about using a different IdP?
Technically you can use any IDP supporting oAuth2, the blog referenced Okta since we have access to good options. Your OIN submission fields should have pretty generic oAuth related fields which should suit any IDP supporting oAuth2.
Also glad that our blog helped you integrate with Okta using SCIM.