Problem with token creation

[s_tartaglione (Salvatore Tartaglione)]

Hello everyone, I’m creating a workflow that has some HTTP blocks that performs some actions, like the HTTP request that makes the GET identities. The problem is that if I use the client ID and client secret generated by an admin for authenticating the request, the requests work fine. If I create a token in global>security settings> API management with the voice “sp:scopes all” as the token that has been generated by an admin, some API like the get identities/:id is not working and returns “403 unauthorized”. I noticed that there are some APIs that work and other one that returns me “403 unauthorized” . The ones that are giving problems are:
GET https://tenant-sb.api.identitynow.com/v2024/identities/:id GET https://tenant-sb.api.identitynow.com/v3/access-request-config PUT https://tenant-sb.api.identitynow.com/beta/identity-attributes/adDn .
I want to know which is the problem and possibile solutions.

[kdfreeman (Kapil Dahal)]

Hi Salvatore,

You need to create Personal Access Token with necessary scopes and user level to access API. If you go with API token, they may not be able to access all api. Refer this thread.

Difference between API Keys and Personal Access Token

Dear all, If you ever have to use Client ID and Secret in a script, what whould you choose, API keys or Personal Access Token? For my part, I’ve read this article and still can’t answer the question. But, so far, I see one caveat for the Personal Access Token, is that we need to create a service account for it, meanwhile, no need for a specific user to manager API keys. Please correct me if I’m wrong. Thanks.

the API token with client credential grant type does not have a user linked to it. This type of token will not be able to call all the IDN REST endpoints. For example, the role revocation API end point /v3/access-requests will give a forbidden error while using the client credential as this end point excepts the call only from a valid user which makes sense from a audit and security standpoint.

The PAT token on the other hand is also of client credential grant type but associated to a user. The PAT associates the user that created the PAT to the generated access tokens, giving those tokens the same user level as the user that created it. So if you are an Admin user and you generate a PAT with `sp:scopes:all` , your PAT can access **almost** every API endpoint.

Thanks

[s_tartaglione (Salvatore Tartaglione)]

in my case I have an external portal that has to call the Sailpoint APis, so I have to use a PAT to let the APIs to be authenticated? And which kind of user i have to link to that PAT? what if the user will be disabled in future?

[amankumargupta (Aman Gupta)]

An API key in SailPoint ISC is not associated with a specific user identity, whereas a Personal Access Token (PAT) is tied to the user who created it. For automation or integration purposes, you can create a service account and generate a PAT from it to ensure the actions are associated with that account.