What Is OAuth and How Does It Work? 

You download a messaging app that requests access to your smartphone’s contacts. A new headshot would make your social media profile stand out, but the service wants access to your photos first. Even your workplace’s latest project management tool asks permission before it connects to your online storage service.  

Providing your password to all these third parties would be a huge security risk, which is where OAuth comes in. What is OAuth? In basic terms, it’s a standard way to authorize others to access the kinds of resources we’ve just described, such as your data or application programming interfaces (APIs).  

Read on for a more in-depth answer to “What is OAuth?” and how you can use it to keep your business secure.  

Understanding the Principles of OAuth 2.0 

While the original version of OAuth -- or “Open Authentication” -- launched in 2007, it was replaced by OAuth 2.0. in 2014.  

There is no backward compatibility between the two, in part because the latter was a complete rewrite of the standard.  

So, what is OAuth 2.0? Here’s an overview:  

Key concepts and principles of OAuth 2.0 

Unlike its predecessor, OAuth 2.0 was designed to support non-browser-based application clients.  

It also allows access tokens – a piece of data that authorizes access to resources on the user’s behalf -- to have an expiration date rather than storing them for a year or more.  

The role of authorization and authentication in OAuth 

You can use OAuth 2.0 in the same way a company might allow a cleaning service into its building in the off hours. Cleaners might be given a number for the keypad, for instance, but the number would only let them into designated floors or offices (and not, say, a company’s vault or safe).  

OAuth 2.0 doesn’t authenticate the identity of the service asking permission. It is only authorizing access based on consent, just as you may authorize a cleaning service without being on a first-name basis with everyone on its team.   

How OAuth enables secure access to resources 

What are OAuth 2.0’s key benefits, then? The fact that the standard shares access tokens means you’re able to grant permission to applications and services to your data without having to hand over your password or other credentials.  

Exploring OAuth 2.0 Roles 

OAuth 1.0 defined authorization flows across just three entities: a consumer, a service provider, and user. What is OAuth 2.0's approach?  

Different roles in the OAuth 2.0 framework 

OAuth 2.0 roles include:  

• The resource owner: this could be a person or an application who owns the data, account, or credentials being requested.  
• The client: This is the application or service that is asking the resource owner for authorization to access its resources.  
• The resource server: This is the external server that protects the resources that the client can be authorized to access. It is sometimes described as the API server.  
• The authorization server: This is where consent is managed and tokens are released.     

The responsibilities and permissions of each role 

The resource owner is responsible for giving consent to a client’s request to access its resources.  

Once that happens, the authorization server is responsible for checking to ensure the client identity is valid and can release the tokens, which integrate with the resource server.  

How roles interact in the authorization process 

This process in which the various OAuth roles interact is described as a series of code flows. This includes the client credentials flow, device authorization flow, and many more.   

Unraveling OAuth 2.0 Scopes 

Defining OAuth2.0 scopes and their significance 

Scopes help limit what applications are allowed to do on a user’s behalf.  You may want a fitness tracker to access your location, for example, but it doesn’t need complete access to all your data.    

How scopes control access to specific resources 

You may see details of scopes in notifications that appear within applications that use OAuth 2.0.  

For example, you might be informed that an app can post to your social media account on your behalf and will access your name and e-mail address and contacts.  

Scopes ensure you’re only providing the access that’s appropriate for an app to work.   

Best practices for setting up and managing scopes 

Scopes should be designed so that users can understand exactly what kind of access they’re giving.  

It’s also best to design scopes so that an app only accesses the data it truly needs, which is sometimes called “least privilege.”   

Understanding OAuth 2.0 Access Tokens and Authorization Code 

The purpose and structure of OAuth 2.0 access tokens 

Tokens provide the data that represents the authorization to access a set of resources. They include a header, a payload, and a signature that is validated with a public key.   

How authorization codes grant access to protected resources 

Authorization codes are given to a client once the resource owner has given their consent, which is then exchanged for an access token. These not only include the scopes but the lifetime or expiry date and other attributes.  

Securing access tokens and authorization codes 

It’s important not to send tokens over non-HTTPS connections to avoid security risks. If an access token gets stolen, you can use revocation to tell the authorization it should no longer be accepted.  

How Does OAuth 2.0 Work? 

You may understand the key concepts and structure, but there’s more than that to having OAuth explained in detail. For instance, what is OAuth 2.0 from a workflow perspective?  

Step-by-step breakdown of the OAuth 2.0 workflow 

1. A redirect URL will take the user to a log-in link that uses the application’s client ID and proof of key exchange (PKCE) code challenge parameters. 

2. An authorization prompt is shown to the user (usually containing words like, “XYZ app wants to . . .”).  

3. The user approves the request.  

4. The flow returns the user to the app server, which has the necessary auth code.  

5. The auth code is exchanged by an access token, providing the app the access it has been given.

  

Interaction between the client, authorization server, and resource server 

Here’s the process in a nutshell: The resource owner receives a request sent by the client to obtain an access token from an authorization server. The authorization server gives the tokens to the client once the resource owner has given consent. The resource owner’s credentials remain stored in a resource server (sometimes called an API server).  

Exploring Grant Types in OAuth 2.0 

Different grant types in OAuth 2.0 and their use cases 

There are several different ways for an application to get the tokens it wants to make a request to the resource server. These are called OAuth grant types and they vary based on the kind of client application involved, the level of security required, and whether you want to let the client get a refresh token after the original access token has expired.   

Understanding the nuances of each grant type 

Most of what we’ve described in this post relates to authorization codes, which is the most common OAuth grant type. If you needed to prove the authorization code is authentic to provide a stronger level of security, though, you would use PKCE as your grant type. Devices that don’t have much in the way of display or input capabilities would use a device code. An implicit grant type, on the other hand, provides access tokens as soon as the resource owner gives consent.   

Choosing the appropriate grant type for your application 

The grant type you choose should ultimately be based on how well you trust the client making requests. A request from a third party you’ve never encountered before might require a more secure grant type than one from an application or service you’ve used in other contexts.  

Summing up OAuth 

In basic terms, OAuth is a standard way to authorize others to access your data or application programming interfaces (APIs). Expiring access tokens mean that you’re able to grant permission to applications and services to your data without having to use a password, only authorizing access based on consent. OAuth is authorization, not authentication.  

Combine OAuth with the best in password management. Start your LastPass trial here.