We require a detailed analysis of the API Management section within the Security Settings of Identity Security Cloud. Specifically, we are looking to understand the behavior and usage of newly created Grant Type entries—how they are intended to be used, where they are stored within Identity Security Cloud, and whether they can be retrieved through any ISC‑related APIs. Additionally, we would like clarification on whether these newly created grant types are incorporated into the Personal Access Tokens within ISC.
Use Case:
We created a Personal Access Token (PAT) with the scope “sp:scopes:all” and obtained the corresponding client ID and client secret. Similarly, we created a new API client from the API Management tab using the same scope “sp:scopes:all” and the Client Credentials grant type, and received its client ID and client secret as well.
When testing the connection to the target system using the PAT client credentials, the connection succeeds. However, when attempting the same connection using the client credentials generated through API Management, we receive the following error:
“The server understood the request but refuses to authorize it” HTTP Status: 403 Forbidden
We would like to understand why the behavior differs even though both configurations use the same scope. Does anyone have insights into why the API Management client credentials are being rejected while the PAT credentials work as expected?
Easier explanation would be you can see all API Token generated in your tenant by others and manage it, but you can’t see the PAT token generated by other administrators.
Certain API calls can be made only using the PAT token.
Think of it this way: when you use a PAT, SailPoint sees a real admin behind the request, someone it can trust to touch sensitive things like sources and connectors. When you use API Management client credentials, it looks like a background application trying to do the same job. Even though both ask for the same scope, SailPoint is stricter with apps and doesn’t let them perform source-level operations. So the request is understood, but politely refused. That 403 isn’t an error in your setup — it’s SailPoint protecting critical end points.
I attempted to use the Get List Identities API with both a Personal Access Token (PAT) and the credentials generated through API Management. I would also like to understand the intended purpose of the API client created through the API Management tab and the typical scenarios in which it is meant to be used.
Thank you for your response. I would also like to gain clarity on the intended purpose of the API client created through the API Management tab, including the typical use cases for this type of client. Additionally, I am seeking to understand which Identity Security Cloud features are compatible with the credentials generated through API Management.
Thank you for your response. Could you please provide additional clarification on the following:
We are seeking a detailed analysis of the API Management section within the Security Settings of Identity Security Cloud. In particular, we would like to understand the behavior and intended usage of newly created Grant Type entries—how they function, where they are stored within ISC, and whether they can be accessed through any ISC‑related APIs. We also request clarification on whether these newly created grant types are incorporated into Personal Access Tokens within Identity Security Cloud.
Personal access tokens are associated with a user in Identity Security Cloud and relies on the user’s user level (ex. Admin, Helpdesk, etc.) to determine a base level of access.
To see which token is required to call the API, you can check the API documentation. Below is one of the screenshot,
Yes, the request works successfully when using the Personal Access Token. However, when using the credentials generated through API Management, we receive a 403 Forbidden response.
On a high level, API token with client credential grant type doesn’t have a user assigned to it. It is basically for creating OAuth clients with various grant types. It did not have permission to call all the ISC API endpoints. You can create a token with auth code grant type which requires a user login to generate a token and the token granted based on their user level and it determines which API it can access.
The PAT is associated with a user, and it is unique to a user. It is a OAuth2 token that only has the client credentials grant type, and the tokens will give you the same user level access as the user that created it. Check more information here Authentication | SailPoint Developer Community.
On the endpoints and the access, whatever the endpoints required the user context for authorization and auditing needs to know who is making the request and it requires PAT. The endpoints don’t have this requirement works with API client credentials. Unfortunately, we do not have any document which lists the APIs that requires user context.
Let me step back and say that a single official document would be a great resource to have to make a decision. I know it is in the API level documentation and it make sense to have it in such a way, but it is always good to have a list in a single document considering different auth type.
