Token Based Authentication

First, what’s authentication about?

You surely must be having an email account, like everyone else around you. But your mailbox is different someone else’s obviously because you get different mails. And each time you try to access your mail provider, you must obviously be able access your mails and not those belonging to someone else. And that is the purpose of authentication: To ascertain if you are you - based on a set of credentials - and lay down the platform to lead you to your mailbox. The scenario is same in the case of every website that operates on an account basis. Authentication, however, is different from authorization. The latter is more about leading you to your mailbox after confirming that you are you. In other words, you have an identity

Why can’t authentication be a simple one time affair?

Well, it’s an important question and to answer that, it’s important to understand what ‘state’ is. Well, the Hypertext Transfer Protocol (HTTP) - the data communication protocol of the Web - is stateless which means to say that any transaction or communication carried out through the HTTP is independent of any other communication. All HTTP requests are isolated from all the others. So, if you are logged into your mailbox, i.e. after being authenticated by the mail server, to open a particular mail you received, you must provide the mail server with your username and password again. And again to reply to that mail. That’s being stateless. A layman would think that his or her mailbox is available for all actions once the correct set of username and password is entered. But that’s not how it works because HTTP is stateless. People only login once before logging out because of the type of authentication system used.

What’s token based authentication system then?

Imagine being in an old school bank that’s just starting to digitize. They would use a token based system and issue tokens to customers, each with a unique number. That a person is a customer is determined when the customer presents his or her bank account pass book. An LED board would display corresponding token numbers and whose ever number comes up can walk to the related counter and transact required business. So, the customer is authenticated before being issued the token and the token can be used to access various services the bank provides. So much so for digitization but this is actually an advanced form of authentication in web services.

In essence, token based authentication involves the issue of an access token at the time of authentication. This token can be in different forms compatible to the ecosystem being used in. Post authentication, a token is created and given to the client. The client keeps this token and sends it across with every request to the server. While processing every individual request from the client, the server doesn’t know that the client is already authenticated - because HTTP is stateless - and so checks the token sent along and ascertains that the client is already authenticated and so provides access to the resources being requested. That’s the idea of token based authentication.

Was it always done this way?

Not really. Token based authentication is a recent innovation. Prior to it, the system in use was cookie based authentication. Actually, it still is the most widely used process. The oldest process was to store session files on the server itself. So, if you present your credentials to the mail server to login to your mailbox, the mail server checks your credentials, logs you in and then creates a session for you on the server itself. In other words, a simple file is created stating that you are you and you are already logged in. So, when you attempt to open a mail, you request the server for access to the mail and the mail server in turn checks the file pertaining to you and then gives you access. Cookie based authentication creates sessions for each user (after the login) and stores in the cookies. But cookies, by their nature, are vulnerable to external attacks and can result in session hijacking.

Isn’t server based authentication simpler than token based authentication?

On the contrary, server based authentication leads to multiple problems. First of all, if there are a thousand people trying to log into a website during a particular timeframe, the server has to create a thousand files for each of these people. So, one, you have got to have a lot of memory space on your servers and, two, accessing the session file for each request created a hell lot of overhead. So, eventually the costs just zoom through the ceiling. And then, there are further problems when you are scaling because in scenarios like cloud, even if you improve your computation capabilities to handle more applications, your memory constraints limit your efforts.

So, what are the advantages of a token based authentication system?

Well, it’s just the opposite of session based authentication systems. Basically, when you use token based authentication systems, there is no concept of a session. Sessions are used in a cookie based environment. With regards to tokens, there is no session as such. So, the advantages would obviously be that it is easy to scale with a token based authentication system, it is faster, it is secure because the token are encrypted and digitally signed. And more so, token based authentication systems work well in a web API environment where most applications are available via their APIs. And so tokens can be used to obtain access to multiple services and applications across domains at once (provided there is some form trust agreement) without worrying about the single domain policy.