Client Credentials fail with Role API

[doernbrackc (Chris Doernbrack)]

I have been working with API for quite a while using client credentials and have not run into any issues until now. I am trying to the POST role api to create a role and it works just fine with a PAT token but we are using client credentials. Every time I try the client creds I get a 403. The same happens for a PATCH using the role api.

message": “Method failed: (/v3/roles) with code: 403 - Forbidden username/password combo\n{"messages":[{"localeOrigin":"DEFAULT","locale":"en-US","text":"The server understood the request but refuses to authorize it."},{"localeOrigin":"REQUEST","locale":"en-US","text":"The server understood the request but refuses to authorize it."}],"detailCode":"403 Forbidden","trackingId":"a96a1e6eab6e45409768cd31339c8dbf"}”

This same credential works fine for things like get role. I took a look at the documentation and I have all the necessary scopes. I even added the “all” scope to try to eliminate possibly missing one. What I am missing? Why does it only work with a PAT token yet the client credentials work some of the calls.

[chris-hogan]

Hi Chris,

Some API endpoints simply require a PAT to be used by nature. You can read more from SailPoint and other ambassadors about this topic in this thread:

API Scopes Not Working Broken Feature

Scopes are intended to scope down access on PATs to create tokens with the least privilege necessary to fulfill their functions: The vast majority of ISC APIs require ORG_ADMIN user level, and that user level context can be provided by a PAT with the client credentials grant flow or by a user actively logging in with the authorization code grant flow when generating a token. We understand the frustration with this requirement, and we hear the feedback loud and clear to provide application ba…

Personally, I manage this constraint by creating a service account identity under a delimited file source for which I generate PATs under as if they were client credentials, that way I know that identity will not get offboarded and the PAT is not linked to a real identity. Then the login credentials for the identity can be managed in the organization’s PAM tool.