Hello @MatthewH.10249 (State of Iowa)​ Thank you for posting on our Community page!

While I have checked internally to see if there are some known issues, I was unable to find any provisioning related issues. I would recommend to open a case with Okta Support as they have access to internal tools and they can review back-end logs to further investigate this issue and get to the bottom of this matter.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.

Thanks for the feedback. I did open a Support case as well. I'll update this community post with whatever I find out from them. We also opened a support case with Salesforce and they did respond with the following.

"Salesforce does support client credentials, but only if you enable it explicitly on a connected app. In that connected app you turn on “Client Credentials Flow,” set a “Run As” user (usually an integration user with restricted permissions), and make sure you use your own domain, such as https://yourorg.my.salesforce.com/services/oauth2/token, as the token endpoint instead of the generic login URLs. The access token you get from that flow can then be used to call the Salesforce SCIM API to create, update, or deactivate users.

The tricky part is that Okta’s SCIM app doesn’t always let you customize things the way you need. In some cases, you can point it to your Salesforce MyDomain token URL and everything works. But in other cases, Okta simply doesn’t support the client credentials flow for SCIM at all, which means you need a workaround. A common solution is to slip a small proxy or “token broker” in between. Okta still thinks it’s talking to login.salesforce.com, but the proxy actually handles the client credentials handshake with your MyDomain, grabs a valid token, and then passes the SCIM calls along to Salesforce. It’s an extra moving piece, but it keeps you within security policies that block the use of the generic login endpoints.

The practical steps that most people follow are to first configure the Salesforce connected app with client credentials, then test the token issuance manually using the MyDomain endpoint to make sure the flow works. After that, they configure Okta’s provisioning settings, ideally pointing directly to the MyDomain token endpoint if the template allows it. If it doesn’t, they either add a proxy layer or use a static token. Once that’s in place, you test SCIM operations, listing users, creating users, deactivating them while monitoring, how tokens are issued and refreshed."

Okta support provided us the following "Knowledge Base" article and the value we had set for "Callback URL" (see step #2 - b - iii) was not the value correct. When we changed the value in Salesforce "https://system-admin.okta.com/admin/app/generic/oauth20redirect" it took awhile for cache to sync but by the next day it worked. When I say "worked" I mean that we were able to press the "Authenticate with Salesforce.com" on the Okta Provisioning tab page for our Salesforce app and it opened a popup window with a Salesforce login screen. We had to click the “Use custom domain” link on that popup page before entering the service account we created username and local Salesforce password. We had to grant that Service Account elevated permissions in order for SCIM APIs to run under that account.

https://support.okta.com/help/s/article/Configuration-Guide-for-Salesforce-REST-Integration?language=en_US