The Authentication section of the SCIM Provisioning documentation contains the following regarding OAuth 2.0 Authorization Code Grant Flow:
After a user successfully authorizes Okta using OAuth 2.0, the authorization server of your app will redirect the user back to Okta with either an authorization code or access token.
RFC 6749 - Authorization Code Grant indicates the client (i.e. Okta) passes the authorization code and authenticate in order to get the access code:
(D) The client requests an access token from the authorization
server’s token endpoint by including the authorization code
received in the previous step. When making the request, the
client authenticates with the authorization server. The client
includes the redirection URI used to obtain the authorization
code for verification.
If my authorization server returns an authorization code to Okta
How would Okta authenticate with my authorization server when requesting the access token? What credentials are required between Okta (client) and my authorization server?
Are refresh tokens supported when using OAuth 2.0 for SCIM provisioning?
How would Okta authenticate with my authorization server when requesting the access token? What credentials are required between Okta (client) and my authorization server?
When using “SCIM 2.0 Test App (OAuth Bearer Token)”, you will need to manually specify the access token. Okta will use the JWT as authorization header for each call that it performs to your SCIM server.
If you are integrating the application in Okta Integration Network (OIN) through oinmanager.okta.com, you will need to provide a client ID and client secret. Using this details, Okta will perform an authorization code flow with your authorization server and retrieve an access token that will be used to further communicate with the SCIM server. This Okta administrator will see this process under Provisioning tab as "Sign in with ".
Are refresh tokens supported when using OAuth 2.0 for SCIM provisioning?
If the application is integrated in OIN, then yes, refresh tokens are supported in order to retrieve a new access token automatically and prevent interrupting the provisioning flow.
This depends on how you will deploy the configuration for your application. Ideally, the best solution would be to have separate client IDs and client secrets per tenant and for the mutual customer to authenticate and get authorized by the authorization server on your side in order to pass the bearer token to Okta. This would be in short how the Sign In with App feature works.