Table of Contents
Before OAuth emerged in 2007, users frequently had to share actual usernames and passwords with third parties, granting complete access to their accounts.
OAuth 1.0 launched as a response to this security challenge, offering apps a better way to handle access delegation without exposing credentials. The current full release, OAuth 2.0, has evolved significantly from those early days, powering web-based authorization for most major platforms. And, while the next official version is likely years away, in-development OAuth 2.1 offers substantial security improvements you can leverage already.
Let’s take a closer look at how OAuth works. We’ll walk through its components and flows, while exploring why it remains the standard of choice for secure web authorization.
OAuth main takeaways
OAuth provides a standardized way for applications to access resources on behalf of users while protecting their actual credentials.
The upcoming transition from OAuth 2.0 to 2.1 brings crucial security improvements, including mandatory PKCE and the removal of vulnerable grant types.
Whether implementing basic social login or complex cross-platform workflows, understanding OAuth architecture will help organizations maintain strong application security.
What is OAuth
OAuth is an open, token-based authorization framework that allows users to grant access to their private resources on one application to another application without giving away their identity details. For example, a Twitter user can authorize Medium to access their profile, read their Tweets, or post to their feed without having to give Medium their Twitter credentials.
OAuth stands for “Open Authorization”. It’s important to note that OAuth is NOT intended for authentication.
OAuth Versions: OAuth 2.0 vs OAuth 2.1
OAuth 2.0 is the last-published version, but it’s still receiving updates today. Work-in-progress OAuth 2.1 is being finalized as a cleaner, more secure update of the base framework. OAuth 2.1 isn’t a completely new version. It simply formalizes current best practices and removes deprecated grant types.
Some key differences between 2.0 and 2.1 include:
Requiring PKCE (Proof Key for Code Exchange) for all OAuth flows using authorization code grants
Removing the implicit grant type and password grant type entirely
Requiring all redirects to use exact string matching
Strongly recommending refresh token rotation
These changes reflect the very real possibility of misconfiguring your OAuth implementation in a way that leaves security holes. These misfires can affect any size or type of organization, from tech giants like Microsoft to dev platforms like Expo.
Here’s how each update addresses a real security threat:
PKCE prevents authorization code interception attacks by ensuring only the original requesting client can exchange the code for tokens
Removing the implicit grant eliminates common token exposure risks in browser-based apps
Eliminating the password grant type prevents exposure of user credentials to third-party applications
Exact string matching for redirects protects against redirect manipulation that attackers could use to steal tokens
Refresh token rotation helps prevent token replay/reuse attacks by invalidating tokens after each use
OAuth roles
There are four roles defined in the OAuth framework:
Resource Owner: The resource owner is the user who authorizes the application to access their account or protected resources.
Client: The client is the application that wants to access the user’s account or protected resources.
Resource Server: The resource server is the server that hosts the user’s protected resources. Once authorization is successful, the resource server grants the client access to the requested resources.
Authorization Server: The authorization server is responsible for getting the user’s consent and providing tokens (access and refresh tokens) to the client to facilitate access. The authorization server usually exposes two endpoints: the authorization endpoint which handles user authentication and consent, and the token endpoint which handles token generation.
Let’s consider the same example laid out in the beginning of this article. In an OAuth process where a Twitter user grants access to Medium to post to their Twitter account:
The user is the resource owner.
Medium is the client.
Twitter hosts both the resource server and the authorization server.
OAuth tokens and scopes
OAuth uses access tokens to authorize applications to access resources on behalf of the user. The client gets access tokens from the authorization server and presents them to the resource server to gain access to the requested resources. Access tokens have no specific format requirements, although the most commonly used format is a JSON Web Token (JWT).
Since access tokens often expire after a set period of time, the client can leverage refresh tokens to request a new access token without needing user participation every time.
Scopes are used to clearly define what the client can access from the resource server on behalf of the user. Rather than granting full account access, scopes limit what a client can do after getting access to a user’s resources (e.g. read vs. write access, limiting access to sensitive information).
OAuth grant types
OAuth supports a variety of methods through which a client can request authorization. Grants refer to the steps a client needs to take before getting authorization to access the requested resources. The main grant types are:
Authorization code
In the authorization code grant type, the authorization server presents the client with a single-use authorization code. This code is then exchanged for the access token when the client communicates with the token endpoint. The authorization code grant type is generally used by traditional web apps.
For single-page apps and mobile / native apps, a better alternative is to use the Authorization Code with PKCE (Proof Key for Code Exchange) grant type. This is an extension of the Authorization Code grant type with additional security measures that prevent code injection attacks.
It’s worth noting that in OAuth 2.1, PKCE is now the standard for all flows using the authorization code grant. Some implementations may still use 2.0 standards, however.
Client credentials
The client credentials grant type is usually used by confidential clients that are seeking access to resources under their own control rather than a user’s resources. For example, an app may need access to a backend cloud-based storage service to store and retrieve data. In this case, the client is also the resource owner.
Automated processes, microservices, and similar clients can use the client credentials grant type without input from the end user.
Device code
The device code grant type is recommended for browserless devices or devices with restricted input capabilities like smart TVs or gaming consoles. In this grant type, rather than authenticating the user directly, the user is presented with a code and asked to go to their computer or phone to input the code and authorize the device.
Legacy grant types
Even though OAuth 2.1 is technically a “work in progress,” it’s smart to stay updated with the latest best practices. The two grant types below have been removed from 2.1 because they are considered insecure. We’re including them here because it’s still helpful to understand how OAuth is evolving.
Implicit grant: The implicit grant type directly returns the access token, usually as a parameter in the callback URI. Since no authorization code is involved in this flow, there’s no confirmation that the token was received by the client. This grant type has security implications and is vulnerable to token leakage and token replay attacks. The authorization code and PKCE grant types are more secure alternatives.
Resource owner password credentials grant: This grant type requires the client to collect the user’s password and send it to the authorization server in exchange for an access token. Since the user’s password is exposed in this grant type, it is no longer recommended for use.
How OAuth works
Before OAuth can be used, the client must first register with the authorization server by providing the application name, website link, and the redirect URI or callback URL used during the authorization flow.
Once the registration is completed, the client will get its own set of credentials in the form of a client ID and a client secret. These two pieces of data allow the client to identify and authenticate itself when requesting an access token from the authorization server.
Let’s go through a simplified example of an OAuth flow using the authorization code grant type.
Step 1: The client requests authorization from the authorization server. It generally provides the client ID, a redirect URI, and scopes that specify the level of access being requested.
Step 2: The authorization server seeks approval from the user / resource owner on the request being made by the client. If the user is not already logged in, this step may involve the authorization server authenticating the user.
Step 3: After approval from the resource owner, the authorization server redirects to the redirect URI provided during Step 1. An authorization code is appended to the redirect URI.
Step 4: The client presents the authorization code, client ID, client secret, and other relevant details to the token endpoint on the authorization server. If everything is in order, the client receives an access token (and a refresh token in some cases).
Step 5: The client presents the access token to the resource server and successfully accesses the user’s resources aligning with the scopes laid out in Step 1.
OAuth and OpenID Connect (OIDC)
OpenID Connect (OIDC) is an open standard that runs on top of OAuth. While OAuth is used solely for authorization, OIDC is used for authentication.
OIDC utilizes an additional token, called the ID token, that contains information about the user and their authentication status. It also adds structure to the scopes and claims used in the process to make the framework more interoperable. With the help of OpenID Connect, otherwise disparate systems can share user authentication states and profile details in a predictable manner.
OAuth vs SAML
SAML is an XML-based standard that helps users access multiple web applications with one set of login credentials. SAML and OAuth are both open, interoperable standards that make security improvements over usernames and passwords while also making users’ lives easier. However, that’s where the similarities end.
While SAML is mainly meant for authentication, OAuth is meant for authorization. SAML uses Extensible Markup Language (XML) as its communication format of choice, making it more relevant for enterprise use cases. OAuth uses JSON file formats called JWTs, which are more lightweight and thus perform better for consumer-facing, mobile, and native applications.
Since SAML can be used for both authentication and (some) authorization, it can provide single-sign on (SSO) functionality on its own. OAuth needs an authentication layer like OpenID Connect to perform an equivalent function.
Add OAuth with Descope
OAuth is essential to web apps, but adding it on your own can be challenging. When implemented properly, OAuth safeguards user account and credentials. However, as revealed in our guide to OAuth misconfigurations, even small errors can create significant vulnerabilities.
Descope helps developers avoid these security pitfalls by providing secure social logins with no-code workflows, SDKs, and APIs. Sign up for a Free Forever account to get started.
