JWT Tokens

What are JWT tokens and their different forms —  JWS and JWE?

Hello everyone. In this article, we will be seeing everything you need to know about JWT, JWS, and JWE.

What is JWT?

JSON web token (JWT) is an open standard (RFC 7519) that defines how to contain the information in a JSON format and communicate with different parties. There are many types of tokens used and JWT is just one of them and the most popular one

JWT is smaller in size and very compact that contains all the information a server needs to verify a client. It is very faster and secure and hence widely adopted by many applications and also the frameworks like OAuth and OIDC(Open ID Connect).There are two different approaches to Managing Sessions in an applications

  1. Session or Cookies based approach

In this approach, session Ids are stored in a session DB and the server always needs to verify the session Id hence it is stateful which takes a lot of overhead on the server if there are too many sessions being used in the application

2. Token(JSON Web Tokens) based approach

In this approach, the server authenticates the client and generates the JWT token, and sends it to the client. Then the client sends the JWT token in the Authorization header on every request and the server does not maintain any state hence it is stateless and less overhead. JWT tokens are called Bearer tokens because all the information about the Bearer(User) is self-contained inside the token

Where can a JWT be used?

JWTs have a lot of use cases and some of them are

  • Propagate user entitlements (privileges) between interested parties.
  • Propagate one’s identity between interested parties.
  • Assert one’s identity, given that the recipient of the JWT trusts the asserting party.
  • Transfer data securely between interested parties over an unsecured channel.

Structure of a JSON Web Token?

Having seen what is JWT and its benefits, now let us explore the structure of a JWT token

As seen in the image above, any JWT token will have 3 parts as follows and they are separated by a dot

  • Header
  • Payload
  • Signature

A typical JWT typically looks like the following.

xxxxx.yyyyy.zzzzz

  1. Header

The header of a JWT contains information about how the token was generated with 2 claims name algorithm and the type of the token

{

 “alg”: “HS256”,

 “typ”: “JWT”

}

In the example above, the “algorithm” (alg) claim is set to HS256, which specifies that the HMAC SHA256 is used to generate the token. Then, this JSON is Base64Url encoded to form the first part of the JWT.

2. Payload

The second part of the token is called the payload, which contains the claims. Claims are information about the user and it also contains additional data. There are three types of claims as follows

  • Registered claims: These claims are not mandatory ones but are recommended to be included in the token to provide some useful information. Some of the registered claims are iss (issuer), exp (expiration time), sub (subject), aud (audience), etc.

{

 “sub”: “1234567890”,

 “name”: “John Doe”,

 “iat”: 1516239022,

 “exp”: 1516239999,

 “aud”: “https://example.com”

}

As shown above, the registered claims provide information on the subject, name of the user, token issue time, expiration time, and the intended audience

  • Public claims: These claims can be defined by the system when it generates JWTs. Public claims are required to be universally collision-resistant by defining them in the IANA JSON Web Token Registry or be defined as a URI that contains a collision-resistant namespace.
  • Private claims: Private claims are used to share information between different parties on an agreed basis. These claims need not be registered and are not collision-resistant like Public claims

{

 “sub”: “1234567890”,

 “name”: “John Doe”,

 “iat”: 1516239022,

 “exp”: 1516239999,

 “aud”: “https://example.com”,

 “admin”: “true” – private claim

}

The payload is then Base64Url encoded to form the second part of the JWT. The header and payloads are just encoded and not encrypted and hence secure information should not be stored in those sections unless the token is encrypted. We will go in-depth in the below sections

3. Signature

The Signature forms the third part of the JWt token and to create the signature, we have to use the encoded header, encoded payload, secret, and the algorithm specified in the header and then we have to sign the token.

For example, to use the HMAC SHA256 algorithm, the signature will be created as follows

HMACSHA256( 

base64UrlEncode(header) + “.” +   base64UrlEncode(payload), secret

)

Thus the output of the JWT is 3 Base64-URL strings separated by dots

Decoding JWT Tokens

You can copy any JWT token in JWT.io as follows and you can decode the contents

Types of JWT

There are two types of JWTs namely

  • JSON Web Signature (JWS)
  • JSON Web Encryption (JWE)

JSON Web Signature (JWS)

When we talk about JWT, it’s by JWS by default. The S stands for Signature which allows the tokens to be validated as we saw above in the structure of a JWT. The token we used above is a JWS format because we used the Signature part. JWS is used for authorization which need not be encrypted and visible to the public.

The JWS claims are signed with the private key that can be verified by the server using a public key. The server decodes the token and verifies the message using the signature. If the token is tampered, then the signature of the token will not match with the signature in the token. The Server will also verify the sender of the JWT

The contents of the JWS token are Base64 encoded and not encrypted. Hence use JWS only for exchanging non-sensitive information between the parties

JSON Web Encryption (JWE)

As we saw above, the data in a JWS is public and anyone can decode the token hence it is used only for scenarios that need authorization and not the authentication purposes. A JWE token is encrypted and private and to read data contained within a JWE token, we need both the token and a secret key.

JWE is used for authentication in OIDC as the token contains the credentials and it should be encrypted

The JWE scheme encrypts the content instead of signing it. The content being encrypted here is JWT claims. JWE thus brings Confidentiality. The JWE can be signed and enclosed in a JWS. Now, you get both encryption and signature (thus getting Confidentiality, Integrity, and Authentication).

JWE is used to encrypt the data as well as make it integrity-protected

  • The rogue client or Man-in-the-middle cannot see the data as its encrypted with a secret key.
  • If the rogue client or Man-in-the-middle modifies the payload, the signature verification would fail and the server will reject if found to invalidate the signature.
  • Man-in-the-middle attacks cannot modify it, since the verification would fail

JWKS

The JSON Web Key Set (JWKS) is a set of keys that contains the public keys used to verify any JSON Web Token (JWT) issued by the authorization server and signed using the RS256 signing algorithm.

JSON Web Key (JWK) — A JSON object that represents a cryptographic key. The members of the object represent properties of the key, including its value.

JSON Web Key Set (JWKS) — A JSON object that represents a set of JWKs. The JSON object MUST have a key member, which is an array of JWKs.

Benefits of JWT

There are a lot of benefits to using JWT over other tokens like simple web tokens (SWTs) and Security Assertion Markup Language (SAML) tokens.

  • More compact
  • More secure
  • Ubiquitous
  • Easier to process
  • Stateless
  • Portable
  • Mobile friendly as no Cookies are required
  • High performance
  • Easily Scalable
  • Decoupled / Decentralized

In this article, we started with what is a JSON Web Token (JWT) and how it is different from a Session Cookie. We explored the structure of the JWT and the 2 forms of JWT i.e JWS and JWE. Finally, we ended up with the benefits of JWT

Hope you enjoyed reading this article and thanks for reading.!!!

I work as a freelance Architect at Ontoborn, who are experts in putting together a team needed for building your product. This article was originally published on my personal blog.