Zendesk APIs - Token Security

8 Kommentare

  • Greg Katechis
    Zendesk Developer Advocacy

    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. 

    0
  • Jay Nelson

    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.

    0
  • Greg Katechis
    Zendesk Developer Advocacy
    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? 
    0
  • Asaf Max

    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.

    0
  • Eike Thienemann-Dehde

    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.

    1
  • Eric

    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.

    0
  • Greg Katechis
    Zendesk Developer Advocacy

    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.

    0
  • Eric

    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.

    0

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

Powered by Zendesk