This article provides an overview of the OAuth 2.0 protocol. It discusses the different actors and steps involved in the process of OAuth 2.0 implementation.
Introduction
OAuth stands for Open Authorization. It’s a free and open protocol built on IETF standards and licenses from the Open Web Foundation. It allows users to share their private resources with a third party while keeping their credentials secret. These resources could be photos, videos, contact lists, location and billing capability, and so on, usually stored with another service provider. OAuth does this by granting requesting (client) applications a token once the user approves access. Each token grants limited access to a specific resource for a specific period.
OAuth 2.0 Is a Delegation Protocol
OAuth 2.0 supports “delegated authentication,” i.e., granting access to another person or application to perform actions on your behalf. Consider this scenario: you drive your car to a classy hotel, they may offer valet parking. You then authorize the valet attendant to drive your car by handing him the key to let him perform actions on your behalf.
OAuth 2.0 works similarly—a user grants access to an application to perform limited actions on the user’s behalf, and access can be revoked when it becomes suspicious.
Actors Involved in OAuth 2.0
There are several actors involved in OAuth 2.0.
- Resource server: the server hosting user-owned resources that OAuth 2.0 protects. The resource server validates the access-token and serves the protected resources.
- Resource owner: typically, the user of the application is the resource owner. The resource owner can grant or deny access to the data hosted on the resource server.
- Authorization server: the authorization server gets consent from the resource owner and issues access tokens to clients, allowing them to access protected resources hosted by a resource server.
- Client: an application making API requests to perform actions on protected resources on behalf of the resource owner. Before it may do so, the client must be authorized by the resource owner, and the authorization must be validated by the resource server and/or authorization server.
OAuth 2.0 defines two client types based on their ability to securely authenticate through the authorization server (i.e., their ability to maintain the confidentiality of their client credentials):
- Confidential: clients capable of maintaining the confidentiality of their credentials. Confidential clients are implemented on a secure server with restricted access to client credentials (e.g., a web application running on a web server).
- Public: clients incapable of maintaining the confidentiality of their credentials (e.g., an installed native application or a web browser-based application) and incapable of secure client authentication via any other means.
You Are an Application Developer, Here Is a Use Case:
Consider a scenario: You are developing a Facebook fun app (call it “FunApp”). FunApp needs access to user’s public profile, photos, posts, friends, etc. The problem is: How can FunApp get the user’s permission to access his/her data from Facebook? Simultaneously Facebook should be informed that the user has granted permission to FunApp so that Facebook will share the user’s data with this app.
The Old Way:
The user shares his or her Facebook credentials (username, password) with FunApp. This approach has some challenges:
- Trust
- Unrestricted access by the app
- What if the user changes their Facebook password?
- Etc.
The OAuth 2.0 Way:
FunApp redirects users to a Facebook authorization page when the app needs access to Facebook user data. Users would log in to their accounts and grant access. Then FunApp gets an access token from Facebook to access the user’s data.
While OAuth 2.0 has solved some challenges, it also created costs for developers. Developers need to learn and implement OAuth .02 framework for their APIs.
Let’s See This Scenario from Developer’s Eyes and Find Out the Actors Involved Here:
- Facebook, having all of the needed resources (user’s public profile, photos, posts, friends, etc.), becomes the Resource Server.
- The user is the Resource Owner.
- FunApp requesting for user’s protected resources becomes the client.
- Facebook gets the user’s consent and issues the access token to FunApp, making it the Authorization Server.
Register the Client (FunApp) and Get Client Credentials
OAuth requires that the client registers with the authorization server. The authorization server asks for some basic information about the client, such as name and redirect_uri (the URL where the authorization server will redirect when the resource owner grants permission). It returns client credentials (Client-id, Client-secret) to the client. These credentials are critical in protecting request authenticity when performing operations such as exchanging authorization codes for access tokens and refreshing access tokens. For example:
Facebook requires you to register your client on the Facebook developers portal. You must go to Facebook for Developers and register FunApp to get credentials.
Get Access Token Step-By-Step
FunApp needs to get an access token from Facebook to access the user’s data. To obtain this access token, FunApp redirects the user to Facebook’s login page. On successful login, Facebook redirects on the redirect_uri (as registered in step 4) along with the short-lived authorization code. FunApp exchanges the authorization code to get a long-lived access token. This access token grants access to the user’s data. This is the most popular flow in OAuth 2.0 called Authorization code grant.
Understanding Authorization Grant Types
To get the access token, the client obtains authorization from the resource owner. Authorization comes in the form of an authorization grant, which the client uses to request the access token. OAuth 2.0 defines four standard grant types: authorization code, implicit, resource owner password credentials, and client credentials. It also provides an extension mechanism for defining additional grant types.
1. Authorization Code Grant
This grant type is optimized for confidential clients (web application servers). The Authorization Code flow does not expose the access token to the resource owner’s browser. Instead, authorization uses an intermediary “authorization code,” passed through the browser. This code must be exchanged for an access token before calls can be made to protected APIs.
2. Implicit Grant
This grant type is suitable for public clients. The Implicit Grant flow does not accommodate refresh tokens. If the Authorization server expires access tokens regularly, your application will need to run through the authorization flow whenever it needs access. An access token is immediately returned to the client after a user grants the requested authorization. An intermediate authorization code is not required as it is in the Authorization code grant.
3. Resource Owner Password Credentials
The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client. The resource owner agrees to share his or her credentials (username, password) with the client. Then the client uses the resources owner’s credentials to get the access token from the authorization server.
4. Client Credentials
This grant type is suitable when the client itself owns the data and does not need delegated access from a resource owner. It is also used when delegated access has already been granted to the application outside of a typical OAuth flow. In this flow, user consent is not involved. The client exchanges his client credentials to get an access token.
Token Expired, Get a New Access Token
API calls using the OAuth 2.0 access token may encounter errors if the access token is no longer valid because it expired or was revoked. In this case, the resource server will return a 4xx error code. The client can get a new access token using the refresh token (a refresh token was obtained when the authorization code was exchanged for an access token).
Conclusion
OAuth 2.0 is becoming a popular solution for protecting APIs. This guide is an attempt to provide an overview of the OAuth 2.0 process, as well as explain how to obtain an access token. I hope it has been helpful.
References:
The OAuth 2.0 Authorization Framework RFC6749.
Getting started with oauth2 by Ryan Boyd
