What is OAuth? {Definition, Terminology & Practices}

Introduction

The appearance and popularization of APIs allowed for mass data sharing. However, a large percentage of shared data is not for public use. As a result, API developers started looking for ways to keep unauthorized parties from accessing valuable resources. This is where identity and access intelligence plays a crucial role.

Developments in the field of identity and access intelligence resulted in numerous data protection tools API owners use daily. One of those tools is the Open Authorization protocol, or OAuth.

Read on to find out what OAuth is, how it works, and how to implement it following best security practices.  

OAuth Definition

OAuth is an authorization protocol designed to grant an application access to resources hosted by other web applications on a user's behalf. It is considered the industry standard for online authorization and an essential component of API security systems. 

OAuth 1.0 vs. OAuth 2.0 

The first version of OAuth debuted in 2007 but was replaced by OAuth 2.0 in 2012 due to implementation challenges. Since then, OAuth 1.0 has been considered deprecated, and API providers no longer use this version of the protocol. 

Here is a rundown of the differences between the two versions.

•  OAuth 1.0 is transport-independent, meaning that the protocol does not delegate security to other security protocols, such as HTTPS and TLS. OAuth 2.0 delegates most security tasks to HTTPS and TLS, making connections more vulnerable to man-in-the-middle attacks. 
• OAuth 1.0 is founded in cryptography, meaning it uses digital signatures as an authorization tool. OAuth 2.0 utilizes bearer tokens, which are easier to implement, but feature no internal security mechanisms. 
• OAuth 2.0 is more user-friendly, but also presents more security challenges. 

OAuth vs. SAML

OAuth and Security Assertion Markup Language (SAML) are similar in that they are web protocols that grant access to web applications. However, they differ in several ways. 

The main difference between the two is that OAuth is an authorization protocol whereas SAML is an authentication protocol.  

With authentication, the end user must state their identity by entering credentials every time they wish to access certain resources. With authorization, the server recognizes the user as someone who has already been granted access, and asks the authorization server, not the user, for a confirmation token. 

The advantage of OAuth over SAML is that a user can seamlessly switch between integrated applications without having to log into each of them individually. 

Let us look at a work environment as an example. Typically, companies use dozens of web applications for their processes. With OAuth, an employee can log into a work environment once and use all integrated applications without having to enter their credentials into each one separately. 

A Short History of OAuth

• November 2006 – Web application developers realize that there are no open standards for API access delegation, thus creating the idea of OAuth. 
• April 2007 – Formation of the OAuth discussion group. 
• July 2007 – Initial specification drafted. 
• December 2007 – Release of the final draft under the name OAuth Core 1.0. 
• August 2010 – Publishing of the OAuth 1.0 framework in RFC (Request for Comments), a knowledge base for internet and internet-connected systems, under the number 5849. All third-party Twitter applications are required to use OAuth. 
• October 2012 – Publishing of the OAuth 2.0 framework and Bearer Token Usage guide in the Request for Comments under the numbers 6749 and 6750, respectively. 
• Present – OAuth 2.1 is in draft stage. 

Note: The information provided is based on data available at the time of writing this article (September 2022) and is subject to change. 

OAuth 2.0 Important Terminology 

The following are definitions of terminology associated with the OAuth 2.0 framework. 

OAuth 2.0 Roles 

The roles that participate in the OAuth 2.0 authorization process are outlined below. 

• Resource owner – The user or system that owns protected API resources and can grant access to them. 
• Client – The system that requests access to protected resources using the appropriate access token. 
• Authorization server – The server that receives client requests for access tokens and issues them upon authentication and consent given by the resource owner. 
• Resource server – The server that contains protected resources and issues them upon receiving a valid request containing a valid access token. 

OAuth 2.0 Scopes

OAuth scopes are the reasons for which clients may be granted access to protected resources. The resource owner determines what scope values are acceptable and which resources the scopes relate to. 

OAuth 2.0 Tokens 

OAuth tokens are strings of data that contain security credentials needed to access protected resources.  

Tokens allow resource servers to identify the token owner, the groups the owner belongs to, and the level of access the user has. However, none of this information is disclosed to the authorization server as the OAuth framework is designed not to expose client credentials. 

The two types of OAuth tokens are: 

• Refresh tokens – A refresh token allows a client to generate, refresh, and revoke a short-term access token. Refresh tokens are sent to the authorization server. Their use is not mandatory but is recommended as a good security practice. 
• Access tokens – An access token is sent to the resource server, which then grants access to protected resources. Its short expiration time prevents token leaks and security breaches. 

There are two types of access tokens: 

• Bearer tokens – These tokens rely on HTTPS security. Requests made using these tokens are not signed or encrypted. Bearer tokens can be unstructured (a short string of hexadecimal characters) or structured (e.g., JSON web tokens). 
• Message Authentication Code (MAC) tokens – These tokens allow requests to be partially cryptographically verified. 

OAuth 2.0 Authorization Code 

Authorization servers can be configured to return an authorization code instead of an access token.  

