Get access token with password grant type

Answered

10 Comments

  • Sutrisno Suryajaya
    Comment actions Permalink

    Hi Jorge,

     

    May I know whether your account have a Zendesk subdomain (i.e. <subdomain>.zendesk.com)? If yes, it'll be helpful if you can provide them. If not, can you provide the email of one of the agent inside your account?

    And which guide are you following in creating the access token? Is it https://developer.zendesk.com/rest_api/docs/chat/auth

     

    0
  • Jorge Tapia Hierro
    Comment actions Permalink

    Hi,

    Yes, I'm trying with a Zendesk subdomain, fonbot.zendesk.com.

    And yes, that's the guide I'm following. I have successfully obtained the access token using the authorization code grant type and the client credentials, by the way.

    Thanks,

    Jorge

    0
  • Sutrisno Suryajaya
    Comment actions Permalink

    Unfortunately, the password grant type is not supported for Zendesk Chat account that has Zendesk subdomain because you will not be able to make a "confidential" API client (i.e. the update client endpoint does not work for accounts with Zendesk subdomain).

    0
  • Jorge Tapia Hierro
    Comment actions Permalink

    But I made a "confidential" API client using the update client endpoint (or that's what I thought).

    When I use the get client endpoint, the client_type is set to confidential.

    Also, the client credentials grant type is working. Shouldn't it fail for the same reason?

    0
  • Sutrisno Suryajaya
    Comment actions Permalink

    May I know how do you call the get client endpoint and update client endpoint? Did you use your basic credentials (email and password)?

    0
  • Jorge Tapia Hierro
    Comment actions Permalink

    No, I used the OAuth2 credentials. I reproduce here the steps:

    First, I get the access token using the authorization code grant type. I log in with my username, jorge.tapia@fonetic.com, get the authorization code and, with that, retrieve the access_token using the https://www.zopim.com/oauth2/token endpoint.

    With that token, I can get the list of clients:

    curl -X GET \
    https://www.zopim.com/api/v2/oauth/clients \
    -H 'Authorization: Bearer {access_token} \
    -H 'Content-Type: application/json' \
    -H 'Postman-Token: 22d8b48d-0e6c-4f01-8665-3441a726b9ce' \
    -H 'cache-control: no-cache'

    [
    {
    "id": 40235,
    "name": "bot",
    "company": "Fonetic",
    "client_secret": "AGkk4bC",
    "client_identifier": "ZyteYHcRJpFyhKuFkOtEHzRroFKUxcJneMI9erEsdjBl5EFjso",
    "client_type": "confidential",
    "redirect_uris": "http://localhost:8080",
    "scopes": "read write",
    "agent_id": 369189064593,
    "create_date": "2018-11-16T11:21:14",
    "update_date": "2018-11-19T12:20:42"
    }
    ]

    Also, when I changed the client_type to confidential, I used the same access_token.

    curl -X PUT \
    https://www.zopim.com/api/v2/oauth/clients/40235 \
    -H 'Authorization: Bearer {access_token} \
    -H 'Content-Type: application/json' \
    -H 'Postman-Token: a5e7d67a-c1d4-47d7-8f2d-e4677a9fcf8c' \
    -H 'cache-control: no-cache' \
    -d '{
    "client_type": "confidential"
    }'

    {
    "id": 40235,
    "name": "bot",
    "company": "Fonetic",
    "client_secret": "AGkk4bC",
    "client_identifier": "ZyteYHcRJpFyhKuFkOtEHzRroFKUxcJneMI9erEsdjBl5EFjso",
    "client_type": "confidential",
    "redirect_uris": "http://localhost:8080",
    "scopes": "read write",
    "agent_id": 369189064593,
    "create_date": "2018-11-16T11:21:14",
    "update_date": "2018-11-21T08:46:49"
    }

    Thanks,

    Jorge

    0
  • Sutrisno Suryajaya
    Comment actions Permalink

    Thanks for the very detailed explanation Jorge!

    Unfortunately, even you successfully modify the API client type to "confidential", the password grant type is not supported for Zendesk Chat account that has Zendesk subdomain.

    Noticed that you are already able to generate access token using other flows (authorization code grant flow, implicit grant flow or client credentials type), would that be sufficient? If not, could you elaborate more on the use case that you are trying to achieve? Thank you!

     

    0
  • Jorge Tapia Hierro
    Comment actions Permalink

    Yes, it's enough with the client credentials type, I was just wondering if I was making a mistake with the password grant type.

    The use case is: I'd like to develop a bridge between Zendesk Chat and a bot. My idea is to launch a program that authenticates as the agent and runs a protocol to decide when to forward the messages to a bot.

    For that, I need the program to authenticate without human intervention.

    Thanks for your help.

    Jorge

    0
  • Sutrisno Suryajaya
    Comment actions Permalink

    Good to hear that, we will definitely take your feedback as consideration for future improvements!

    0
  • Bryan - Community Manager
    Comment actions Permalink

    I know this is an old post, but to add a couple of points and clarifications...

    As Sutrisno states, the password grant type can only be used on standalone Zendesk Chat accounts. Integrated accounts (those that have both Zendesk Support and Zendesk Chat) should use one of the other Chat OAuth grant types.

    If you do indeed have a standalone Zendesk Chat account and still want to use the password grant type, then the cURL command mentioned above should not pass the Authorization header (as this is not needed in a password grant flow -- all the necessary authentication information is in the OAuth client data that's passed). Instead use:

    curl -X POST \
    https://www.zopim.com/oauth2/token \
    -H 'Content-Type: application/x-www-form-urlencoded' \
    -d 'grant_type=password&username=jorge.tapia%40fonetic.com&password=*****&client_id=ZyteYHcR****&client_secret=AGkk4bC****'

    Note, too, that as in this example data passed (such as username) should be URL encoded. If your email has as special character (say the '+' character) and it is not encoded, you will get {"error_description": "Invalid credentials given.", "error": "invalid_grant"} returned.

    0

Post is closed for comments.

Powered by Zendesk