What Is OAuth & How Does It Work

OAuth, short for “Open Authorization,” is a standard that enables access delegation across apps without exposing credentials. It gives developers flexibility with APIs and integration, allowing fast and easy authorization without compromising on security. This makes it useful for SaaS integrations and APIs where one service needs scoped access to another on behalf of a user.

OAuth 1.0 launched in 2007 as a response to auth security challenges, like sharing user credentials with third parties. The current full release, OAuth 2.0, has evolved significantly; it is widely used across web and mobile platforms for delegated authorization. And OAuth 2.1, while still a work in progress, formalizes security best practices already recommended for OAuth 2.0 implementations.

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 is authorization, not authentication. OAuth provides a standardized way for apps to access resources on behalf of users while protecting their actual credentials.

• OAuth 2.0 is the current version. OAuth 2.1, while still a work in progress, introduces security improvements, including mandatory PKCE and the removal of vulnerable grant types.

• Whether implementing basic social login or complex cross-platform workflows, understanding OAuth 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 app to another without giving away their identity details. This is often seen in streamlining and securing user account activities across apps.

For example, with OAuth, a user on X (formerly Twitter) can authorize Medium to access their profile, read their posts, or post to their feed without having to give Medium their X credentials.

OAuth stands for “Open Authorization.” It’s important to note that it is NOT intended for authentication. Instead, authentication layers must be added on top of OAuth—more on that below.

What is OAuth 2.0?

OAuth 2.0 is the current edition of OAuth. Upon official release in 2012, it replaced OAuth 1.0, which was primarily designed for web-based use. Due to its complex signature requirements, OAuth 1.0 was difficult to implement for mobile and native apps. Almost all deployments of OAuth today use OAuth 2.0, as it’s designed for use with web and mobile apps across a variety of APIs. 

Both 2.0 and 2.1 offer significant upgrades to the now-deprecated older version. 

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.

Differences between 2.0 and 2.1

OAuth 2.1 makes some relatively small but significant changes to OAuth 2.0, including:

• Requiring Proof Key for Code Exchange (PKCE) 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, which are much more likely with OAuth 2.0, can affect any size or type of organization, from tech giants like Microsoft to dev platforms like Expo.

How OAuth 2.1 addresses a real security threat

OAuth 2.1 strengthens security over its predecessor. In particular, the new requirements and recommendations address common threats to OAuth 2.0:

• Requiring PKCE prevents authorization code interception attacks by ensuring that 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

For these reasons, it’s worth considering OAuth 2.1 rather than 2.0 for new deployments.

Also Read: OAuth 2.0 vs OAuth 2.1

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 an X user grants access to Medium to post to their account:

• The user is the resource owner.

• Medium is the client.

• X 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. This reduces the friction of short-lived tokens while minimizing exposure risk.

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, authorizing payments, and limiting access to sensitive information). Minimizing scopes upholds the principle of least privilege, which is a gold standard for security and a pillar of many regulatory frameworks.

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 in use today are authorization code, client credentials, and device codes, but some contexts require using legacy grant types, especially in OAuth 2.0.

Authorization code

This grant type uses a single-use authorization code. Specifically, the authorization server presents the client with the authorization code, which 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 and mobile/native apps, a more secure option is Authorization Code with PKCE. This is an extension of the Authorization Code grant type with additional 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

This grant type uses the client ID and client secret to authenticate the application itself. It is usually used by confidential clients who 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 Authorization Grant (also called Device Code) type sends a code to a secondary device for quick, secure authorization. It’s mostly used in browserless 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

These grant types use outdated methods that are no longer standard in OAuth 2.1 due to their inherent security risks. Even though OAuth 2.1 is technically a “work in progress,” it’s smart to stay updated with the latest best practices. 

These methods, though deprecated, are still used to connect to older apps and software or in cases where OAuth 2.1 has not been fully adopted:

• 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. Authorization code and/or PKCE work better in most cases.

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, adding the functionality to OAuth.

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 with better UX and security than password-based auth. However, that’s where the similarities end.

Here’s how the two standards stack up, at a glance:

The most significant difference is that SAML is mainly meant for authentication, while OAuth is meant for authorization. SAML uses Extensible Markup Language (XML) as its communication format, making it more relevant for enterprise use cases. OAuth uses 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. However, as noted above, OAuth needs an authentication layer like OpenID Connect to perform an equivalent function.

Common OAuth use cases

OAuth is widely used across web and mobile apps to enable secure, delegated access without exposing user credentials. Common implementations include:

• Social login: With OAuth, users can grant a third-party app access to their information through another service provider (like Google) without sharing a password or creating new credentials. For developers, this reduces onboarding friction and offloads credential management. 

• SaaS integrations: OAuth allows users to connect third-party tools to SaaS platforms. For example, a project management app might request to read a user’s Google Calendar or post updates to a Slack channel. From a developer perspective, OAuth makes it straightforward to request only the permissions your integration needs, rather than requiring broad account access. 

• API access between services: OAuth’s client credentials grant type is commonly used for machine-to-machine (M2M) authorization, where one backend service needs to access another without user involvement. 

• Enterprise identity platforms: OAuth is often used alongside OIDC and SAML to power single sign-on and federated identity across internal tools and third-party applications. 

• AI agents and agentic systems: OAuth is increasingly being used to authorize AI agents to act on behalf of users across external services; for instance, reading emails, updating records, or triggering actions in connected apps. Importantly, agentic authorization requires careful scope management to ensure agents only access what they need. The Model Context Protocol (MCP) recommends OAuth 2.1 with PKCE as the ideal implementation path.

OAuth best practices for secure implementation

Implementing OAuth, whether 2.0 or 2.1, is a first step toward improving UX and security in your auth flows. To maximize the security benefits, consider:

• Using PKCE, even in OAuth 2.0, to prevent the interception of sensitive information

• Limiting scopes to uphold the principle of least privilege for security and compliance

• Using short-lived tokens to reduce risk by minimizing the potential attack surface

• Securing refresh tokens with token rotation to further minimize long-lived risks

• Avoiding deprecated flows that can potentially lead to access token leakage

The best way to get the most out of OAuth is to use it alongside a powerful auth platform.

Add OAuth with Descope

OAuth is essential to web apps. It improves both the security and UX of auth flows by enabling authorization without exposing credentials. 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 security pitfalls in OAuth and other auth approaches by providing secure social logins with no-code workflows, SDKs, and APIs. Our platform powers OAuth authorization, OIDC authentication, and many other identity and access management (IAM) functions, including for AI systems, that dev teams can access in just a few lines of code.

Sign up for a Free Forever account with Descope and start building secure, scalable auth flows today. Have questions about OAuth 2.0 or 2.1 implementations? Book time with our experts.

FAQs about OAuth