Anatomy of a JWT Token Part 1

Executive Summary

In today’s world of distributed systems, a Json Web Token(JWT) provides a very efficient and internet scale way of ascertaining user identities between disparate parties. It helps relying parties to outsource validation of user identity to an identity provider so that relying party can focus on providing the desired service and not worry about providing authentication of the user. This plays out perfectly in the world of micro services where the job of authentication is outsourced to a identity validation micro service. The beauty of the JWT is that it is stateless and hence the relying party can validate the JWT token without calling the identity provider. This is due to the fact that JWT has inbuilt security features due to which its provides sender’s authentication and integrity protection. However, there are many drawbacks with JWT also.

Since, JWT is such a hot topic and different people have different opinions about its security (or lack thereof), I wanted a write a two-part blog post on how JWT works, when would you use JWT, what are the security issues with using JWTs and what are the security best practices when using JWTs.

Here are the contents of the two parts of this article:

Part 1. What is a JWT and where would you use it?

Part 1. What is a JWT and where would you use it?

Part 2. What are the security issues with JWTs and what are the security best practices where creating and consuming JWTs?

What is a JWT?

1. A JWT is a non opaque self contained token that is assigned to a user once they login to a identity provider successfully. Unlike opaque session tokens that require consuming application to call a persistent database to know the identity of the user possessing the token, a JWT is a self contained token that once possessed by the user can be presented to the consuming application. A consuming application can validate and read the contents of the token without calling the issuing identity provider.
2. A JWT has three parts as shown in Figure 1 namely Header, Body and Signature.

Figure 1 Forensic Analysis of a JWT

A JWT takes a form of Header:Payload:Signature (See figure 1 above) where header and payload are both base64URLencoded and signature is generated by encrypting header and payload using an algorithm specified in the JWT spec(see Appendix 1) and then also base64URLencoding it.

Figure 2 How JWT authentication works between authentication server and authorization server

The user who wants to sign in to a relying party goes to the Authentication server to sign in. The authentication server validates the user credentials and creates a JWT. In the JWT, the authentication server includes user assertions like the user name, user first name, user last name, issuer of the token, subject of the token, issue date as well as the expiry date of the token and the user permissions (if applicable) — this becomes the payload of the JWT. Then the authentication server creates a header that says what is the type of the token(type=JWT) and what is the signature algorithm and puts this value in the header of the token. Then it creates a signature of the JWT. This is the most important security aspect of the token. There are two methods to create the signature of the JWT.

The first method to create a signature is to use a common secret cryptographic key to hash the header and payload of the JWT. This is done using a HMAC-SHA256 or HMACSHA512 algorithm that takes in a cryptographic key and hashes the header and payload of the JWT. The application server which is consuming the JWT will get this JWT and it will also take the same header and payload and use the previously shared cryptographic key and HMACSHA256 or HMACSHA512 algorithm (whatever the header says) to create the hash and compare the hash that is included in the signature of the JWT. If both match, it means that the end user or a man in the middle did not tamper with the JWT. And the application server can trust the JWT as no one except the authentication server had access to the cryptographic key. On this assumption, the user is granted access to the resource if the user has the appropriate privilege to access this resource.

The second method to create a signature is to use a hashing algorithm to create a hash of the header and payload and then use a private key to encrypt it resulting in a signature. Then the receiving party also takes the header and payload and creates a hash using the same hashing algorithm and then decrypts the signature using the public key of the sender and compare the hash sent by the sender with the one computed by the recipient. If they match then JWT can be untampered and valid and user is granted access to the resource if the user has the appropriate privilege to access this resource.

Now that you know the basics of how JWT works, I wanted to discuss some of the use cases when you would use JWTs.

Common Use Cases when you would use JWT

1. The major use case of using JWT would be as an access token in an OAuth flow meaning the access token in the OAuth Flow can be of the JWT format. As JWT is self-contained, the client possessing a JWT format access token would not need to call the Authorization server to validate the access token. This is great from a performance and scalability perspective and the security properties of JWT also ensures that JWT can be trusted.

2. Within enterprise when you have separate applications doing authentication and relying applications, then JWTs can be very useful. In this case, the authentication system can issue a JWT to the client application and client application can present this to the consuming application(or a relying party application). The advantage of using JWT in this case is that consuming application does not have to go to the authentication application to validate the JWT. It can validate the JWT signature and have assurance that the JWT is valid and not tampered with.

3. JWT are very useful where you are developing microservices and have different microservices for different parts of the application architecture providing different services. In this case, the consuming application microservices can all rely on the JWTs issued by authentication application microservices who issue the JWTs. This way the consuming application microservices have to provide the service that they provide and not worry about providing authentication services. Using JWTs makes the perfect sense in the microservices world.

Conclusion of Part 1

Now that you now know the basics of JWT, how and where to use them, in part 2 we will go over some of the security issues with using JWT and what are the best practices to avoid them so your JWT implementation is very secure and hackproof.

Appendix 1 Acceptable Signature Algorithms for JWT

Originally published at https://www.linkedin.com on August 26, 2017.