101–110 of 255 posts
I'm not a security expert - one of the strengths is one of the weaknesses - that's it's a simple spec to implement so your average Joe can implement it, but imperfectly.
Incorrect, these are not comparable things. JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state. You can absolutely use JWTs as the payload of your cookie. How you pass the session data back and forth is separate from how you encode the session data. Most web frameworks have their own token formats, but you can easily chang…
The topic is more about session VS JWT, not cookies vs whatever local storage is used in place of cookies.
Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…
How you invalidate either is the same, whether its a database lookup or something else. Article and most of the comments are wholly inaccurate.
Incorrect, these are not comparable things. JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state. You can absolutely use JWTs as the payload of your cookie. How you pass the session data back and forth is separate from how you encode the session data. Most web frameworks have their own token formats, but you can easily chang…
No, it's an engineering argument that makes several testable claims about JWTs, sane session protocols, and how the two are mutually exclusive.
> JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state.
The difference is this:
- Sane sessions
- Random unique identifiers stored in a cookie
- Upon receiving the cookie, the web app looks in the
filesystem/database/etc. for the data associated with
that session
- Can be invalidated by deleting the server-side storage
- JWT-based sessions without server-side persistence
- All session state is encoded into the cookie
- All the trust is outsourced to the client to invalidate
sessions.
A strongly worded argument against a bad engineering argument is not FUD.
Incorrect, these are not comparable things. JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state. You can absolutely use JWTs as the payload of your cookie. How you pass the session data back and forth is separate from how you encode the session data. Most web frameworks have their own token formats, but you can easily chang…
> Cookies are special headers added to HTTP requests to store state. The topic is more about session VS JWT, not cookies vs whatever local storage is used in place of cookies.
Earlier quoted context omitted.
I don’t think of JWT as a replacement for db lookups or storage, but they do provide a convenience in not having to store and manage all sessions in the database[1]. I’ve done it both ways, and as long as you’re careful about a few of the potential security issues with JWT (solve it once, put it in a reusable module), it actually does save a considerable amount of code and complexity on the server side. Also, in my c…
The author is pretty clearly comparing using jwts with using some framework provided session solution, not having you implement sessions from scratch. So just use a session library with expiration implemented, don’t take one without and add it on yourself.
For some of my particular use cases[2], I happen to prefer the JWT approach (despite all the points given in the article, and after auditing the libraries used). For others, I definitely prefer traditional session tokens.
[1] Just because it’s been implemented by someone else, the complexity of that code still falls on you - especially so with something as critical as authentication. It’s not automatically “easy” because someone else implemented it; I’ve seen some pretty terrible security issues in both JWT libraries (e.g., insecure defaults) and framework-provided session management libraries.
[2] Guess what? If you have tens or hundreds of millions of users, managing sessions and expiration can be a bit of a pain. Example: to keep things performant, you'll want to periodically clean up your session store (rather than just invalidating at lookup). Congratulations - now you have a background worker and the complexities of dealing with that at scale. Point is, even with nice framework-provided libraries, managing session tokens on the server can add considerable complexity.
Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…
Yes you can. JWTs are just a standard way to encode state, and can just as easily be sent as a cookie or the Authorization header. How you invalidate either is the same, whether its a database lookup or something else. Article and most of the comments are wholly inaccurate.
Many in the comments are curious about blacklisting JWTs. No, you don't need to put the whole token on a blacklist. Give your tokens reasonably unique JTI claim[1] and put the affected JTIs on the blacklist. The benefit of JWTs is that token blacklists are usually much shorter than hypothetical token whitelists. [1] https://tools.ietf.org/html/rfc7519#section-4.1.7
What if the blacklist becomes unavailable? The author addresses this in part 2.
The advantage is that you can use a loosely consistent datastore with expiring entries and few records at any given time. There’s lots to love about the approach.
Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…
Yes you can. JWTs are just a standard way to encode state, and can just as easily be sent as a cookie or the Authorization header. How you invalidate either is the same, whether its a database lookup or something else. Article and most of the comments are wholly inaccurate.
Otherwise, they could just use a long random string and maybe HMAC it and call it a day.
Incorrect, these are not comparable things. JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state. You can absolutely use JWTs as the payload of your cookie. How you pass the session data back and forth is separate from how you encode the session data. Most web frameworks have their own token formats, but you can easily chang…
> This is just FUD. No, it's an engineering argument that makes several testable claims about JWTs, sane session protocols, and how the two are mutually exclusive. > JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state. The difference is this: - Sane sessions - Random unique identifiers stored in a cookie - Upon receiving th…
JWTs are a encoding format. You can just put a single random unique identifier in there if you want. And you can use cookies to transfer JWTs automatically instead of using the Authorization header. Either can be checked on every request by the server for further validation.
The limitations you wrote are completely arbitrary.