does Token Based Authentication requires to store token in DB?

Question

I am using token based approach in authentication, but in many blogs i read that they are storing token in the database.

Do we need to store token in Token Based Authentication in DB?

https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication

In this blog, it is mentioned that we are signing the tokens instead of storing in database, and i think this should be the way to go to acheive true statelessness.

Solution

If you are using a Token base Authentication as described in the linked/mentioned web page there is no necessarity to store the token in a database.

What you have to consider is it possible to transport all required infomation the resource servers need to fullfill deliver the requested resources within the token in a secure way.

To transport for example the userId in a secure way you can additionally encrypt the token. If you want to ensure some data never leaves your datacenter for security reasons than it would be a good idea to hold those data in a database and the token only contains a reference(id) to the user related data stored in a database - that's more or less what's described in Open ID connect.

You should also keep in mind that adding user information to the token means addional payload with each request and may take longer to encypt / decrypt and sign / verify the signature.

If you are going to use the stateless / database less aproach you should clarify:

• the possible size of the token
• the additional cpu load to sign / verify / encrypt / decrypt the token
• header size limitations
• distribution of the keys used to sign / verify / encrpyt / decrypt the token within your datacenter
• extending the lifetime of the token
• revokation of the tokens
• additional security requirements - i.e. is it a problem if an attacker is able to read / (decrypt the encrypted) token?

Comments

[Zelldon]

You mean the Header Authentication? Also something like this Authentication : Basic xSdaqsdfawEFdqweD ? But basic is only base64 no need for saving. You could compute them everytime new.

[andih]

That's not true. The idea is that the during the authorization the (authorization) server creates a signed (and encrypted) Token which the clients sends in each request. Any (resource) server which has the correkt keys can (decrypt) and validate the token without local persistence. Interesting questions here are: how to distribute the how to build a revokation list without knowledge of the existence of a token (because of the lack of the persistence), and how to distribute / exchange / rotate the encyption / signing keys.

[ssindelar]

Like I said. If you have more than one server you need to persist the token to somewhere that all servers can access. If you have a single server and don't care that the token get invalid when you restart the sevrer you can "persist" the token to memory. While the server is running you have a list of all tokens and can do anything with them. If you receive a unknown token (e.g. after a server restart) it is invalid by default.

[ssindelar]

Ok the blog post das was added later describes a different approach. There you don't need to store anything, but encrypt the user, permissions, etc. in the token. It is true, that than you would be "truely" stateless, but it is usually easier to store that information somewhere on your side.