Some design suggestions since I know little of Identity

I have a SCIM app in my dev account (transitioning to trial) and a SCIM server deployed in AWS that passes both Okta runscope test suites as well as all my testing IF I provide an OAuth2 bearer token for testing. No luck, so far, with providing a token to the SCIM app to use when needed. Think that is because I used the OIN template to build it and want to use OIDC? Next step is have a beta customer of our application use their production Okta account to test using SCIM to maintain users in our application validation deployment before going into production. We will not have an OIN available for this so the Okta app(s) will be built in the customer’s account for use during the beta testing phase. We will also NOT be using our IDP to provide a token at this time. Maybe in the future will use our IDP but not for now on this project

The use case is the customer admin will log into their Okta account, assign a group of test users to the SCIM app, then perform add, update, and deactivate in the users Okta profiles and confirm that the changes occur in our application and work correctly for the users.

Bottom line. If I want Okta (I’m using the default server now based on the Okta admin user’s credentials) to provide a bearer token for this testing and have the SCIM app pass it to the SCIM server, what Okta app, of what type, do I need to use and configure? With transfer to trial I need to re-build everything anyway so all options are on the table. Just looking for one that would work.

Shifting user maintenance from a third party application to Okta would seem to be a pretty common SCIM task so I must be missing some fundamental piece of the process. Maybe someone can restate the use case so I better understand what is supposed to happen? So far everything I have read is clear as mud to me.

If you would like the SCIM integration to use OAuth and get the bearer token from the customers own Org they will need to use either a SAML or SWA application created using the Okta Application Wizard. These 2 type of apps allow for a full OAuth2 flow where the SCIM 2.0 apps from the OIN require a hardcoded token which would need to be manually updated.

There is a difference between the SCIM 2.0 app(s) and the SAML/SWA apps.
SCIM 2.0 uses PATCH requests for most of the /groups endpoint updates and a couple of the /users endpoint updates (user status and password sync).
SAML/SWA is used instead it will be 100%if PUT.

Submitting to the OIN gives the option of setting up a full OAuth2 flow like with the SAML/SWA app, and still support PATCH.

Setting up either SAML/SWA the provisioning for OAuth2 with Okta will look like,

This is configured for the Org Auth server so the authorization endpoint needs to add a scope such as ?scope=openid.
(In production the scope should be or contain offline_access so new access_tokens can be acquired as they expire.)

For the client Id/Secret a customer would create a Web Type OAuth2 app in their Org.
Assign the user who will do the authentication.
Add the appropriate redirect_uri dpending on their Okta Environment.
See Build your SCIM API service | Okta Developer

The SCIM server needs to be setup to validate these tokens.
This can be done remotely by calling introspect on the customers authorization server /oauth2/v1/introspect
Or locally by downloading the keys /oauth2/v1/keys and validating the token signature.

Erik, Thanks for the great response. I see now what is causing me grief and how to eventually get past it. Biggest part of what I am missing is adding provisioning to my account. That is why I cannot find the example you gave. Re-read the docs and finally saw the lines I missed. Can you add this feature to dev-44103049 and trial-5605516? Then I might have some success at seeing how this is supposed to work. Please also can you confirm that provisioning cannot be done with the OIDC app? Just want to make sure the doc is still up to date.

That is correct. OIDC applications created from the application wizard won’t have an option to enable provisioning.
Either a SAML or SWA application will be needed.
If an OIDC application is submitted to the OIN, then there will be an option to enable provisioning. This is only for OIN OIDC apps.