OAuth 2.0 (Open authorization) is an open standard protocol for implementing Authorization. It is the industry standard for online authorization and has replaced OAuth 1.0 in 2012.
It is designed as a means to grant limited access to protected resources (API / user data) in a secure way to third-party applications. The sharing of resources is done without sharing the user credentials, instead it uses an Access Token; usually in JSON Web Token (JWT) format.
It is an authorization protocol and NOT an authentication protocol.
Difference between authorization and authentication
While being often used interchangeably, authorization and authentication serve two different functions.
Authentication is the process of verifying the identity of a user or service. (Who they are)
Authorization is the process of determining the access right of a user or service. (What they can do)
Authorization is done after authentication.
A real life example would be when you do the check-in at an hotel. The receptionist will check your ID to determine who you are (authentication), and then give a key card access to browse the facility. Using the access card to enter your room or the spa at the rooftop would be the authorization.
Why OAuth?
OAuth has been created as a standard and secure way to authorize application to access protected resources.
Here are some use cases:
- A finance aggregator application that keeps track of your expenses, that will connect to your bank to fetch transactions and your account balance.
- An online video game platform that will connect to your social media, e.g. Facebook, to fetch your friends list information to retrieve your friends already playing at the same game
- An application that will use Facebook to create a user account and ask Facebook to retrieve your email address and profile picture to pre-fill your new account.
With OAuth, no passwords are shared between the client requesting the protected resource and the service provider. Instead it uses a system of token exchange to approve one application interacting with another on the behalf of the user.
How OAuth 2.0 works
Roles
OAuth defines four roles:
- Resource owner: It is the user (or system) who owns the protected resources and grant access to it.
- Client: It is the application that want access to the protected resource.
- Resource Server: That’s the protected resource that the client wants to access on behalf of the Resource owner.
- Authorization Server: That’s the application that “knows” the resource owner, where it already has an existing account. It verifies the identity of the resource owner and then, issues the access token to the client.
Scopes
Scopes defines the level of permission and reasons for which access to resources may be granted to the client. The scopes values, and resources they relate to, are dependent of the resource server and the permission the Resource owner agreed to.
Abstract Protocol Flow
Let’s take the example of a Finance aggregator application that wants to access the account balance and your transaction history on your personal bank.
-
The application (client) requests authorization from the user (resource owner) and receives an authorization Grant.
-
The authorization grant is used to obtain an access token from the Bank authorization server.
-
The access token is used to retrieve the protected information from your bank, account balance, history of transactions, etc. (resource server)
OAuth 2.0 Grant types
The grants are the different ways that can take a Client to be granted authorization. The most common OAuth grant types will be listed below, without entering into too much details of the flow.
Authorization Code
The Authorization Code grant is a flow where the client exchange an authorization code to the Authorization server to obtain an access token. This is the traditional approach for Single Page Applications (SPA) and mobile/native apps. However, as the client secret can’t be securely stored, it is recommended to use instead the Authorization Code grant with Proof Key for Code Exchange (PKCE) for better security.
Authorization Code with Proof Key for Code Exchange (PKCE)
It is an extension of the Authorization Code grant with extra steps to prevent CSRF and authorization code injection attacks.
Client Credentials
The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user. Used for non-interactive applications e.g., automated processes, microservices, etc.
Device Code
A grant that enables use by apps on browserless or input-constrained devices devices, such as smart TVs.
Refresh code
Flow to exchange the refresh token to a new access token when the previous access token has expired.
This allows clients to continue to have a valid access token without further interaction with the user. (silent refresh)
Implicit Flow (Legacy)
A simplified flow where the Access Token is returned directly to the Client. It is not recommended to use it as it has security flaw. Instead for public client (SPA / native app), use the Authorization Code with Proof Key for Code Exchange (PKCE).
Password Grant (Legacy)
This is not secure and not recommend anymore. In this flow, the Client had to collect the Resource owner’s password to send it to the authorization server.