Session-Based vs Token-Based Authentication
The two most popular types of authentication for web apps are session-based and token-based authentication.
With the rise of SPA and the decoupling of the front-end and back-end, token-based authentication has risen in popularity due to its statelessness.
I am not going to debate the merits of session vs token-based authentication here. I’m simply going to breakdown the differences between the two.
Session-based authentication requires the server to do the majority of the heavy lifting. After successful authentication, the server stores a session in the database and provides a session_id (stored in a cookie) to the client to send in future requests.
The session_id (cookie) is associated with a session in the database meaning it can enforce authorization and track users movement throughout the website. Basically you can change users access to your app on the fly.
In other words, session-based authentication is stateful. What does stateful mean? It means that the server is constantly tracking and maintaining the client’s state. Are they logged in? For how long? All of that information is tracked and stored on the server.
The main disadvantages for session-based authentication is scalability because of the high memory-use and it couples the front-end with the back-end.
Summary of how session-based authentication works
- User provides authentication credentials (email/password)
- Server verifies credentials and generates a session which is stored in the database
- A cookie with the session_id is placed on the user’s browser
- On subsequent requests, the session_id is sent from the client and verified against the database
- When a user logs out, the session is destroyed on the client and server
For token-based authentication, nothing is persisted and tracked on the server. Each token holds all the user information you need. Because the server does not have to store any information about the user’s session in the database, token-based authentication is stateless.
When I first heard about token-based authentication, I had serious security concerns. After diving deeper, I realized the secret sauce is that each token is unique (contains information such as user_id and token expiration) and signed by a secret key. If a hacker gets access to your secret key, that’s where trouble starts…
Token-based authentication better aligns with Restful principles and enables you to provide authentication for users and your API. Additionally, memory usage is decreased because nothing is stored and verified against our database.
Summary of token-based authentication
- User provides authentication credentials (email/password) – Same as sessions.
- Server verifies the credentials and returns a signed token – Different. In token-based authentication, the token contains user information including user_id and token expiration. This is signed using a secret key.
- The token is stored client-side in local storage, session storage, or a cookie – Same as sessions, although it is more common to store the returned token to local storage to avoid CSRF
- On subsequent requests, the token is included – Same as sessions sending its session_id
- The server decodes the token. If valid, it processes the request – Different. Each token from the client to the server contains the information we need. If the token is properly signed and decoded by our server, then the user is verified.
- Once a user logs out, the token is destroyed client-side. Nothing happens on the server – Different that sessions which has to delete the session on the server too.