Get refresh token



I can’t get the syntax right. How can I get the refresh token using the node API? I have an access token from the OAuth callback though.


cc @Diakoptis

Problem with Token Exchange Endpoint

I’m facing the same issue. I fetch the bearer token from OAuth callback. but can’t get the refresh token.


Sry guys i’m late.

Check this: PHP API, Oauth2 workflow


@Bastien_Siebman i haven’t use node api :frowning:



Thank you for your response.
I use this Api to fetch refresh token. But it fails everytime. What should i pass in the request body? is there any format?" + ASANA_CLIENT_ID + "&redirect_uri=http://localhost:3000/auth/asana/callback&response_type=code


Try this:

https://’ + ‘&client_id=’ + client_id + ‘&client_secret=’ + client_secret + ‘&refresh_token=’ + refresh_token


I will try when I have the time, thanks a lot


@Diakoptis the given url includes the refresh token while I am stuck without a refresh token at all :stuck_out_tongue: I don’t understand how to get it. I think I am going to reverse engineer the PHP library that allows it…


FYI to login the library makes a request to

and as a result I get


I am using the Implicit Grant workflow…


According to this page refresh token are not supported with Implicit Workflow, I will have to do a workaround :stuck_out_tongue:


Hi all, sorry I’m a bit late to the game, but you seem to be getting it sorted :slight_smile:

The general issue here is that there are 2 types of OAuth authorization workflows: “Authorization Code Grant” and “Implicit Grant”, and unfortunately while standard, those names don’t give many clues as to what each flow means…

“Authorization Code Grant” is intended to allow a server that has the capacity to securely store secrets to get a long-lived capability for accessing an API. The refresh token is the key here, because it is what is used to grant long-lived access to the API (and is therefore an important thing to keep secret). This is the flow with response_type=code as the request parameter. The way this flow works is:

  • The app is given a secret credential called the client_secret when it is created. Users should never see this.
  • A user wishes to authorize the app, and gives it access to do so at The response contains a code in the URL parameter that the browser is redirected to.
  • The app uses this code, representing “this user did say it was OK to access their data for this app just now”, and the app’s client_secret which identifies that this is indeed the correct app, to get a long-lived refresh_token. The user also should never see the refresh token.
  • Refresh tokens can be used in perpetuity to get access to short-lived access tokens via These short-lived tokens are the ones passed in the header to actually grant access.

The above flow presumes that the app can store both its own client_secret and the refresh_token per-user in a secure location that users (and, say, snoopy browser extensions) don’t have access to. If this is not true, it’s recommended to use the “Implicit Grant” flow with response_type=token. That is a simpler (but unfortunately more user-impacting) way to access an API:

  • Show the user the same sort of authorization grant via
  • Instead of a code to get access to a long-lived token, a short-lived token is given directly in the redirect via a URL parameter. This token can be used to access the API for an hour.
  • After that time expires, repeat this flow to get another short-lived token.

So more or less, the price that’s paid to have a purely in-browser (and therefore inherently hard to secure) application is that the user will explicitly have to keep reauthorizing the app every hour or so. This is basically because OAuth was written with server-to-server authentication in mind, and browser-to-server auth is basically impossible to completely secure, since users and browser extensions have the capability to snoop into any client side storage :confused:


Thank you so much with all the details! It is very clear now :kissing_heart: