DEV Community

Cover image for πŸ” Session-Based vs. Token-Based Authentication: Which is better?πŸ€”

πŸ” Session-Based vs. Token-Based Authentication: Which is better?πŸ€”

Fidal Mathew on December 23, 2023

Hi fellow readers!βœ‹ I hope you’re doing great. In this article, we will learn about session and token-based authentication methods used in backend ...
Collapse
 
notachraf profile image
notachraf

Honestly in the era of OAuth2, SSO, password-less.... JWT's are the way to go, but session id still have a lot of uses.

Also, in the beginning of projects, I try to abstract those concerns as they are never a core business decision in the beginning, so I just use a framework ( like NextAuth ) and only deal with authorization ( not authentication )

Collapse
 
fidalmathew profile image
Fidal Mathew

That's a great point. Authorization frameworks do make the job easy for us. Thanks for sharing your insights!

Collapse
 
tbroyer profile image
Thomas Broyer

How does one log out? That's a major difference between them. Put differently, how does one revoke a token? If you have to check the token against a database of revoked tokens, how's that different from a session?

BTW, we're talking about self-sufficient tokens here, but other kinds of token exist that are just the same as session IDs, just sent differently (cookie vs "something else")

Collapse
 
fidalmathew profile image
Fidal Mathew

We can log out in token-based authentication by deleting the token stored in the browser (local/session/cookie storage). It is done in the frontend whereas if a session needs to be destroyed the command is executed in the server code.

Collapse
 
tbroyer profile image
Thomas Broyer

Forgetting something or just stopping using it yourself has zero security value. So technically you cannot logout with a self-sufficient token, you cannot revoke it, unless you start making it stateful.

TL;DR: don't use such tokens, at least not that way.

(fwiw, I've written about this recently; unfortunately I'm on mobile right now so can't easily find the links; you'll find them in my DEV profile)

Thread Thread
 
fidalmathew profile image
Fidal Mathew

The article is amazing!
I'll put it out here for others to check it out as well. @tbroyer has pointed out some great points about the compromises we make while developing authorization.
Check it out: dev.to/tbroyer/beyond-the-login-pa...

Thread Thread
 
tbroyer profile image
Thomas Broyer

Thanks for the kind words πŸ€—

The other article I wanted to point out was dev.to/tbroyer/what-are-jwt-nm0 about what JWT are best used for (spoiler: not any kind of "session"). And please don't take my word for it, go read the articles referenced at the end!

Collapse
 
sadiqsalau profile image
Sadiq Salau

Use cookies If you want to store authentication data on the client side.. You still need to append the token to every request you make, that's not different from a cookie..

Collapse
 
atomiccode profile image
Atomic Code

You probably do not want to check the JWT against the database because it's not even designed for that. JWT eliminates the need to have any kind of state, be it in the database or on the server as a session. The JWT has an expiration date, and you should set an expiration 100% of the time.

But the problem then comes, how do you revoke access? The answer is - you don't, so keep the expiration time near.

The next question is, how do I stop the user from automatically getting logged out once expired? The answer is - by using a refresh token that is stored in the database close to the expiration of the JWT. That way, you only need to check the database every 15 minutes or so.

If you want fast middleware that doesn't eat up RAM on your server and is not dependent on a specific server, use JWT.

If you want a way to log someone out by the split second, use sessions. But each user shouldn't use different servers at the same time, and you need to make sure the sessions are removed from memory after use in some lower languages.****

Collapse
 
hoosayn profile image
hoosayn

Recently I developed a project based on token authentication. To keep the state I store the token in db and match for every subsequent request after authentication of the first request. Is this good approach or what could be the draw backs?

Collapse
 
tbroyer profile image
Thomas Broyer

If you didn't mean your token to be self-contained, then it's totally ok and definitely the way to go! (and more or less what an http session in any web framework gives you, the only difference being how the token or session I'd is sent over the wire).

The "problem" is choosing a self-sufficient token format so it's "stateless", and then realizing you can't revoke said tokens, so shoehorning some state, defeating the whole reason you chose self-sufficient tokens in the first place.
I'm not saying it cannot be done efficiently, keeping some perf advantage over "stateful tokens", but it also becomes more complex.

However if you used tokens to authenticate a first-party web frontend to its backend, my opinion is you should just use cookie-based sessions instead. CSRF are a solved problems nowadays so there's no drawback to using cookies, and on the server you have plenty of libraries/frameworks to implement it with pluggable storage mechanisms (make sure you only ever store the user identity in the session though, and otherwise be stateless)

Collapse
 
sadiqsalau profile image
Sadiq Salau

If the server can't revoke a token at anytime it wants then it's bad. A minute is enough for an attacker if they acquire your JWT token...

Collapse
 
fidalmathew profile image
Fidal Mathew

One of the disadvantages of token-based authentication.

Collapse
 
jacksonkasi profile image
Jackson Kasi

The backend language for my project is TypeScript.

Collapse
 
abidullah786 profile image
ABIDULLAH786

Very useful...

Collapse
 
fidalmathew profile image
Fidal Mathew

Thank you!!

Collapse
 
rdarrylr profile image
Darryl Ruggles

Very well explained! Thanks for your time on this!

Collapse
 
fidalmathew profile image
Fidal Mathew

Glad that you liked it! 😊

Collapse
 
ianmacartney profile image
Ian Macartney

Redis put out this free e-book about why JWTs are not safe for sessions. Worth a read, esp if you care about the logout problem: redis.io/resources/json-web-tokens...

Collapse
 
noorcs profile image
Noor Ahmed

I really love the simplicity of your explanation. It really helps.

Collapse
 
fidalmathew profile image
Fidal Mathew

Thank you! Means a lot! 😁

Collapse
 
prod42net profile image
prod42

Exceptionally good explanation. On the point.

Collapse
 
fidalmathew profile image
Fidal Mathew

Thank you!! Glad that you liked it! 😁

Collapse
 
hoosayn profile image
hoosayn

Recently I developed a project based on token authentication. To keep the state I store the token in db and match for every subsequent request after authentication of the first request. Is this good approach or what could be the draw backs?

Collapse
 
joes_bffac7a634ab profile image
Joes

not bad βœ…

Collapse
 
joes_bffac7a634ab profile image
Joes

not badβœ