What is OAuth 2.0 ? How does it work ?
Say, you have a social media account, in which you have saved your private as well as public information. You have an app called “Who are my closest friends”, which you are desperate to try out. This app requires access to the protected information in your social media, that is: your friend list, perhaps your email. In order to grant access to your friend list, you have to provide the login credentials of your social media to the application. Now you are giving the full access to your social media account to an application, which you barely know. Application can now act as you, posting anything, reading any messages. This possesses a huge security threat.
This is where secure access delegation comes into play. In simple terms, secure access delegation means proving limited access to an otherwise protected resource on behalf of a user. The classic example for access delegation is the valet key of a car. The valet key of a car only provides access to the necessary parts of the car, like driver-side door, engine start. It will restrict the access to glove box and trunk. In this way, the things in you stored in glove box or trunk remains protected.
- How OAuth fit into all this?
OAuth is an open standard that applications can be used to provide client applications with secure delegated access. OAuth works over HTTPS with access tokens rather than using credentials. There are two versions of OAuth, OAuth 1.0a and OAuth 2.0. The most widely used form is OAuth 2.0, which we are going to talk about here.
How does OAuth provide access delegation ? The usual use case of OAuth involves an user, a resource server which has protected resources of the user, an authentication server or a identity provider, a client application requesting access to protected resources. With OAuth 2.0 standard, the client application can access the resource server on behalf of the user. In order to achieve this access delegation, an access token is used by the authentication server to client application.
Let’s revisit our “Who are my closest friends” application scenario, now with OAuth 2.0. Earlier to give access to your contact list you had to provide the credentials to your social media account, which had a great security threat. But now with OAuth 2.0, you can ask your social media account to provide the client application (i.e. “Who are my closest friends” application) an access token on behalf of you. This token will contain the your consent and many other field which are necessary to the access delegation.
There are several ways, in which a client application can request access tokens from an authentication server. These are called grant types.
- Authorization Code
In authorization code grant type, client application sends an authorization request to an authentication server. The server authenticates the user and prompts the user to approve the access delegation to the said client application. If approved, an authorization code is sent to the client application which can be exchanged for an access token in an authenticated backend call. Usually, apart from the access token which is short-lived, client application will receive a refresh token, which can be used to request a new access token. In this grant type, user only enters their credentials to the authentication server. Therefore the access delegation is secure.
- Client Credentials
In the client credentials flow there is no user involved. This flow is strictly for server-server communication. In this flow the client application passes its credentials to an authorization server and gets an access token. There’s no need for a refresh token as client can always request another access token using its credentials.
- Device Code
This is used in input-constraint devices to exchange a previously obtained device code for an access token. In this method, the device asks user to open an URL in a browser of a secondary device. While user completes the authorization flow on their secondary device, primary device will poll the authentication server for an access token. If user approves, the authentication server will respond with an access token and if user denies server will respond with an error. If user hasn’t completed the authorization flow, server will respond with a “Authorization Pending” response.
- Refresh Token
Refresh token grant type is used to receive a new access token for a previously issued refresh token ( in authorization code grant type) when the previous access token is expired. This allows client application to get an access token without any user interactions.
- Legacy Grant Types
The implicit flow and password grant are now considered as legacy grant types as they contain a security vulnerabilities. Let’s see why the implicit flow is now considered legacy . Implicit flow was used by public clients such as native apps and JavaScript apps. Implicit flow starts out in the same way as the authorization code grant type. But instead of sending an authorization code, the server responds with, an access token. The problem here is, the token is sent to the client application through an user-agent (i.e. browser). Due to visibility of the token and inherent security risk of returning a token in a HTTP redirect without any confirmation that is has been received by the client application, now the OAuth 2.0 standard suggests client applications to use the Authorization Code Grant Type with PCKE extension.
While article might provide you an introduction, I suggest reading OAuth 2.0 Specification for further understanding on OAuth 2.0. Also you can experiment on different grant types on OAuth 2.0 Playground.
