What is OAuth (open authorization)?

Websites and third-party applications that ask users to “Sign in with Google?” or “Allow access to your account information?” are common use cases for OAuth. The OAuth protocol enables users to easily grant these applications access to their account data without sharing their user credentials.

In addition to web applications, OAuth can also grant resource access to APIs, server-side applications, OS native apps, mobile apps and devices such as smart TVs and appliances. In some instances, there is no human user involved as OAuth can authorize application access on behalf of an organization or business account.

OAuth offers important access management benefits to users, developers and businesses by keeping login data inaccessible and limiting access to other sensitive information. It also makes it easier for applications to access necessary account information without the security vulnerabilities of sharing user credentials.

By simplifying secure access, OAuth can help organizions address some of their biggest security challenges. For example, an IBM Institute for Business Value study found that 52% of executives say complexity is the biggest impediment to their cybersecurity operations.

A small team of software developers released OAuth 1.0 in 2007. This first version of the protocol was designed as an alternative to web-based authentication, which required users to share their usernames and passwords with third-party services. However, OAuth 1.0 provided authorization flows for websites only.

In 2012, the Internet Engineering Task Force (IETF) released OAuth 2.0 as RFC 6749 and RFC 6750. An RFC (Request for Comments) is an IETF document that describes internet communication protocols. RFC 6749 is the core framework for OAuth 2.0, and RFC 6750 defines how the framework uses access tokens.

This updated version of OAuth expanded the protocol beyond web browsers to include authorization capabilities for applications, APIs and devices. OAuth 2.0 replaced OAuth 1.0 and is now the industry standard.

Unlike other frameworks that rely on usernames and passwords, OAuth is an authorization protocol that is based on access tokens. Access tokens are pieces of information that determine the specific resources an application is allowed to access. The OAuth protocol defines how each component in an authorization request process approves, defines and manages access tokens.

OAuth tokens commonly use the JSON Web Token (JWT) standard because of its ability to transmit data securely.

The primary components of the OAuth framework are:

• Resource owner
• Resource server
• Client
• Authorization server
• Scope

Here is a basic overview of how an OAuth flow might work:

1. Jim (the resource owner) wants to allow a social media site (the client) to access his email contacts (the resource).
   
   
2. The email authorization server prompts Jim to provide consent for this access.
   
   
3. After receiving Jim’s consent, the authorization server provides the social media site with an access token.
   
   
4. The social media site presents the access token to the resource server that stores Jim’s email account information.
   
   
5. The resource server recognizes the access token and grants the social media site access to Jim’s email contacts. Because the access token includes the scope of Jim’s consent, the social media site cannot access any other data from Jim’s account.
   

The procedure for providing an access token to an application is called an authorization grant or authorization flow. There are different grant types and OAuth flows that can be used for different types of applications, devices or APIs, such as:

• Authorization code
• Proof Key for Code Exchange (PKCE)
• Client credentials
• Implicit grant
• Refresh token

This grant type is typically used for web applications and mobile apps. In an authorization code flow, the authorization server provides a one-time authorization code to the client. The client can then exchange that authorization code for an access token from the authorization server’s token endpoint.

This flow adds extra security to the authorization code grant to protect apps from code injection attacks. These types of attacks can trick apps into running malicious code that changes how they operate.

PKCE adds a “client secret” that authenticates the client with the authorization server before an access token is issued. Because only the legitimate client has the secret, malicious actors cannot pretend to be the client and introduce malicious code.

This grant type is designed for situations where no human user is involved, such as automated processes, machine to machine interactions and microservices.

Applications are granted access to system resources that they need to carry out functions, but are not given access to end user resources. For example, a client credentials grant might allow a weather app to access an API to retrieve data on the latest forecast.

This grant type provides a simpler flow for JavaScript web applications. Unlike the authorization code grant, the implicit flow does not require an authorization code before an access token is issued.

Instead, after the user provides consent, the access token is included in the redirect Uniform Resource Identifier (URI) that returns the user to the application requesting accessing. The app obtains the access token from the URI.

If an access token has expired, this grant type provides the application with a refresh token that can be exchanged for a new access token. Without a refresh token, the end user would have to once again provide consent in order for the application to receive a new access token.

The fundamental difference is that single sign-on (SSO) is a user authentication protocol and OAuth is an authorization protocol.

SSO often uses an identity provider (IdP) and the Security Assertion Markup Language (SAML), which is based on Extensible Markup Language (XML), to authenticate the digital identities of users through usernames and passwords.

OAuth does not authenticate users, but it does authorize them to access system resources. SSO solutions sometimes use OAuth to provide authenticated users with easy access to applications and services across an enterprise.

OpenID Connect (OIDC) is an authentication protocol that is built on top of OAuth 2.0. Working together, OpenID Connect can verify the identity of a user, then OAuth can authorize that user to access resources and services.