Stateless Authentication in Web Applications

+ 2 comments

In this edition, Abhijeet Thakur (abhijeet.thakur@indexnine.com) talks about Stateless Authentication in Web Applications.


Traditionally, web applications were built as a monolithic app, designed to scale within a given server. In order to authenticate valid users, the classic approach was to use a “cookie” or a small object containing user information and store it in a “session” object on the server side. (more about session). In this approach, “state” information was stored and retrieved at the server side.

This approach has limitations when it comes to scaling the application in question. Contemporary applications use “stateless authentication”, which avoids storing any kind of state on the server side.  Stateless authentication has the advantage of being suitable for web applications that are horizontal in nature, thereby allowing the app to scale by adding more servers to process requests.
In stateless authentication, client sends user-specific identification data to the server as part of the login process, and if the data is correct, the server responds with a valid token to the client. After the authentication is done, the client uses this token to send further requests, without giving any user-specific identification. The token sent by client contains all the information to validate a user, therefore any server can validate any user, allowing the user to scale the application horizontally.
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 the HMAC algorithm ) or a public/private key pair using RSA. ( More about JWT token )

JSON Web Token consist of 3 parts separated by dot ( . ), which are Header, Payload and Signature. JWT typically looks like the following.

jwt.png
JWT has several advantages, including its stateless nature,  JWT tokens can be set to expire, so the same token cannot be reused indefinitely.

Just throw away the token when you're done with it, it will expire on its own. So, web applications no longer need to be logged out after every session.  A network round-trip (e.g., finding a session in the database, deserializing it, then extracting the information you're interested in) is likely to take more time than calculating a HMAC SHA256 to validate a token and parse its contents.So, JWT also helps improve performance.

JWT tokens are very widely used for authentication of REST applications. Researching JWT authentication best practice implementations for web applications can be very confusing.  This is in part due to the variety of ways one can implement JWT authentication. In our experience, an interesting plugin to implement JWT authentication in dropwizard is "dropwizard-jwt-cookie-authentication".

Dropwizard-jwt-cookie-authentication plugin is very simple to use. It stores and reads the jwt token directly into the cookie of the browser. So there is no need to store and add the token to each API request. This saves front-end developers the hassle of doing it themselves.This plugin is a dropwizard bundle, and is a breeze to be integrated in the back-end code. It automatically serializes/deserializes session information into/from JWT cookies.

Dropwizard-jwt-cookie-authentication plugin has built in functionality to create JWT tokens. To add Dropwizard-jwt-cookie-authentication bundle in dropwizard, add the dependency in your application. Default value to expire session tokens is 30 minutes and default value to expire persistent tokens is 7 days.

References:

Summary : JWT authentication is a secure and efficient way to authenticate users for horizontally scalable applications. The dropwizard jwt cookie authentication plugin for dropwizard, makes integrating JWT extremely easy.

Note for mobile apps:
If you want to use dropwizard jwt cookie authentication plugin with mobile apps then some extra effort is required. Because mobile applications don’t support cookies out of the box, when the server sends a response to mobile app, read the Set-Cookie property from the response header and save the JWT token into shared preferences. Similarly, set the JWT token in the request header from shared preferences before sending subsequent requests to server.

2 comments

Post a Comment