Session Based vs Token Based Authourization

Sat 13 August 2016

For user authentication on SegAnnDB we depended on Mozilla Persona till now, but unfortunately persona systems will be shutdown by this November.

So we decided to move our existing authourziation mechanism to OAuth2 based authentication. In this post I will be doing comparison of Session vs token based authourziation and how we are implementing it in SegAnnDB.

Session Based Authentication

In session based authentication the server does all the heavy lifting server side. Client authenticates with its credentials and recieves a session_id (which can be stored in a cookie) and attaches this to every subsequent outgoing request.

So this could be considered a “token” as it is the equivalent of a set of credentials. There is however nothing fancy about this session_id string. It is just an identifier and the server does everything else. It is stateful. It associates the identifier with a user account (e.g. in memory or in a database).

It can restrict or limit this session to certain operations or a certain time period and can invalidate it if there are security convern and more importantly it can do and change all of this on the fly. Furthermore it can log the users every move on the website(s).

Possible disadvantages are bad scalability and extensive memory usage.

Token Based Authentication

In Token based Authentication no session is persisted server-side (stateless). The initial steps are the same. Credentials are exchanged against a token which is then attached to every subsequent request which is commonly stored in the local storage of the client (It can also be stored in a cookie).

However for the purpose of decreasing memory usage, easy scale-ability and total flexibility (tokens can be exchanged with another client) a string with all the necessary information is issued (the token) which is checked after each request made by the client to the server. There are a number of ways to use/ create tokens.

In a nutshell-

Most popular authentication system for APIs
Less load on server compared to session authentication.
Scaling and load balancer can be applied effectively on the API.
No cookie and CSRF(Cross Site Request Forgery) protection required.
Allows the same API to be used in mobile and web.

JWT - JSON Web Token

Pronounced as “jot”
The token is a combination of three parts- Header, payload and signature.
Each part of authentication is encoded with base64 url encoding and separated with a dot (.)
Server generates the token and gives to client
With every request the server verifies the token using, time, signature, etc
JWTs can be signed using ‘secret’ (OAuth2 Secret) in the server
Usually Asymmetric Key Algorithms are used.

OAuth2

OAuth2 is the most modern way of providing authentication support. Generally, OAuth2 allows users of one website to access and authenticate in any other web application or mobile application.

The login providers e.g. - Google, Facebook, Github provide APIs to access user data, on basis of the user consent.

OAuth2 for SegAnnDB and Pyramid

In our case, we currently are using Pyramid authentication along with persona module for pyramid which is most probably a session based authentication system. The project is Pyramid Persona

Its potential replacement is - Pyramid Google Login

This dependency will be replacement for the pyramid_persona module, the current code hosted at the github repo contains a few bugs which I am fixing;

We will have to fix the pyramid module, upload it to pypi and then dockerize the whole thing.

I got pyramid_google_login module to work with SegAnnDB, although for sustained authentication and remembering the state of application I am using session.

The authentication is pretty basic which can be summed up in the following steps -

User logs in via Google OAuth
The user information is retrieved from Google’s API
Using pyramid, we set a cookie on with the name of user_id
Everytime a request comes in we decode the cookie, and get the user_id
For logout, a simple javascript function clears out the cookie by invalidating it based on expire time.
For retrieving the user_id from the cookie in the server-side I wrote down a simple function which takes the request and retrieves the user_id from the cookie.

Unlike typical session based authentication scenarios we are not maintaining the stateful-ness of application at the server side, because there is no data other than the user_id which we want to store. The user_id is stored as a cookie itself.

So, that’s it about the new login system of SegAnnDB.

The code changes on SegAnnDB can be found at - https://github.com/abstatic/SegAnnDB

The code will be up by my next blog post, because I still need to figure out how can I upload the modified pyramid_google_login to pypi.

Coding Mantis