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.
This is a bit of a gray area from my perspective because I believe there are certain API calls (I don’t have any specific examples at the moment) that require a user context which is only in the PAT. There’s a LONG history to API keys / PATs that’s been a winding road over the years, so we generally still default to a service user with PAT vs. using the API key.
2 Likes
Alright, thanks @edmarks , I’ll use PATs with a service account, but as soon as someones confirms that API keys are pretty the same thing, I’ll switch. I’m still interested btw to know what differences there are between them, if anyone has any reference, please share 
{{baseUrl}}/workflows is an example of a BETA API call that appears to fail with the API key but is successful with the PAT.
I was looking at the documentation for the V3 API’s and they specifically note “API” and “ORG_ADMIN” in many of these. I found a couple that only listed “ORG_ADMIN” but they appeared to work with the API KEY also, so the confusion lingers.
2 Likes
From my understanding, 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.
While observing the response of the authentication call using a PAT and client credential token you can observe the difference, while PAT authentication response provides identity id and user name info, client credential token does not provide this.
1 Like
@anujoseIC , that’s clear, thanks for the reply.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.