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.
On
It depends. If you have multiple servers of keep the token between server restarts than you need to persist it somewhere. The database is usually an easy choice. If you have a single server and don't care that your users have to sign in again after a restart, than you can just keep it in the memory.
On
If you are building a web application, you have a couple options:
If you compare these approaches, both receive a JWT down to the browser. Both are stateless because all the information your API needs is in the JWT. Both are simple to pass back up to your protected APIs. The difference is in the medium.
Web Storage (localStorage/sessionStorage) is accessible through JavaScript on the same domain. This means that any JavaScript running on your site will have access to web storage, and because of this can be vulnerable to cross-site scripting (XSS) attacks. XSS in a nutshell is a type of vulnerability where an attacker can inject JavaScript that will run on your page. Basic XSS attacks attempt to inject JavaScript through form inputs, where the attacker puts <script>alert('You are Hacked');</script> into a form to see if it is run by the browser and can be viewed by other users.
As a storage mechanism, Web Storage does not enforce any secure standards during transfer. Whoever reads Web Storage and uses it must do their due diligence to ensure they always send the JWT over HTTPS and never HTTP.
Cookies, when used with the HttpOnly cookie flag, are not accessible through JavaScript, and are immune to XSS. You can also set the Secure cookie flag to guarantee the cookie is only sent over HTTPS. This is one of the main reasons that cookies have been leveraged in the past to store tokens or session data. Modern developers are hesitant to use cookies because they traditionally required state to be stored on the server, thus breaking RESTful best practices. Cookies as a storage mechanism do not require state to be stored on the server if you are storing a JWT in the cookie. This is because the JWT encapsulates everything the server needs to serve the request.
However, cookies are vulnerable to a different type of attack: cross-site request forgery (CSRF). A CSRF attack is a type of attack that occurs when a malicious web site, email, or blog causes a user’s web browser to perform an unwanted action on a trusted site on which the user is currently authenticated.
You can make this CSRF protection stateless by including a xsrfToken JWT claim.
Leveraging your web app framework’s CSRF protection makes cookies rock solid for storing a JWT. CSRF can also be partially prevented by checking the HTTP Referer and Origin header from your API. CSRF attacks will have Referer and Origin headers that are unrelated to your application.
Read this great blog post from Stormpath for more details.
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: