OAuth is an open standard for authorization that uses access and refresh tokens.
Access tokens are tokens developers send to gain authorization between an application and endpoints as long as they’re valid. Before the access tokens expire, refresh tokens are used to renew access. In this post, we’ll review the access and refresh tokens for five of the leading cloud document management services: Box, Dropbox, Google Drive, OneDrive and SharePoint.
This blog post is a follow-on to our updated Definitive Guide to API Integration. Download the full guide for more in-depth content on integration best practices, from pre-build to post-build, or check out the blog series.
With OAuth2.0, there aren’t defined standards for using access and refresh tokens. This means developers need to keep various expiration intervals in mind for maintaining access to different applications.
Some document management services’ tokens expire in a matter of months, while others never expire. For example, Box’s access token expires after 1 hour while Dropbox’s never expires. And it doesn’t help that finding information about expiration intervals is a taxing process - wading through documentation isn’t exactly a cakewalk.
Here are the OAuth access/refresh token expiration intervals for the five leading cloud document management services that you should keep in mind when building integrations to these applications.
Box
- Access token: 1 hour
- Refresh token: 60 days (resets 60 days after retrieving new access token)
Dropbox
- Access token: Forever
- Refresh token: N/A
Google Drive
- Access token: 1 hour, but it seems this can vary depending on the Google API (expires_in field is returned in JSON)
- Refresh token: Forever
OneDrive
- Access token: 1 hour
- Refresh token: 6 months (Get a new one every time you call refresh)
SharePoint
- Access token: 12 hours
- Refresh token: 6 months (Get a new one every time you call refresh)
Cloud Elements uses OAuth 2.0 standards to interact with our robust API connectors (called Elements) during the provisioning process. For native APIs that don’t use OAuth 2.0 (and there’s a wide range from custom auth types to the first iteration of OAuth), Cloud Elements offers an OAuth 2.0 facade so that you can avoid the if/then/else statements in your code that would typically be required to handle a variety of auth types across integrations in your catalog.
Further, our platform handles token refresh for our clients and have discovered how important it is as a developer to be mindful of these expiration intervals.
Want to read more about relevant best practices and considerations for building an API integration? Check out our Definitive Guide to API Integration.
Even more? Read about the range of auth methods.