Getting an OAuth access token for testing purposes

Have more questions? Submit a request

14 Comments

  • vitaliy.bondar.tvorovskiy

    Is there a way to create token using this endpoint for a non-admin user?

    0
  • Brian Manning

    @vitaliy - The token creation endpoint is only available to admins. If you have questions on the authentication flow for an app or service you're working on feel free to open up a ticket and we'll assist. Cheers!

    0
  • Chris Nicholson-Doyle

    The most well written and simple to follow Zendesk article I have read. Great work!

    1
  • Jessie - Community Manager

    Thanks, Chris! I'm glad you found it useful. :)

    0
  • Karl Kerem

    The user interface has changed for creating an OAuth token, there's no link anymore to get the client ID via the link. Also, the List Clients endpoint of the OAuth Client API doesn't list our newly created OAuth client.

    What are the new steps for finding out OAuth client ID so that we could create a new token for it with desired scope?

    0
  • Bryan Flynn

    Hi Karl -- looks like you're talking about wanting to grab the OAuth Client's internal ID value from the UI -- agreed, it doesn't look like that ID value can be picked up in the UI -- sorry about that.

    However, the List Clients API call should be listing out all your OAuth Clients listed under Admin > Channels/API > OAuth Clients, along with their corresponding IDs (and just to be complete, creating a new token via the API is documented here - note that client_id is the numeric id of the OAuth client, not the client's identifier).

    If you're not seeing all your OAuth clients via the List Clients API, please do a hard refresh and make sure you're getting the latest. If you're still not getting all your OAuth clients listed, probably best to open a ticket via support@zendesk.com, so it can be investigated further.

    Please share any additional info or resolutions here. Thanks!

    0
  • Chris Adams

    @Karl you can still get the client id if you know how to open up the network tab in Chrome and inspect the network call to clients endpoint and inspect the JSON response.

     

    @Bryan, does this article still work if you are using Single Sign On? I don't know what I can use for the password argument.

    0
  • Bryan Flynn

    Hi Chris. Unless you've disabled passwords (admin/settings > security > admins & agents tab / Passwords Disabled is checked), you should still have a username/password associated with your account and can use that.

    If not, then you could enable it for this exercise.

    Or you could generate an OAuth token using a grant flow (see Using OAuth authentication with your appplication). Then you could use the OAuth token in an Authorization header instead of specifying a username/password combination -- example: curl -v -H "Content-Type: application/json" -H "Authorization: Bearer 5888a...."  ...

    An easy way to generate an OAuth token is to:

    1. Go to https://developer.zendesk.com/requests/new

    2. Click 'OAuth Implicit Grant', enter your Zendesk subdomain, and click 'Authorize'

    The value that appears to the right of the 'Authorize' button is an OAuth token. You can copy that full string and use it in your cURL call as shown above. But be careful, that token is essentially a key into your Zendesk account. You'll want to protect it similar to a password.

    Hope this helps!

     

    1
  • KC Baltz

    Please edit this article to put Bryan's "An easy way..." at the very top.  This is the only way that works without an admin's help and I have so far had no success working the methods described elsewhere.  I got as far as the Grant Flow (since we are in an SSO environment) but the code that was returned was always rejected when I tried to get a token (The provided access grant is invalid, expired, or revoked (e.g. invalid assertion, expired authorization token, bad end-user password credentials, or mismatching authorization code and redirection URI))

    0
  • Nicole - Community Manager

    Thanks for that feedback, KC. We've passed your comment on to the documentation team.

    0
  • Charles Nadeau

    Hi KC,

    We cover the same information in an article in the Develop Help Center. I added the option of using the API console to that article:

    https://develop.zendesk.com/hc/en-us/articles/360001074348#quick

    I also added a link to the option in a tip in the introduction of this Support tip.

    Thanks.

    0
  • KC Baltz

    Thanks Nicole and Charles.  That's perfect. 

    As a follow up to anyone else trying the Grant Flow, my issue turned out to be that the value for "redirection URI" that I was using didn't exactly match (missing a trailing slash) the value provided when I set up the Client.  I suggest copying and pasting this value.  I think it's less important what the value is than that it match exactly.  

    1
  • Dru Kepple

    I'm a little confused. I hope it's just me not fully understanding things.

    The premise of this article is to use an OAuth token for API calls so that those API calls are not associated with a specific user.  But if an OAuth token is exchanged for a normal user/pass authorization, isn't the token associated with a specific user?  That is, you, the requester?

    I thought these tokens were unique to a user, so while the technique of generating a token without setting up a whole OAuthed app is helpful, I read this article on the presumption that I could "build... an internal application" where I do "not want your API requests to be associated with a specific user". Quotes from the very first sentence of this article.

    Am I misunderstanding OAuth tokens? Or the intent of this article?

    0
  • Bryan Flynn

    I see what you mean Dru. You're right. There is no "non-user" or system-type OAuth token. They are always associated with a user. I'm going to guess at the author's intent combined with what other customers have done, which is to create an "robo" agent that these tokens are created under. When the token is used, it's not against a particular user and no passwords have to be exposed.

    You also gain the benefit of being able to revoke the tokens under this special user without affecting actual users. Since the title of the article is to create tokens for testing, this scenario might fit better.

    0

Please sign in to leave a comment.

Powered by Zendesk