Authorization codes are used to obtain access tokens and work much like refresh tokens. An authorization code and refresh token differ in that the former is for one use only and has an expiration time, while the latter can be used an indefinite number of times. 

OAuth 2.0 Grants 

Grants represent sets of steps a client must complete before obtaining access to requested resources. Different flows require different grant types, and the OAuth framework allows the following:  

• Implicit grant – It is a flow in which the authorization server returns the access token directly to the client via browser URL. Upon a request, the user is redirected to an OAuth page and asked to authorize permissions. When the user does so, they are redirected back to the application with an access token. This grant is rarely used as the exposed access tokens pose a security threat, but when it is used, it is for single-page JavaScript applications. The simplicity of this flow is overshadowed by the effort it takes to secure it. 
• Refresh token grant – Used by clients to exchange a refresh token for an access token without the need for reauthentication. This flow is one of the most used ones because the involvement of two tokens provides the right balance between security and usability. Refresh tokens work with single-page, native, and web apps. 
• Authorization code grant - Works best for traditional web applications because the secret exchange happens on the server side. Upon receiving a client’s request, the authorization server returns a single-use authorization code the client exchanges for an access token. Mobile, native, and single-page apps require additional security measures because client secrets cannot be stored securely in such architectures. 
• Authorization code grant with proof key for code exchange (PKCE) - Involves the use of a single-use authorization code. This flow meets the security needs required for mobile, native, and single-page applications. 
• Resource owner credentials grant - Reserved for trusted clients (i.e., an operating system or highly privileged application). The client needs to acquire the resource owner’s credentials and send them to the authorization server. Authorization servers should enable this type of grant only in cases when other flows are not viable. 
• Client credentials grant - Designed for non-interactive applications (applications with no user input) such as microservices and automated processes. The authorization server authenticates the client application using its client ID and secret. 
• Device authorization flow - A grant type that enables access to apps on input-constrained devices, such as smart TVs, smart watches, smart home devices, etc. 

How Does OAuth Work?

An authorization process using OAuth 2.0 consists of the following steps: 

1. A client application sends an authorization request to the authorization server containing a client id, client secret, required scopes, and an endpoint URI. 
2. The authorization server authenticates the client using the client id and checks whether the requested scopes are permitted. 
3. If the request is valid, the client authenticated, and the scopes permitted, the authorization server requests an authorization credential (access token or authorization code) from the resource server. 
4. The resource server provides the authorization credential. 
5. The authorization server passes the credential to the client. 
6. The client now requests access to the resource server using the credential they received. 

OAuth Example

CCBill’s RESTful transaction API utilizes bearer tokens for authorization.  

Before merchants can use the API to manage their transactions, they are required to register their application, after which CCBill provides them with a merchant application ID and secret key. These credentials are then used to generate an access token. 

The URI of CCBill’s authorization server is https://api.ccbill.com/ccbill-auth/oauth/token. 

Access token request – curl example: 

curl -X POST  
\ 
'https://api.ccbill.com/ccbill-auth/oauth/token'  
\ 
    -i -u 'MERCHANT_APPLICATION_ID:APPLICATION_SECRET'  
\ 
    -H 'Content-Type: application/x-www-form-urlencoded'  
\ 
    -d 'grant_type=client_credentials' 

Once they receive an access token, merchants must provide it in the Authorization header of each API request they make. 

OAuth 2.0 Implementation – Best Practices 

Because OAuth 2.0 delegates security to security protocols, API owners using OAuth 2.0 must ensure their security measure implementation is watertight. The best practices associated with secure OAuth 2.0 implementation are as follows: 

Use SSL

To establish OAuth 2.0 connections, authorization servers must obtain an SSL or TLS certificate. This is a mandatory prerequisite within the OAuth 2.0 framework and aims to prevent man-in-the-middle attacks. 

Set up SSL Certificate Checks (for Mobile Applications) 

Web browsers perform checks on web applications by default and warn users if the certificate is not trustworthy. 

Do Not Store Client Secrets in Plaintext  

API owners who wish to retain client secrets should store them in their hashed values. Storing client secrets in plaintext seriously compromises security because, in case of a breach, the secrets are easily accessible. 

Use Refresh Tokens 

Refresh tokens are credentials used to obtain short-lived access tokens. Using refresh tokens instead of relying only on access tokens is more secure for the following reasons: 

• An access token is exchanged with the resource server directly, while a refresh token is exchanged with an authorization server. Thus, the chances of an access token being leaked are minimized. 
• Refresh tokens allow client application owners to revoke a short-lived access token, should the need arise. 
• A refresh token travels faster than an access token, giving hackers less time to perform man-in-the-middle attacks. 
• Malicious activity is easier to spot because expired access tokens can only be replaced by sending a request with the refresh token it is tied to. Let us imagine a hacker obtains an access token and the refresh token associated with it. When the access token expires, they would have to send a refresh request with the refresh token. Server operators would be able to spot suspicious activity because of changes in user behavior (e.g., a different IP address the request is sent from). 

Conclusion

You understand what OAuth is and how it is used to secure authorization procedures, credentials transfers, and resource transfers between web applications.