Gatekeepers of the Treasure-house — Part 2
Let’s continue our expedition and see what else can be brought to make sure that the system we are building is secure and has a strong defense against any kind of attack. We will resume from where we left in our previous article which can be referred to here.
Just to summarize in the previous article, we talked about the need for having dependable Authentication and Authorization mechanism, and specifically, we delved deeper into the Authorization part and saw how this can be achieved according to the specifications and guidelines provided by OAuth 2.0.
OAuth 2.0 in general is an Authorization framework as it majorly deals with permissions that ‘The Client Application’ can get on behalf of ‘The Resource Owner’ from ‘The Authorization Server’. At no point in its journey does it deals with the Profile data (name, email, age, gender, etc.) of the user. Although, we saw that ‘The Client Application’ can send ‘profile’ in the ‘scope’ field while sending a request that goes to ‘The Authorization Server’ and can get some part of the user profile back but this is literally just about it! In case ‘The Client Application’ needs to fetch more details around the user, there was no better way available for the same.
Incomes OpenID Connect
OpenID Connect saw the light of the day in 2014 and is a standard for Identity Providers (IdP) and since the beginning, it became a common buzzword owing to its simplicity, as it was based on OAuth 2.0, and it was easy to consume, as the tokens they generated were in JSON format.
Upon successfully authenticating with Identity Providers, the user is issued an Identity Token. This works as a gateway for entering into the system, as it possesses the claims, but at the same time, the user is not allowed to perform an inch extra which is not part of the claims that the token carries.
How to get one?
As briefed above, OpenID Connect is based on OAuth 2.0 or rather we should say that it is an extension of OAuth 2.0. The mechanism of implementing it is also not very much different from OAuth 2.0 flows that we have covered here.
Summarizing them, there are two parts to it as long as we are talking about a typical web application that has a frontend that is supported by a backend.
- Getting the Authorization Token: The frontend of ‘The Client Application’ makes a call to an OpenID complaint ‘The Authorization Server’ as shown below:
In the above call, there is one difference from the regular OAuth 2.0 call. As can be seen, we are sending ‘openid’ and ‘profile’ as part of the ‘scope’ field. This tells ‘The Authorization Server’ that ‘The Client Application’ is interested in getting the ID Token along with the Authorization Code.
2. Getting the Access Token: As we saw in the previous post the next step in the OAuth 2.0 protocol is to exchange the Authorization Code with ‘The Authorization Server’ to get the Access Token. The backend of ‘The Client Application’ will send the Authorization Code to ‘The Authorization Server’ and in response ‘The Authorization Server’ will send back the Access Token along with the ID Token, as in Step#1 ‘openid’ was also sent as part of the ‘scope’ field.
The URL for the above remains the same as was the case with normal OAuth 2.0 exchange
Upon success, ‘The Authorization Server’ will generate a response that looks like below:
{
“id_token”:“eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c”
“access_token”: “SlAV32hkKG”,
“token_type”: “Bearer”,
“expires_in”: 3600,
}
The value that we see for ‘id_token’ field appears to be a gibberish sequence of characters but actually, it has significance and is popularly know as JSON Web Token or JWT in short. Every JWT token has 3 main parts: Header, Payload, and Signature.
Along with ‘id_token’ we can see the response also contains ‘access_token’ this is to ensure that the exchange between the backend of ‘The Client Application’ and ‘The Authorization Server’ is an OAuth complaint. Any subsequent request to ‘The Resource Server’ from the backend of ‘The Client Application’ has to have the Access Token.
As part of the JWT Token ‘The Client Application’ will get the basic information of the user that comes embedded within the ‘payload’ part of the JWT Token, but should there be any further need by ‘The Client Application’ to fetch more details for the user, they can invoke a dedicated endpoint /userInfo available on the OpenID compatible Authorization Servers.
What comes by default
OpenID connect specifies a standard set of claims and they provide ‘The Client Application’ all the basic needs for all that it needs to know about a user. ‘The Client Application’ should ensure that they are putting the ‘claims’ to as low or as much as needed. At any later point, the user can deny the release of some claims, and the application should be able to handle such situations gracefully.
There are a couple of ways in which ‘The Client Application’ can get the claims they are after:
- By explicitly passing what they need in the ‘scope’ field. A complete list of what they can send in ‘scope’ field is covered here
- By sending the optional ‘claims’ parameter in the request. As shown here
Original Specs
More on the subject can be found here
Conclusion
In these two posts, I’ve tried to add more light to the two aspects of OAuth 2.0 and OpenID Connect which is an extension of OAuth 2.0 especially around the usage and intent of these two specs.
