OAuth2 Demystified
When you try to access a mobile app or website (Web app), you are often asked to use your Google or Facebook account to log into it. You type in the credentials (your ID and password) and are presented with a screen that allows access to some of the information (e.g., access to your contact, access to SMS, camera, etc). You trust it and proceed. It sends a SMS with an OTP. You key in the OTP and voila, you have access to the app or website.
This is something we have done a number of times.
This article talks about the fundamental principle around this mechanism – the all-pervasive and ubiquitous Open Authorization, aka OAuth. The current version is 2 or OAuth2.
What is OAuth2?
OAuth2 is an authorisation standard or framework, and not really a protocol as such. It has nothing to do with authentication, but is an authorisation delegation framework. Apps practice authorisation in other ways also. One standard way is the session token based system. The sequence diagram in Figure 1 explains this.
However, nowadays, applications are far from monolithic. They often deploy domain sharding (subdomaining) for the resources in order to extract more parallelism out of the networking layer — layer-4 in the networking stack. Every domain needs to consult the same store of access tokens against credentials, every time a user accesses the resource. Hence, the token store is a single point of failure for the whole application ecosystem.
Tenets of OAuth2
Table 1 lists different participants or tenets in the OAuth2 ecosystem.
In the era of rapid application development and deployment as well as concerns around security and privacy, the OAuth2 authorisation is a huge boon.
How OAuth2 works
Let us start with an interaction diagram (Figure 2).
Here are the steps:
1. User wants to print a photo using a photo application.
2. User opens the photo application.
3. User authenticates using credentials. The application, in turn, contacts the authentication entity (AD, Kerberos, etc) for the user identification.
4. Authentication is successful.
5. Now, OAuth2 comes into play.
6. Photo application contacts authorisation server for access permission with specifying scope (“please allow me to access user’s photos stored in your server”).
7. Auth server silently asks the user if it can trust the photo application.
8. User gives a nod.
9. Auth server issues an authorisation token.
10. The authorisation token is passed to the application.
11. Application asks for an access token for passing the authorisation token.
12. Auth server verifies the auth token, and gives a JWT format access token with a limited expiry. (This double token business — authorisation and access token—is for safety, as it will be very difficult for both to be compromised.)
13. Application securely stores it in its vault.
14. Application contacts the resource server by passing the JWT token as the http Authorization: bearer
15. The photo is presented to the application.
16. The application processes it and returns it to the user.
OAuth2 and microservices
The workflow we discussed above is the standard reference sequence of how OAuth2 works. However, in practice, we sometimes see a slight variation of the above. Step 9 to Step 11 (authorisation token and access token) are generally shortened into one step. This variation is called ‘Implicit OAuth2’.
How does this microservice architecture fit into this whole OAuth2 story? The client microservice contacts the auth microservice to acquire the authorisation token and subsequently the access token, to get served by the resource microservices.
JWT
Let us look at what is inside the JSON Web token (JWT). The access token anatomy looks like what is shown in Figure 3.
In case it is found that the JWT token is stolen or compromised, the server can be notified of this incident and it can blacklist the token. Figure 4 gives the sequence diagram of how this works.
Takeaway
When we loosely say ‘auth’, it indicates two completely orthogonal but correlated things—the authentication and the authorisation. In this article, we talked about the latter using the industry standard OAuth2 mechanism. The idea behind OAuth2 is the delegation of authorisation using an independent authorisation server or microservice. An application, in lieu of the user, asks for authorisation permission from the authorisation server in two steps: the authorisation token, followed by the access token. The access token has three layers of security — the secret key that is never passed out of the authorisation server, the token that comes with a predefined expiry stored securely in the application, and the application to resource server which is SSL/TSL encrypted. In this way, OAuth2 ensures airtight and invincible security, making it a widely accepted and adopted framework for authorisation.