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.
Please sign in to leave a comment.
5 Comments