Skip to main content
purple hex pattern

What are OAuth tokens?

OAuth tokens authorize a user’s access to resources. In other words, they do not authenticate users, but are used by the service provider to authorize access on behalf of the user to other resources. 

An OAuth transaction occurs when a user requests permission from another resource using their service provider identity. The resource will request permission from the service provider, which is given in the form of a request token and a secret. Next, the resource redirects the user to their service provider to authenticate the request. At this point, the resource exchanges the request token for an access token and a secret. If the two tokens share the same secret, the OAuth process is complete, and the user has successfully delegated access for the resource to the service provider.

The OAuth Process

STEP 1

Request access

Anne makes a request on YouTube (resource) to post videos directly to her Twitter feed (service provider). YouTube then asks Twitter for permission to access.

graphic of a woman sitting at a desk

STEP 2

Request token and secret exchange

Twitter provides YouTube with a request token and secret.

graphic of a key and web browsers

STEP 3

Authentication

YouTube redirects Anne to Twitter to log in. Anne provides Twitter with her login credentials and authenticates that the request from YouTube was initiated by the user.

Graphic of a person using a laptop

STEP 4

Access token exchange

Once the request is authenticated by the user, YouTube asks Twitter to exchange the request token and secret for an access token. If the secrets associated to the tokens match, Twitter will provide YouTube with the access token and grant access to YouTube.

graphic of a key and web browsers

STEP 5

Access granted

Anne can now securely use YouTube to post videos directly to her Twitter feed.

graphic of a woman sitting at a desk

The above example summarizes a general OAuth process. OAuth also allows more granular control and permissions, such as the right to revoke tokens whenever the user wants and defining different levels of access to service providers for different resources.

OAuth 1.0 vs. OAuth 2.0

In 2012, OAuth 2.0 was introduced as a major overhaul to OAuth 1.0. The changes made to this version of OAuth were significant enough that versions 2.0 and 1.0 are not compatible. OAuth 2.0 was designed to address a session fixation security flaw in the OAuth authorization flow.

 Although this issue has been resolved with OAuth 2.0, the new version intentionally does not define or support encryption, signature, client verification, or channel binding, but instead requires that implementers use a different security protocol like HTTPS/TLS for that purpose. 

The differences between OAuth 1.0 and 2.0 can are summarized below:

OAuth 1.0 versus OAuth 2.0 chart

OAuth vs. SAML – what’s the difference?

SAML is an XML variant language that describes a framework that allows one device to perform both authentication and authorization on behalf of one or more devices. 

As light-weight options for encoding data emerged, such as JSON, OAuth gained adoption to support mobile device users. Although OAuth is a newer protocol that evolved from a need to replace SAML, both protocols are critical for secure single sign-on (SSO). 

In other words, OAuth is not an alternative to SAML as much as the two protocols can complement each other. For example, in an SSO environment, SAML may be responsible for authentication (confirming the user is authentic and should be granted access) and OAuth will be responsible for authorization (granting access to specific protected resources).