Get refresh token

English Forum Developers & API
12

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 Log in - Asana. 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 https://app.asana.com/-/oauth_token. 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 Log in - Asana
  • 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:

3 Likes