Last Updated on October 11, 2023 by KnownSense
JWT (JSON Web Tokens) plays a significant role in enhancing the security of microservices in a distributed system. Rather than sending the password for authentication, token use is recommended.
A JWT is essentially a JSON map, which is Base64 URL‑encoded. This is so you can transmit it easier in a header and even in the URL. Although, if the payload is too large, it can exceed the maximum length of a URL or a header.
The message is split into three parts separated by a period.
Let’s deep dive into each part one by one
Middle part: Body
The middle part in the above decoded token is the payload. The standard doesn’t mandate what you can put in here. Generally, it would be the claims about a subject. A claim is effectively a statement that a particular entity has a particular property. Generally, the subject is a user, and claims are assertions about the user like their name, age, gender, data of birth.
Now JWTs have a number of registered IANA claims and are optional for you to include.
- JTI: A unique identifier for the token.
- ISS: Issuer identifies who issued the token, for example the Security Token Service.
- SUB: The subject, essentially the requesting party, who the claims represent, like a user or another service, etc.
- AUD: The audience, who is the recipient of the token? Now this allows the receiver to check if the token was intended for it.
- EXP: The expiry date after which the JWT should not be accepted and processed. Now this is a very important field, especially for signed tokens. If the token gets leaked in any way, then the damage is limited to the duration of the expiry. Hence, it should always aim to be the shortest possible time frame.
- IAT: The issued at time, the time the token was issued. This is very useful to work out how long the token has been alive for. Say the expiry the issuer provided is just too long. The receiver can choose to not accept tokens older than in a certain period of time.
Last Part: Signature
The last part of the JWT is the signature. Now JWTs are signed using the web signatures specification, which is a Base64‑encoded header and payload concatenated with a period and signed with the algorithm specified in the header. JWTs can also be encrypted to prevent the content being read by unwanted parties using the JSON Web Encryption specification.
First Part: Header
At the top, we have the header, which has the field type to identify the algorithm used to encode or encrypt the token. This uses the JWA Web Algorithm specification format.
JavaScript object signing and encryption
JWT uses a number of specifications to handle signing and encryption of tokens and validating the signature. The collection of all these specifications is known as the JavaScript object signing and encryption. JWTs are so popular because they are Base64 URL encoded, you can put them almost anywhere, inside headers, query strings, making them very mobile‑friendly, which is why it is replacing SAML. Developers can use the JOSE library to easily decode them. However, this flexibility can leave the system compromised if not correctly implemented. Example, the algorithm claim in the JOSE header supports none, basically an unsecured JWT. Now this exploit existed in a number of libraries where a malicious party could create a forged JWT with the none algorithm, and the library passed the JWT validating the token. Now the exploit was to downgrade the algorithm type to a symmetric key algorithm and sign the token with the recipient’s public key. Hence, your implementation should either ignore this header and mandate its own algorithm or mandate a selected group of strong algorithms. Now the JWT specification defines some optional claims that you would expect to have in a token. However, they are optional, and they lack the detail on the format of the field and how our clients should authenticate, receive, and exchange the tokens. Now we could implement our own solution for that, but that would make it harder for us to integrate with external clients and libraries or expose our API externally. Fortunately, there are other standards like OAuth and OpenID Connect which can leverage JWTs and help us achieve this.
Challenges with JWT
JWTs are very flexible. This has a number of benefits. By exchanging our tokens, we can narrow the audience and claims on the token to a bare minimum, reducing the blast radius of any leaked tokens. Additionally, it simplifies token revocation. If a token gets leaked, we can invalidate it at the authorization server, and it will instantly not be accepted by any of our services. However, it’s not very scalable and can impact the performance of your application. The authorization server can also become a bottleneck and a single point of failure. There is additional token acquisition cost and token verification cost. One of the key selling points of JWTs is their ability to decentralize state in a large, distributed system through the ability to verify the integrity of the token offline via the signature and even provide confidentiality with encryption. But that also introduces challenges, such as the revocation challenge. If you are verifying tokens offline, how do you revoke a token if a user logs out or wants to invalidate a token it delegated to a client or in the event the token was leaked? Outdated claims. What if a claim on the token has changed after it was minted? Perhaps a policy change and the subject no longer has admin privileges, but the token still has the admin scope. Now there is no one‑size‑fits‑all solution. Some trade‑offs between performance and scalability versus complexity of a solution to this needs to be taken.
Conclusion
JSON Web Tokens (JWTs) are integral to enhancing microservices’ security in a distributed system. Instead of transmitting passwords, JWTs are recommended for authentication. JWTs consist of three parts: the header, payload, and signature. The payload typically includes claims about a user, which can be registered or custom, and the signature ensures data integrity. JWTs are versatile and can be used in headers or URLs. Challenges with JWTs include scalability concerns, token revocation, and outdated claims. Proper implementation is vital, and JWTs can be leveraged with standards like OAuth and OpenID Connect to enhance security in distributed systems.