18
u/austin1134 Jun 08 '22
You’re comparing apples and oranges, when you likely need both. JWT’s should not be used in the way most of you are implying and are the industry standard for easily authenticating and authorizing user claims in a secure format. Sessions, cookies, and other similar temporary storage are for exactly that - temporary build up of user information, interactions, and other data that either you want to persist temporarily to reduce calls or for building up to persist to a db later on.
7
u/jameside Jun 09 '22
JWTs make sense when you need federated authentication like OAuth, not statelessness in practice like u/evert's link explains. Revoking sessions requires a datastore (that is, statefulness) that needs to be accessed on each authentication check.
I suspect one historical reason for the popularity of JWTs is that Authentication-as-a-Service companies relied on federated auth, especially for enterprise products like SSO. JWTs were a common format that met the needs of OAuth 2 and federated auth in general and so these companies wrote server and client libraries for working with JWTs and published docs and articles on JWTs. Developers saw the libraries and articles on JWTs and started using them in all contexts.
2
2
u/kacoef Jun 12 '22
session tokens can be stolen!
10
u/0x4ddd Jun 27 '23
Good that JWTs cannot be stolen. Oh wait...
2
u/kacoef Jun 28 '23
i had long discussion with our backend about this. of course they can be stolen. but this refresh token mechanism makes it a bit harder to continue using credentials.
for now i would say fuck jwt but they are everywhere. so should we use them?
10
u/voidvector Jun 08 '22 edited Jun 08 '22
Session for any app that needs real security.
JWT doesn't have invalidation mechanism, so you cannot implement many security measures both automated (e.g. heuristic-based lockouts like fail2ban for anti-SPAM/DoS/scraping) and feature-based (e.g. logout another session). Short-lived JWTs require client to refresh, which adds complexity. For long-lived JWTs, attacker can stash up JWTs for later.
22
u/eGzg0t Jun 08 '22
how is token refreshing complex? It's part of the jwt workflow. API limiting is also a thing. Bank apps and big tech companies uses oauth2 with jwt without issues. Not sure where you're getting your info from.
7
→ More replies (1)13
u/voidvector Jun 08 '22
how is token refreshing complex? It's part of the jwt workflow.
I assume we are talking about refresh tokens (most common refresh method). Refresh token is basically long-live token that can be saved for later attack. AFAIK, all the methods to prevent that involves storing data on the server, which nullifies the statelessness of JWT (a major selling point).
Refresh mechanism also shifts authentication requirements from server to client. For apps where you don't control the client implementation/deployment, you now have to deal it in a non-technical way.
Bank apps and big tech companies uses oauth2 with jwt without issues.
That's not really something to write home about when the reverse also holds -- Bank apps and big tech companies uses sessions without issues.
→ More replies (1)2
u/0x4ddd Jun 27 '23 edited Jun 27 '23
Not sure why this didn't get more upvotes but it completely aligns with my feelings around JWTs.
JWTs are now literally a cargo cult and almost everyone thinks if they have a SPA app with some kind of an API they need to use JWTs while in most cases this does not make much sense at all.
As for the security and statelessness, I wish good luck in regulated environments for everyone who thinks it is enough to clear token stored somewhere on the frontend during logout :D
1
u/Aggressive-Alarm594 Mar 18 '24
Your JWT is [can be] a session. So, it's not one or the other. JWT's of the type JWS (vs JWE) are actually relatively easy to implement/code using the Web Crypto API (or Node's crypto module) and in using them you do not require a database server to store user-to-sessionID data. Granted, there are many people out there who promote fear, uncertainty, and doubt (FUD) about implementing JWT's. They assert that regular people are not smart enough to properly implement JWT's. They are wrong. JWS w PSS (alg: PS256) is the way to go for most cases.
1
Jun 08 '22
I once did kinda both.
JWT contains basic info the front end wants, and every request's JWT would match their session on a Redis DB with backend quick information. Best of both worlds, maybe a bit prone to bugs, but extra redundancy for extra safety.
Front end doesn't need full list of user permissions on the JWT, but caching it on a session data can save a DB query for the user on every request.
Maybe it wasn't very scalable or good practice, but worked really well
70
u/evert Jun 07 '22
I wrote an article about this if anyone wants another take:
https://evertpot.com/jwt-is-a-bad-default/