15

I am trying to understand JSON Web Tokens and got to learn that Base64 is the encoding used in them. As base64 can be decoded easily, my question is why to use them. Why not use a one-way hash function to generate the token?

Please spare me if the question seems silly

simhumileco
  • 31,877
  • 16
  • 137
  • 115
abi24m
  • 161
  • 1
  • 1
  • 5

2 Answers2

16

JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

In fact, JWT is a generic name for the following types of token:

  • JSON Web Signature (JWS): The payload is encoded and signed so the integrity of the claims can be verified.

  • JSON Web Encryption (JWE): They payload is encrypted so the claims are hidden from other parties.

As base64 can be decoded easily, my question is why to use them.

JWT uses Base64url, which is slightly different from Base64.

One of possible reasons why Base64 is used: it's a very popular encoding format and it's very easy to use it in most of programming languages. Also, Base64url is URL-safe, so the tokens could be sent in the URL.

Why not use a one-way hash function to generate the token?

It defeats the purpose of signed JWT, as the receiver wouldn't be able to parse the content of the token.

Community
  • 1
  • 1
cassiomolin
  • 124,154
  • 35
  • 280
  • 359
  • Thanks. I completely missed the fact that without knowing the actual payload the server cannot validate the identity. +1 – abi24m Oct 12 '19 at 14:18
  • 2
    I came across the same question and I asked myself why using base64 in JWT AT ALL, since it enlarges the string. However your mentioned fact "[...] Also, Base64url is URL-safe, so the tokens could be sent in the URL. [...]" seem to me like the only point to use it in this format. – Limon Dec 23 '22 at 11:16
4

You are correct base 64 is easily decodable, but the 2 sections (Header & Payload) that are based 64 encoded was not meant to be hidden.

Just a general introduction, a JWT token consists of 3 sections nl. 1.Header (Algorithm) 2.Payload (User Data) 3. Signature

The header and the payload contain non-sensitive data but this data provides enough information to assist you in identifying the user that presented you with the token. So for you to be able to grant him a refresh token or allow him access to some resource you need to know some information about him without the user having to give his credentials on each call.

So yes it is easily decoded but that is what the 3 section is for the signature. The Signature takes the header and the payload's base64 encodes values and hash them with some secret key. This is done so when the key comes in to your back end from the client we can first check to see if the payload (which could contain permissions) have note been altered or changed if they have the hash value of the token would not be the same anymore.

For more information you check ou the following resources: https://jwt.io/ (To see structure) https://jwt.io/introduction/ (General Info)

Terblanche Daniel
  • 1,169
  • 2
  • 12
  • 18