Session vs JWT (token based authentication)

Am building a CMS for a service and we need authentication for the same. I’ve done a lot of coding by accident in my college. Stackoverflowing and googling to get the work done. One of those things are the session. I have been making many authenticated services since Sophomore year and I’ve used session multiple times without looking for its alternatives. This blog will tell more about what is session, what is token based authentication with some pros and cons for both.

Session

Lets start with session. This is the time where the servers were slaved. This is the case when the server takes care of all the authentication. Client has very less idea of whats happening around.

Use case: I want to login. I send the post request to the server with username and password. If they are correct, I set a cookie in the browser for this specific session id. Also I store the details in the server (file/local storage/in memory). This cookie is encrypted by some secret in the server. (app.secret_key in Flask. Thats why its always complex). So for session id — 20, the cookie would be bhfsbdkjfbsjkd8484049hjjhfgkdh9iuhuihuh43i85945. Flask does it by its encrypting algorithm. Every time a new request comes to get the authenticated data, this cookie is sent along with that request. Flask decrypts it to the session id and then it checks in its file/local storage/in memory db to see if the user is authenticated or not.

Authentication Token

Now lets go the time when servers revolted against their masters (the clients). They argued that clients should also do some work. They believed in the stateless ideology and demanded that it be followed.

Same example — Authentication. Post request sent to server with username and password. If they are correct, the server creates a token and returns to the client. Client sends the jwt token on every further request to get the authenticated. Thus making REST actually stateless.

Whats JWT?

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with HMAC algorithm) or a public/private key pair using RSA.

JWTs consist of three parts separated by dots (.), which are:

• Header — The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
  For example:

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

Then, this JSON is Base64Url encoded to form the first part of the JWT. Have explained Base64Url encoding below.

• Payload — This contains the claims. The data we want. An example payload could be:

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

The payload is then Base64Url encoded to form the second part of the JSON Web Token. This is readable by anyone as its just encoded. Its not encrypted. Encoding is just conversion from one form to the other. So avoid using sensitive data like Aadhaar number here.

• Signature — To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.
  For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

The signature is used to verify the message wasn’t changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

When we receive the token, the first thing we do is to verify the signature. We decode the header and payload and then make this signature with our secret as with the above algorithm. If they match, its a signed JWT.

Therefore, a JWT typically looks like the following.

xxxxx.yyyyy.zzzzz

What is Base64UrlEncode ?

This is an encoding. That is converting from one data type to other. Sending ASCII bytes can be problem in many paths. So, encode the data in base64. There are 64 characters. Url encoding means that its safe to send as url. Eg: - is used instead of +and _ is used instead of /

Follow this link for the algorithm to convert from any base to any base. (This would take you to the nostalgic high school ride)

Why JWT?
This is purely stateless. With Horizontal scaling, we would have to use sticky sessions (load balancer directing to same box everytime) or other techniques with sessions but not with JWT.

JWT’s can be bulky (payloads). They are large compared to session id. But they don’t involve any operation with storing values on server.

JSON Web Tokens (JWTs) are lightweight and can easily be used across platforms and languages. They are a clever way to authenticate & authorize without sessions. There are several JWT libraries available for signing and verifying the tokens. There are also many reasons to use tokens, and Auth0 can help implement token authentication in an easy and secure way.

Personally, I don’t think there is a one-size-fits-all approach. It will always depend on your application architecture and use case.

Ping me for random conversation at me@abhinavrai.com