OAuth

OAuth is an open-standard framework for API authorization. It defines how an API client can obtain security tokens that express a set of permissions against the resources fronted by that API. These permissions often reflect the consent of the user that owns those resources. The tokens are attached by the client to its API messages to serve as proof of the client’s authorizations relative to the requests it makes of the resources.

Instead of requiring a user to share login credentials with one application in order to give that application access to another, OAuth delegates authorization decisions to a separate authorization server that hosts the user account. Essentially, OAuth acts on behalf of the user, providing delegated access to a third-party service without the user exposing their credentials to that third party.

For example, if you create an account on YouTube, and YouTube offers you the ability to sign on with your Google credentials, you can be authorized to access YouTube resources with those credentials without you ever having to supply them.

Note: OAuth 1.0a and OAuth 2.0 are the two different specifications available. They are different from each other, cannot be used together, and are not backward compatible. But most people today use OAuth 2.0, so that’s the specification we discuss here. 

The hotel check-in process is another example of how OAuth works. You visit the front desk and authenticate yourself by providing your ID. After you’ve proven who you are, the concierge at the desk exchanges that information for a hotel key card.

Your key card allows you to access your room, as well as the pool and fitness room. However, you will not be able to access the custodial closets to get additional towels yourself because you lack authorization. 

The hotel check-in process is similar to the OAuth authorization process:

• The hotel can revoke your access at any time, just as the authorization server can revoke access at any time.
  
  
• Your key card does not have your identity or credentials on it, just as the access token granted by the authorization server doesn’t require user information to be included.
  
  
• You can use your keycard to access multiple hotel resources. In a similar way, the access token lets you access specified resources and denies access to others.
  
  
• Your key card will expire when you check out of the hotel. Your OAuth access token will also expire.
  

How does OAuth work?

Users give one application permission to access data in another application without having to provide their usernames and passwords. Instead, access tokens are used to complete the authorization process.

These tokens contain information about the authentication session, the user identifier, an identifier for the identity provider who issued the token, and an identifier for the client for which the token was created. Tokens also contain information about the length of time they'll be valid and the length of time that has passed since the authorization process began. 

With OAuth, there are four different roles:
 

• Resource Owner: The resource owner is you. You own your data and authorize an application to access your account information. 
   

• Client: The client is the application that wants to access your account information. Before it can access this information, you must authorize it, and the authorization must be validated by the API.
   

• Resource Server: The resource server hosts protected user account information.
   

• Authorization Server: The authorization server verifies the identity of the user then issues access tokens to the application.

There are a variety of different OAuth flow types available, but here's how OAuth flows work at a high level:

1. When you sign on to an application, you’re prompted to authorize or deny the client application access to your account information. 
   
   
2. When you authorize the request, the client application receives an authorization code.
   
   
3. The application presents authentication of its own identity, the authorization code to the authorization server, and requests an access token.
   
   
4. If the application is authenticated and the authorization code is valid, the authorization server issues an access token to the application. Access tokens are similar to badges or key cards that give the client permission to perform specific actions on your behalf. Scopes are included in the token and define these permissions.
   
   
5. The application requests the resources from the resource server API and presents the access token.
   
   
6. If the access token is valid, the resource server API provides the user with a redirect URI that provides access to the application and the appropriate resources.
   
   

OAuth is not an authentication protocol

OAuth is used in a wide variety of applications and is used in a variety of different ways, which is why many people think it’s an authentication protocol, but it’s not. It even says so on their site. 

Much of the confusion comes from the fact that OAuth is used inside of authentication protocols, and developers will see the OAuth components and interact with the OAuth flow and assume that by using OAuth, they can authenticate their users. 

But there are a lot of different ways OAuth can be used, OAuth doesn’t define a specific token format or a common set of scopes for the access token, it doesn’t address how a protected resource validates an access token, and identity providers implement API identity differently, so custom code might be needed to integrate with vendors.

For example, a user's identifier might be found in a user_id field with one provider but in the subject field with another provider. Even though these identifiers are semantically the same, they would require two separate code paths to process. In other words, while the authorization might happen the same way at each provider, the ways in which they are conveyed could be different.