API tokens: security and permissions?


3 Kommentare

  • Sebastiaan Wijchers
    Community Moderator

    Hello Chris,

    I think you already know the answers, but just need confirmation? :)

    Anyway, here they are:

    1. Yes
    2. The role of the user whose email address was used in the authorization.
    3. No

    With kind regards,

    Sparkly ⭐

  • Chris Hall

    Thanks Sebastiaan,

    Maybe we've been doing the API token thing wrong the whole time (?). The tokens we create (for API calls) are under Admin > Channels > API > Settings > Token Access > [ + ]. The only options are to add an "API Token Description", and nothing that would tie a token to the "role of the user whose email address was used in the authorization."

    Thanks again!

  • Dan Ross
    Community Moderator

    Hey Chris,

    Unfortunately, you're correct. There's nothing tying a token to a specific user, or to a set of permissions. Treat API keys like a universal password to whatever username is passed along with the key during login. 

    If you gave an agent a token, nothing stops that agent from changing the username they authenticate with to one of another user. When they do so, they log in as that user, along with associated permissions. Actions taken via the API will be attributed to the user that authenticated with the key.


    You (an admin) give me (an agent) an API key. I want to delete a ticket for some reason, but that permission is set to require admin access in your Zendesk. Using the same API key, I change my username to your email and send the DELETE request. The request will process, as your account has permission. In the event logs, the deletion will be attributed to your user.

    In short, you probably don't want to give API tokens to users that you don't trust with administrative access to your instance. It would be very difficult to identify misuse, as the actions would be attributed to another user.

    A possible workaround would be having a user create a Basic Auth string to use, with their username and a password. This would let them access the API in a custom script (but perhaps not a prebuilt integration that is expecting an API key), but would be locked to their account and permission set. However, if you have a password expiry/rotation configured, this would need to be rotated as well. This is less than ideal, but probably better than giving out API keys.



Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.

Powered by Zendesk