Hi,
I am trying to use an access token generated using oauth client id and secret but and i am able to do it but while using it to authenticate an API i am receiving following error
Invoke-RestMethod : {"detailCode":"403 Forbidden","trackingId":"aeeb3806acad443fb4b15da929d748e5","messages":[{"locale":"en-US","localeOrigin":"DEFAULT","text":"The server understood the request but refuses to authorize
it."},{"locale":"und","localeOrigin":"REQUEST","text":"The server understood the request but refuses to authorize it."}],"causes":[]}
What needs to be changed so it can be used to authenticate the API?
My main requirement is to provide authentication to api without being dependent on any individual’s pat credentials(as they will have to be changed once that person leaves organization) and without giving admin roles to service or robotic accounts. I will be glad to receive any inputs on this
I think I need a little bit more information here before I would be able to identify exactly what the issue is.
Can you provide some clarification around what OAuth flows you have enabled on this OAuth client configured in your tenant?
The OAuth Flows docs are here:
Additionally, I see you are making the Rest call using the PowerShell method, but how are you implementing the larger flow? Is this a full solution or script written out in PowerShell?
This is expected behaviour. You are trying to use client id and secret which are under Global → API Management. Those would not work for most of the new API and have been depreciated if I am not wrong.
You ideally should use PAT which are generated under service/bot accounts. This makes it easy in terms of audit in case you see something suspicious activity done. If you are using id:secret from API management , there is no way to correlate them to specific identity so you would not have audit for the action performed using those id:secret.
@chirag_patel generating PAT token for service/bot accounts will require us to give admin privileges to those account which won’t be possible in current scenario. As far as I know PAT token generated for an individual will be removed once his admin account is deleted
@chirag_patel OAuth credentials generated from the API management page are not deprecated. They are useful for creating web auth flows where your application requires the user to login to their account with their username/password in exchange for a token.
Personal Access Tokens are typically ideal for service/bot accounts since they don’t require a manual login. You do not have to grant an account the Admin user level in order to leverage PATs. Any user can generate a PAT with their respective user level permissions.
@colin_mckibben If we are using PAT to do API call which require reading data such as get certification or api which generate a campaign. It will require the account(from which PAT credentials are taken) to have admin credentials right? or will it work if pat is generated from non admin service/bot accounts.
Please see the documentation on user levels. It might be possible to assign your service account the “Cert Admin” user level, which will grant that account access to the APIs it needs to manage certs, and nothing more.
We also just announced scopes for PATs, which will allow you to fine tune the access that your PATs are granted. This is a very new feature, however, and we are still working on adding scopes to all of our endpoints.