The benefits of JWT + JWS + JWE on API Designs

In this post I cover some good reasons to adopt JWT (JSON Web Token), JWS (JSON Web Sign), and JWE (JSON Web Encryption) in your API Designs.

JWTs are a modern solution to an old problem: how to I know who this user is? They help us by being signed and stateless, and by having a common data format.

JSON Web Tokens work across different programming languages: JWTs work in .NET, Python, Node.js, Java, PHP, Ruby, Go, JavaScript, and Haskell. We can therefore see that JWTs can be used in many different scenarios.

JWTs are self-contained: They carry all the information necessary within itself. This means that a JWT will be able to transmit basic information about itself, a payload (usually user information), and a signature.

JWTs can be passed around easily: Since JWTs are self-contained, they are perfectly used inside an HTTP header when authenticating an API. You can also pass them through the URL.

JWS + JWE Definition

A signed JWT/JWS object can be additionally encrypted, thus providing integrity, authenticity, non-repudiation and confidentiality to data.

  1. The JWT is signed with a private RSA or EC key.
  2. The signed JWT then becomes the payload (plaintext) of a JWE object, which is encrypted with either the public key (RSA or EC) of the recipient, or with a secret key that has been shared between the two parties.

Processing a nested JWT works backwards:

  1. The JWE object is decrypted with the appropriate key (private key for RSA or EC, or established secret key).
  2. The extracted payload (plain text) is then parsed as a signed JWT, and verified with the issuer’s public key (RSA or EC).


The JSON Web Token standard can be used across multiple languages and is quickly and easily interchangeable.

Tokens can be used in a URL, POST parameter, or an HTTP header. The versatility of the JSON Web Token allows us to sign, encrypt and authenticate an API quickly and easily by passing information through the token.

Recent Posts