Are API tokens user specific or account wide?

Have more questions? Submit a request

17 Comments

  • Pat Prince

    Just to clarify - if the user account of the Administrator who generated to the token is disabled, does the token remain usable or does it get disabled also?

    0
  • Dwight Bussman

    HeyO Pat,

    The API token itself remains active even after the user is deleted. 

    Note: if you are using the token with that former admin's email address, it would cease to work once that user no longer had permissions (whether suspended/deleted/demoted).

    As another point of clarification - OAuth tokens do not behave the same as API tokens. When an agent is demoted/deleted, OAuth tokens  for that user are automatically destroyed.

    Please let me know if I'm failing to describe this well enough or if this helps to answer your question!

    1
  • Dan Ross

    Are there plans to allow for restricted API tokens? Either by user or by access?

    While API access is role-restricted, there's nothing stopping an agent with an API key to change the username to an admin's username and then access admin-only endpoints. 

    0
  • Daniel Cooper

    Hi Dan, 

    I agree, that it would be nice to lock down tokens further.  My team mostly has individual tokens for ourselves so that each of us has our own token that is unknown to others.  If we leave the company, we can disable the token and know that it isn't shared with others.  Of course, this doesn't always work out as we have system integrations that need a token as well and I'd love to be able to see access to that token to monitor for unexpected behavior.  For example, if I saw an unauthorized agent use that token to access the API, I'd love the ability to blacklist the user from using that token - but you bring up a valid point.  All an agent has to do is enter a different email address in to access the API again with the token.  

    1
  • George Azzopardi

    Hi,

    interesting to note above.  I have an issue with a customer who wishes to use the Api token to access tickets from his organisation only.  Is there a way this could be done?  

    Example, can I create a token with a user who is an administrator but then later downgrade the user to an agent to limit the access to his group only?

    Is this possible?

     

    Thanks

     

    0
  • Dwight Bussman

    Hi George,

    If that API token is used with a specific user's email address, it will inherit their level of permissions. If the user only has access to view tickets within their organization, it will grant them the same access via the API. The permissions in that case don't follow the token so much as the user to whom it's applied. 

    Please let me know if this helps to answer your question or if there's something more I can clarify. I'd be happy to create a ticket for us to chat if you'd prefer a more private communication or a phone call.

    Thanks

    0
  • Dan Ross

    Hi George,

    I feel it's worth explicitly stating that giving a customer an API token to your Zendesk is a security risk. They function as passwords to the account they're applied to. There is nothing stopping them from using the account email for you or a member of your team and then gaining elevated access beyond what their end user role would offer. Because of this, API keys as they currently stand should be treated as potential admin level access tools.

     

    It's also important to know that if someone did this, any actions they took via the API would appear as having been done by that user. I'm sure you wouldn't bulk delete all your tickets in your account, but a malicious person with your email address and an API key could certainly make it look that way. 

    The safest solution would be to set up this integration using OAuth, as the authentication is tied to the user in that case.

    0
  • Dwight Bussman

    Good point, Dan. I should've read that request more carefully - I thought it was being used to pull information on behalf of some agent, rather than giving them this token so that they could access things directly. Definitely better to use OAuth in that case.

    0
  • Ankit Dahiya

    Hi Dwight,

    Any idea on what would be best way to generate Oauth tokens ? I am trying to integrate Zendesk with Zapier which works on agent tokens, need Zapier to create zendesk tickets from another tool. 

    Does this apply ? https://developer.zendesk.com/rest_api/docs/core/oauth_tokens

     

    0
  • Dwight Bussman

    Hi Ankit

    The documentation you shared above is a good starting point. I would also recommend having a look at these articles:

    That having been said, if Zapier has been configured to work with agent tokens, an OAuth token will not function in the same way.

    Please feel free to reach out to support@zendesk.com if you have further questions or would like to discuss the specifics of this in more detail!

    0
  • George Azzopardi

    HI Dwight,

    I'm working with Ankit from Zendesk side and the is the first time I'm using Oauth tokens also.  We need this for an external app ONLY to create and answer to ticket for ONLY two organisations.  The api should have no access whatever (No read/write access to other Zendesk data).  Is this possible using OAuth tokens please?

    0
  • Bryan Flynn

    Hi George. It sounds like there are a couple of things in your request:

    1. How to limit a user's ticket access to those tickets in certain organizations

    2. How to authenticate that user

    ++++

    For #1:

    You can create a user and limit them via their role to only tickets within their organizations. This is set in the Role's page under Admin > People > Roles.

    Edit their Role (or create a new one) that limits their access depending on what you need:

    For #2 on how that user authenticates in:

    If this is going to be a dedicated external service, you may want to consider using a special "service" agent user, which is only used for this operation. You can then create a dedicated "service" role, assign this "service" agent user to that, and then just have that service agent authenticate in with its password.

    Another option would be to create an "OAuth token" (as described in previous posted links) and use that to authenticate in versus a username/password. One advantage is that you can set the scope of the OAuth token to "ticket:read ticket:write", so it can only access ticket information and nothing else. #1/Role will limit them to just tickets in their organization AND the OAuth token will limit them to just ticket reads and writes.

    Yet another option is to use an "API token" instead of a password. You won't get the limited ticket read/write scope that an OAuth token could offer, but you also won't have to use the user's password or create an OAuth token, which may be more flexible from a maintenance point-of-view.

    What determines the path you take is up to you and depends on your needs. The main point is that you have a number of options -- some may be more appropriate than others depending on your situation.

    0
  • George Azzopardi

    Hi Brian,

    the best option right now would be just the token and restrict user roles as we have an API already built for this however

    I have tried testing access to this using the token but found some access issues.  I also have a support ticket open for this (https://support.zendesk.com/hc/en-us/requests/3791079).  See my last comment below which describes my testing:

    I created a token on our sandbox to be used with an external API. I created this using just token access (NOT with OAuth Clients). With this API, I can extract and view all users, groups and organizations for from Zendesk. I can do this from the API with the user left as an Administrator.

    I downgraded the user (which I created the token with) to an agent. The agent is assigned to only one group and is set as in attached screenshot.

    I tried to extract users and get the below exception which is correct and as expected.

    I tried to extract organizations and I get NO exception this time which is NOT correct and NOT as expected.

    I tried to extract groups and I get NO exception this time which is NOT correct and NOT as expected.

    Extract Users exception:
    [2018/07/10 02:45:38] Client error: `GET https://cwsupport1488798197.zendesk.com/api/v2/users.json?page=1&per_page=100` resulted in a `403 Forbidden` response:
    {
    "error": {
    "title": "Forbidden",
    "message": "You do not have access to this page. Please contact the account (truncated...)
    [details] {
    "error": {
    "title": "Forbidden",
    "message": "You do not have access to this page. Please contact the account owner of this help desk for further help."
    }
    }

     


    0
  • George Azzopardi

    Brian,

    Additional to above, I tried extracting tickets and this works correctly and I can see only tickets from the user's group.

    So the only issue I see is why I can view all groups and organizations!  Is there something configurable which I need to change?

     

    Thanks a lot

    0
  • Bryan Flynn

    Hi George. Sounds like you're getting closer to what you want.

    Given the number of account specific details here to consider, I'm going to ask that you defer to the ticket that you submitted. Please make sure the above information is in your ticket and our support group will take it from there. Exposing any more account specific details that may be needed should not happen in the community. Thanks for you understanding.

    0
  • George Azzopardi

    They details are in the ticket.

     

    Thanks

    0
  • Bryan Flynn

    Regarding Dan and Daniel's comments above, a request to clarify the documentation on these points has been submitted.

    There are different use-cases for the different ways to authenticate into Zendesk Support. It's definitely agreed that depending upon needs, API tokens may or may not be the best approach. Understanding how to handle them is also important, which is what the doc clarification request asks to do. Thanks for raising these points guys.

    0

Please sign in to leave a comment.

Powered by Zendesk