Symmetric vs Asymmetric JWTs

5 min readSep 4, 2018

What is JWT?

JWT or JSON Web Token is string of characters that represents some information. The information in actual is combination of multiple fields separated by a ‘.’ (period).

JWT is a combination of 3 fields:
1. header
2. payload
3. signature

in the following format:

header.payload.signature

A sample JWT (used from jwt.io), You can clearly see the 3 components.

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM

This JWT was generated using RSA256 signature. Below is the JSONs used in generation of the token,

Header:

{
  "alg": "RS256",
  "typ": "JWT"
}

Payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

The header and payload are base64 encoded and passed to the selected algorithm for signature. One must understand this, We only digitally sign the data and do not encrypt it (Well we do encrypt it but using only base64, which is almost like not encrypting. You can decrypt any base64 message easily [Try : base64 decoder]).

The aim of JWT is not to hide the data in any way but to add authenticity of the data i.e. to prove that the sent data was actually created by an authentic source.

For playing around, visit jwt.io.
You can see, the header and payload can be decrypted easily using base64 decoder.

Symmetric signing of JWTs

Symmetric algorithm

In a Symmetric algorithm, a single key is used to encrypt the data. When encrypted with the key, the data can be decrypted using the same key. If, for example, Alice encrypts a message using the key “my-secret-key” and sends it to John, he will be able to decrypt the message correctly if and only if he uses the same key i.e. “my-secret-key”.

HMAC

Hash-Based Message Authentication Codes (HMACs) are a group of algorithms that provide a way of signing messages by means of a shared key ( “my-secret-key” should ring a bell!). In the case of HMACs, a cryptographic hash function is used (for instance SHA256) and the strength of the signature depends on the hashing algorithm being used. By strength I mean, how hard it is to forge an HMAC.

When to use HMAC based JWTs?

HMACs are used with JWTs when you want a simple way for all parties to create and validate JWTs. Any party knowing the key can create new JWTs. In other words, with shared keys, it is possible for a person to impersonate another one.
If you can ensure your secret key will truly be a secret and the clients you share it with are trustable, you can use HMAC based JWTs.

Verification process

User auth request lands on the auth server and after validating the credentials generates a JWT using the secret-key. This JWT is passed back to the application for further API calls. Using this JWT, data requests lands the application server where the server verifies the JWT using the same secret-key which was used to sign the JWT at time of creation.

Asymmetric signing of JWTs

Asymmetric algorithms

In an Asymmetric algorithm, two keys are used to encrypt and decrypt messages. While one key(private) is used to digitally sign the message and the other key(public) can only be used to verify the authenticity of the signature. So basically, John can generate both public and private keys, then send only the public key to Mary to verify his messages.

RSA

RSA is an asymmetric encryption and digital signature algorithm. What asymmetric algorithms bring to the table is the possibility of verifying or decrypting a message without being able to create a new one. This is key for certain use cases.
Picture a big company where data generated by the sales team needs to be verified by the accounting team. If an HMAC were to be used to sign the data, then both the sales team and the accounting team would need to know the same key (the secret-key). This would allow the sales team to sign data and make it pass as if it were from the accounting team.

When to use RSA based JWTs?

JWT is particularly effective where they are used as a single-use authorization token i.e. the token is only expected to be used only once.
For example, you might run a file-hosting service where the user has to authenticate to download their files, but the files themselves are served by a separate, stateless “download server”. In this case, you might want to have your application server (Server A) issue single-use “download tokens”, that the client can then use to download the file from a download server (Server B).

Verification process

User auth request lands on the auth server and after validating the credentials generates a JWT using the private RSA key. This JWT is passed back to the application for further API calls. Using this JWT, data requests lands the application server where the server verifies the JWT using the public RSA key of the auth server. If the data inside the JWT is tampered, the signature verification process will fail.

#learn-something-new

Remember, we need to share our public keys for others to verify our digitally signed JWT? Not only this, sharing of public keys in general may require a manual effort.
To kill this manual work, one can always create a public API which simply returns the public key of your system. And whenever you wish to integrate with some other team or organisation, you can simply tell them to use the public API and get the public key at runtime.
This also comes handy if you in near future sense (or simply spidy-sense) a need to update your keys.

I read many articles (listing from Medium to Security StackExchange and individual blog posts) and went through the code from jsonwebtoken.io JAR.

This article is only a sum up of everything that is required to know what is JWT.