Using OAuth authentication with your application

Have more questions? Submit a request


  • Bryan Flynn

    Hi James. This article talks about the general OAuth grant flow for getting an authorization token to access the Zendesk Support product. We don't have any specific guidance if moving from the SalesForce solution you mention, however.

    If you have specific questions related to OAuth and Zendesk, we can work on answering those. Also, if you want to share your use case, maybe some additional information can help.

  • James Lertora

    Hi Brian,

    Thank you for the quick response! 

    We host files for download on apache server, but require auth for users. We have links in Zendesk pointing to these resources, but again need to be authenticated. So the link in Zendesk could relate to "First Use" in the diagram above, I think. Any pointers will be helpful. Thanks again.

  • Bryan Flynn

    If you're already authenticated into Zendesk Support product's agent interface, clicking on links inside ticket comments that lead to your asset server, that would be one scenario. This article might give a different perspective for that scenario (not necessarily an exact solution for you, but closer to this use case): Using OAuth to authenticate Zendesk API requests in a web app.

    If you're accessing these assets via an Apps framework app, that would be a different scenario and would benefit from secure settings.

    If these points still don't hit the mark James, I suggest reaching out to with more details related to your account and use cases and we can dig into more details there. Hope this is at least a step in the right direction.

  • Colin Smith

    Hi, I was hoping to use the client-credentials grant type, but that isn't documented here, is it supported?

  • Bryan Flynn

    Hi Colin,

    The OAuth client credentials grant type isn't supported in Zendesk Support.

    Zendesk Chat does support it, however. There are specific setup steps needed. Instructions are here: Implementing an OAuth authorization flow.

    Because there is no "non-agent"/system type user, any token created always belongs to a specific agent or admin. This means any actions made with that token will appear to be done by the user who created the token.

    Hope this helps!

  • Matt Frowe

    Is there any way to style the Zendesk Authorization page (where the user chooses to grant or deny access)?

  • Nicole - Community Manager

    Hi Matt -

    The Authorization page is not customizable. Several users have requested this, but the product team determined that it was not something they were going to open up for customization at this time.

  • Max McDaniel

    Hi there, struggling to wrap my mind around API/OAuth here. We're evaluating a 3rd party tool integration who is requesting API access. With the understanding that this grants them unlimited access to our Zendesk instance, looking for a way to limit this authentication access. It seems like OAuth may be a possibility, but not clear exactly how it works. 

    Ideally we'd want to provision read-only access to CSAT response data, but permissioning doesn't seem to be that granular. Any thoughts?

  • Bryan Flynn

    Hi Max,

    There are a number of ways to authenticate into Zendesk and it's not always clear what they all are and when to use a particular option.

    "API Tokens" (Admin > Channels/API > Settings/Token Access) act as a substitute for passwords. If you know the value of an account's API token and know an email in that account, you can combine the two (<tokenvalue>) to act under that particular user. Because they are so flexible, they should really only be used in a secure environment such as a backend server or within a script that has limited access.

    "OAuth Tokens" are generated under a particular user against an "OAuth Client" (Admin > Channels/API > OAuth Clients). Once generated, these always act under the user they were generated under. They should also be protected to some degree as they act as a "key" for that user to get into Zendesk. If an administrator generates a key for themselves, then that key has administrator rights, and so on with agents and end users (each having the respective rights their profile allows for).

    As you noticed, OAuth tokens can have scope as well. Scopes are documented here: If you want to limit scope and have the access key always be for a particular user, you should use OAuth tokens.

    Scope granularity, however, is not that fine. You may have to find a different way to access only CSAT data in a read-only way.

    Here are a few good articles that talk about authentication, too:
    Having the talk: Am I ready for a more advanced authentication option?
    Creating and using OAuth tokens with the API
    Authentication for API requests
    Generating a new API token

    Hope this helps get you to your next step.


Please sign in to leave a comment.

Powered by Zendesk