We just flipped the switch on SAML SSO for our CXone org. Human login works fine, but our backend services are getting kicked out.
Trying to grab a token via the standard client_credentials grant. Getting a 401 Unauthorized back from /api/v2/oauth/token.
Here’s the payload we’re sending:
{
"grant_type": "client_credentials",
"client_id": "my-app-id",
"client_secret": "super-secret-key",
"scope": "admin:api"
}
The error response is pretty generic:
{
"code": "unauthorized",
"message": "Invalid credentials"
}
I’ve double checked the client ID and secret. They’re valid. The app is still listed as active in the admin console. Since SAML is now enforced, does that kill the client_credentials flow entirely? Or do we need to add a specific SAML assertion to this request?
Dropping a quick cURL test for reference. Same result.
curl -X POST https://api.mynice.com/api/v2/oauth/token
-H “Content-Type: application/json”
-d ‘{“grant_type”:“client_credentials”,“client_id”:“…”,“client_secret”:“…”}’
Any ideas?
You’re hitting a 401 because enabling SAML SSO doesn’t automatically disable basic auth for API clients, but it often triggers a security policy update that requires explicit client secret validation or changes the allowed grant types if the app wasn’t configured for machine-to-machine auth initially. Check your application settings in the admin portal. Specifically, look at the “OAuth 2.0” tab for your app. Ensure “Client Credentials” is actually checked as an allowed grant type. If it’s not, the endpoint rejects the request outright.
Also, double-check that your client_secret hasn’t been regenerated or rotated recently. It’s a common mistake to copy an old secret from a config file without realizing the app was re-authenticated in the UI. If the grant type is correct and the secret is valid, the issue might be related to how the headers are being sent. The API expects application/x-www-form-urlencoded, not JSON, for the token request body. Sending JSON to /api/v2/oauth/token will fail silently or return a 401 depending on the server state.
Here’s the correct curl command to test this locally. It uses the proper content type and form-encoded body:
curl -X POST "https://api.mypurecloud.com/api/v2/oauth/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=my-app-id&client_secret=super-secret-key&scope=admin:api"
If this works, your code is likely sending the payload as JSON (application/json) instead of form data. Fix the content type header in your backend service. If you still get a 401, verify that the admin:api scope is actually granted to this specific application in the permissions list. Sometimes bulk permission updates strip custom scopes. Check the “Scopes” section for your app ID.