Refreshing OAuth 2 Tokens
This guide assumes you've already built an OAuth2 app
If you haven’t, please refer to this guide, and return here once you’ve captured the access_token and refresh_token from a successful OAuth 2 credentials grant.
Basics of token refresh
Assuming you’ve included the offline scope in your OAuth2.0 credentials request, successful authentication via Frame.io’s Accounts application will return a payload that looks like the following:
The access_token is a bearer token that can be used to act on behalf of the authenticated user; it will expire after 3600 seconds (one hour); and after that, the refresh_token can be used to to fetch a new access_token. The refresh token will then expire after 30 days, at which point you will need the user to login from scratch, producing a new access/refresh token pair; and so on.
If you do not request the offline scope explicitly, you will not receive a refresh_token, and therefore after an hour will have to fully re-authenticate the user.
Capturing the refresh token on successful authentication
Needless to say, you can’t use a refresh_token you don’t have, so be sure in your app to:
- Request the offline scope
- Capture the
refresh_tokenthat’s returned in a successful callback.
For convenience, the callback from our OAuth 2 App Guides is reproduced here, with an os call to stash the Refresh token. Please note that two examples are provided: one with PKCE configured (does not include basic auth header), and one without (includes basic auth header).
Without PKCE
With PKCE
Executing a refresh
The refresh itself is a single call to Frame.io’s token URL:
- Method: POST
- URL: https://applications.frame.io/oauth2/token
Content-Type: application/x-www-form-urlencoded
A refresh will always include at least the following three attributes in its form data:
grant_type: refresh_tokenscope: <SCOPES>refresh_token: <REFRESH_TOKEN>
If you’re using PKCE, you’ll need to include your app’s client_id in this form data; if not, you’ll need to include a Basic authentication header with your app’s client_id and client_secret as the Username and Password, respectively.
Without PKCE
Similar to making the initial authentication callback without PKCE, this standard refresh will require supplying your client_id and client_secret as the Username and Password in a Basic Authentication header.
With PKCE
Again, we’re mimicking the rules of our initial /callback cycle:
- We don’t include an
Authorizationheader - We must include the
client_idin our payload
Congratulations! You can now handle the entire token lifecycle of an OAuth2.0 client application.