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 2.0 vs OAuth 1.0
OAuth 2.0 is the latest version and de facto industry standard for authorization. It replaced OAuth 1.0 in 2012 after a complete rewrite. OAuth 2.0 is not meant to be backwards compatible with OAuth 1.0.
There are several differences between OAuth 1.0 and OAuth 2.0, some of which are detailed below:
While OAuth 1.0 required the client to perform cryptographic functions, OAuth 2.0 enforces security via HTTPS and unburdens the client of cryptographic requirements.
OAuth 2.0 signatures are much easier to work with and do not require any special sorting, parsing, or encoding.
While OAuth 1.0 only supports browser-based applications, OAuth 2.0 supports a wide variety of non-web apps like mobile apps, API services, and IoT devices.
OAuth 2.0 has a clear separation of roles between the server that handles the authorization request (authorization server) and the server that makes access control decisions based on the response to the authorization request (resource server). This will be covered in more detail in the next section.
OAuth 1.0 has been deprecated. Mentions of “OAuth” in this article refer to OAuth 2.0.
OAuth roles
There are four roles defined in the OAuth 2.0 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 2.0 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.
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
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 2.0 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, 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.
More OAuth resources
Interested in learning more about OAuth?
Read the full OAuth 2.0 specification from the Internet Engineering Task Force.
Read this tutorial on adding OAuth2 to a React app for authentication and authorization.
Check out the latest OAuth 2.0 Security Best Current Practice draft.
Implementing OAuth social logins for your app can be a complex and time-consuming process. Descope helps developers easily add social logins to their apps with no-code workflows, SDKs, and APIs.
Sign up for Descope and add OAuth social logins to your app with a few lines of code.
