Zendesk APIs - Token Security
Currently today Zendesk API Tokens do not offer enough security to allow non-admin teams to have access to tokens. As Zendesk does not validate a specific user to a token, or what a token has permission to do, all tokens are Admin level.
This is caused by a user only needing to know an admin email address and the token. If they replace their email with the admin email, they are now an Admin instead of the role that was designated to their user.
-
Hi Jay, that is correct...API tokens are meant to be a quick way to implement admin-level authorization at the token level. You should never share account credentials, whether or not it is an API token or a password, for an agent, admin, or end user. Additionally, API tokens do not require a specific email address to utilize, as it is the token itself that is providing the scope, not the user.
If you're looking to provide scope to your tokens, I would recommend utilizing an Oauth token instead, as that would give you the granularity that you are looking for here.
-
But for a user to generate an OAuth token that matches their user and scope, we would need to enable password API auth. This would allow all users to generate a token during this time period.
Would your recommendation be as an Admin to leverage an API token and generate a user a personal OAuth token and scope then provide it to them?
The concern still comes back to ensuring that ticket visibility does not reach past that specific users Groups. Where as I have seen if I am generating this, will it carry my visibility or theirs.
-
It sounds like your use-case is requiring password grant type for OAuth, which is usually a more complicated scenario to dive into recommendations for. Could you tell me about the use-case for this scenario so that I can get a better idea of what you might need?
-
I agree, this is a security risk.
All it takes is for one malicious/disgruntled former employee who has a token from their organization to know who the admins are and use their emails in combination with the token to do serious damage.
API access permissions should set based on need on tokens themselves and not admin level for each and every token.
This also prevents creating integration specific tokens that can read and write to only specific endpoints. If I have an integration that needs to pull ticket_audit info but doesn't need to make user changes, there should not be a need to grant a full admin user account just for that API access. -
I wish Zendesk would finally replace the classic API tokens approach with a modern one!
Provide the existing https://developer.zendesk.com/documentation/ticketing/working-with-oauth/creating-and-using-oauth-tokens-with-the-api/ oauth functionality in an UI for admins to be able to generate personal access tokens which are limited to a dedicated user and desired scope (e.g. read and/or write and additionally limited by resource as in https://support.zendesk.com/hc/en-us/articles/4408845965210#topic_gql_kbd_gt).
This reminds me of the approach taken by GitHub which is IMHO still the most convenient and secure one out there and should be evaluated by Zendesk API experts. Please refer to https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token.
-
Greg Katechis, is a part of this the expectation of API calls need to be associated with a paid license? For our API integrations, it seems dangerous to attach the calls to a token of the Account Owner, but it also seems needlessly expensive to buy a license just for making API calls.
An option to provision API keys, which are not associated with individual users, would be great to see Zendesk add.
-
Hi Eric! If you are creating an integration, I would highly recommend exploring OAuth options, however I understand that there may be a void in our product in between API tokens and OAuth for your use-case. For some companies, dedicating an "API user" isn't something that concerns them much, but we definitely would never expect you to feel like you're spending money unnecessarily. I realize how silly that sentence sounds, so maybe I should change it to "I would never expect you to" and it has never been something that we've said needs to be done. On the flip side, because of the potential void, it might feel like that, which I get.
To that end, could you let me know if OAuth would work for you and if not, could you share your use case? I can then take that (along with all of the other comments) and pass it along internally to the right team.
-
We had reviewed the OAuth flow (https://support.zendesk.com/hc/en-us/articles/4408845965210) as part of our Zendesk onboarding, and our dedicated Zendesk rep recommended the API token flow instead.
We have several use-cases. A recent one, being tracked within ticket 11569387, has to do with triggering ticket escalations. There's an automation rule that finds the ticket needing escalation, and it attaches a tag. That tag attachment triggers a webhook, and the webhook does an API call to create a side conversation. All of this is automated, so the user grant step makes OAuth a non-starter.
Please sign in to leave a comment.
8 Comments