JOSE

By default, JSON Web Tokens (JWTs) are base64url encoded JSON objects signed using a digital signing algorithm thanks to JSON Web Signatures (JWS). JWS assures integrity, authentication, and non-repudiation, but it does not provide you with confidentiality. Anyone can read the payload, which can be an issue if the token holds any sort of sensitive data. So, how do you prevent this? How do you encrypt a JWT?

This is where JSON Web Encryption (JWE) comes in. JWE allows you to encrypt a JWT payload so that only the intended recipient can read it while still providing integrity and authentication checks. Combine this with JWS, and you have an encrypted token suitable for use as an access token in OAuth or an identity token in OpenID Connect.

In this article, you will learn how to protect sensitive data by encrypting your JWTs, how JWE works, and what encryption algorithms are typically available.

JSON Web Tokens (JWTs) can be signed using many different algorithms: RS256, PS512, ES384, HS1; you can see why some developers scratch their heads when asked which one they would like to use.

In my experience, many of the mainstream identity providers have historically only offered RS256 or at least defaulted to it. However, thanks to initiatives such as Open Banking, these identity providers are now expanding their support to cover more signing algorithms, which means you will need to start understanding which ones to use.

JSON Web Tokens (JWTs) get a lot of hate from the wider crypto community, but what are the alternatives? In this article, I am going to give a high-level overview of some of the recommended alternatives mentioned in Twitter rants and attempt to provide an opinion on whether or not they can replace JWTs.

I in no way want to become the defender of JWTs; this is not the hill I want to die on. However, with the increasing hate on JWTs and what I see as misunderstandings around them and their alternatives, I felt that I had to put something into writing to clear my head.