9 ms·

Why JWTs Suck as Session Tokens (2017)

91 points by powvans 4y ago

parker_mountain 4y ago
Some concepts to think about: local introspection: validating the validity and lifespan of a jwt by checking it cryptographically. does not need to make a network call, thus very fast and a great way to perform a low stakes operation. remote introspection: validating the integrity and lifespan of a jwt by checking with the server that signed it and/or the server that issued the session. this should happen at least once per call flow, ideally as few times as possible but also every time sensitive information is accessed if you have a heavy call graph, you can do local introspection on everything in the middle. and then, when you go to retrieve pii, do remote introspection. if your token is appropriately short-lived (15 minutes), this means that an attacker can only yield information within that window with token scraping. that means that an attacker can only access data for as long as they have a foothold. i hope you have strong reporting and immutable architecture :) > If you’re building a simple website like the ones described above, then your best bet is to stick with boring, simple, and secure server side sessions. Instead of storing a user ID inside of a JWT, then storing a JWT inside of a cookie: just store the user ID directly inside of the cookie and be done with it. so basically, if your application is doing its own authn/authz (most monolithic applications), you don't need jwts.
- hknmtt 4y ago
  no, you need to store the jwt in a cookie(or local store) because the jwt is signed. if you would have only cookie with user id then anyone would be able to pretend to be anyone by manually setting the cookie with some user's uid.
  - Huh1337 4y ago
    The alternative isn't storing user ID and sending it around but generating a unique session token that's stored for example in your DB. See how PHP does it (session_start etc).
  - eurasiantiger 4y ago
    Do not persist or store access tokens anywhere but in-memory. You can use a session cookie as a refresh token, and use it to get a fresh JWT whenever you need.
    - parker_mountain 4y ago
      > Do not persist or store access tokens anywhere but in-memory. Using short lived ATs is one defense against this happening, such as if an attacker compromises one of your services and starts scraping tokens off of it. Ideally, the services should also have some sort of checks (such as service accounts), to ensure that only approved services can talk to each other.
    - hknmtt 4y ago
      using two tokens makes sense only if you have cqrs system. otherwise it's a complexity that brings no value.
  - parker_mountain 4y ago
    > if you would have only cookie with user id then anyone would be able to pretend to be anyone by manually setting the cookie with some user's uid. That's what session id (as mentioned in the article) is for.
taywrobel 4y ago
This skips over one other big way that I’ve always seen JWT implementations fall over - sign out/session invalidation. A JWT has all the information for verifying its own lifetime contained within it, which is cool in that you don’t need to hit the DB to verify it… until you want to invalidate it before the embedded expiration is hit. Then you need to hit the database or some cache layer to verify that it isn’t invalidated, and now one of the biggest reasons to use it is gone. They do mention that for CRUD operations you’ll need to hit the DB anyways, which is in the same vein as this issue tho.
- mrhands556 4y ago
  Why not just have a lower TTL on your JWT?
  - cercatrova 4y ago
    Then what's the point? Just use sessions at that point.
- fastball 4y ago
  Not really true if you use an access/refresh token system. The access token doesn't hit the DB for auth, the refresh token does. You have an access token with a lifetime of say somewhere between 1-10 minutes. If you want to invalidate a session, you just revoke the refresh token and any access tokens will be invalid soon after. In a system where a user is making 10+ requests in a minute, that can be well worth it to reduce stress on the DB without an appreciable loss in security.
  - trinovantes 4y ago
    Cookie sessions are usually stored in fast caches like redis so the performance hit is negligible. Most people will never reach the performance ceiling of a beefy single redis instance so why bother complicating the system?
    - LanceH 4y ago
petrocrat 4y ago
PASETO tokens are superior to JWT in just about every important way, it's weird how they are so obscure and have not caught on. [1] https://paseto.io/ https://paseto.io/
- sgammon 4y ago
  > Our specialty is cryptographically secure PHP development. Hm
  - zmxz 4y ago
    If your snarky comment is aimed at PHP, I'm afraid I have bad news for you. > PHP becomes the first programming language with modern cryptography in its standard library thanks to the bundled libsodium https://www.jetbrains.com/lp/php-25/#e_2017_11_30_2 https://www.jetbrains.com/lp/php-25/#e_2017_11_30_2 If the snarky comment is aimed at the developer posting the claim, yet again, wrong target. Don't be like that please.
    - vore 4y ago
      Bundling libsodium in the standard library doesn't really seem to be a mark for or against PHP.
    - Huh1337 4y ago
      What about all the languages that can simply use libsodium directly? I don't think having it in the std lib is really such a distinguished feat.
      - zmxz 4y ago
        > What about all the languages that can simply use libsodium directly Nothing. It's great they do that. I made a comment that refuted a snarky remark that had no basis, I did not compare languages nor post claims about language's awesomeness or anything else, just that it uses libsodium and that silly remarks centered around trashing PHP are based on lack of knowledge.
jongjong 4y ago
JWTs are great for fast, efficient, distributed authentication. You shouldn't store too much stuff in the JWT, just the username and access level is generally enough. The trick is to set it to have a short expiry and keep renewing while the user is online/active.
seandoe 4y ago
Jwts are great for micro/multiple services -- no need to hit the auth db on every request. Determine ttl by considering the context and then balancing performance/security concerns. If you need to invalidate a session before the ttl expires, throw the identifier in a memory cache. But I think this is overkill for most applications. Rather, protect important state changes by asking user to enter password or to provide other form of auth. If the frontend wants access to the jwt data, a pattern I like is splitting the jwt by keeping the header and payload in js readable cookie or local storage, then keep the signature in an http only cookie.
senko 4y ago
Related recent discussions (different articles on a similar topic): https://news.ycombinator.com/item?id=33019960 https://news.ycombinator.com/item?id=33019960 https://news.ycombinator.com/item?id=33018135 https://news.ycombinator.com/item?id=33018135
maxpert 4y ago
Yes for basic websites simple DB based session might be enough. And if you think about these sessions they are essentially opaque and stateful tokens pointing to a row in DB containing the information you need. But saying JWT sucks in plain generic terms is out of context statement, in large micro-service environment if every front-end service starts hitting an identity service the fan out is gonna kill you! You keep a basic set of information in token that is most often used, not every service will need user phone number, and all of his roles. 95% of your read traffic will need some basic ID, email, and basic roles that can be satisfied from JWT token. What OKTA is suggesting essentially is gonna push all the load onto a DB or some sort of datastore, so that it becomes SPOF, and now you have shifted problem to scaling that DB/Datastore. Answer IMO is it depends.
- vore 4y ago
  The article calls this out: > If you’re building any type of service where you need three or more parties involved in a request, JWTs can also be useful. In this case the requesting party will have a token to prove their identity, and can forward it to the third (or 4th … nth) service without needing to incur a real-time validation each and every time. But it doesn't seem like a good idea to expose the JWTs to the user directly: what if a user updates their phone number? This won't be reflected in already generated JWTs. It seems like a better idea to, at the frontend, generate any JWTs you need to pass to backends and use those to avoid fan-in to whatever identity service, rather than handing those JWTs directly to the client.
  - eurasiantiger 4y ago
    To be honest, if your JWT access token expiry is over ten minutes from creation and you have no way of invalidating tokens, you are doing it wrong.
29athrowaway 4y ago
Also from the same author (actual titles): - Multi-Factor Authentication Sucks - Nobody Cares About OAuth or OpenID Connect - What Happens If Your JWT Is Stolen? - Why JWTs Suck as Session Tokens I would rather write an article titled: Why all those blog posts suck
- ikiris 4y ago
  This is a great summary of why this guy's blog is a waste of time honestly. Thanks for doing the work!
- zmxz 4y ago
  The titles are misleading (purposely, because it attracts interest), however - you should read what's written before judging. From what you've written, I'd safely bet your attention span is really low and that you haven't read a single one of those before writing the comment here.
  - InGoodFaith 4y ago
    > The titles are misleading (purposely, because it attracts interest) I am neutral to this conversation but thought you might not want to justify this point as it is against the spirit of HN. Specifically in the guidelines: > Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize. Which would give the submitter permission to change the title to something more substantive.
    - zmxz 4y ago
      When you read the posts and when you don't rely on titles, you can see the point that the author argues. 2FA does suck, it's not a pleasant experience but it is necessary. If something sucks, it does not mean that you don't have to or should not have to use it. There are things that hinder user experience but are immense for security, like 2FA is. Making judgment based on title is silly, and if the spirit of HN is to judge without facts - then I apologize. Carry on as you were. The strawman argument against the author, based on the title that provokes thought, is not a sign of intellectual discussion.
sgammon 4y ago
JWTs survive in popularity because, by and large, their size is negligible over the wire, internet speeds get faster (not slower), and key agreement across systems is still a surprisingly complex problem. (1) Size Factoring Gzip and HTTP/2 header compression into this, size is no longer an issue, but it's still a reasonably good idea to keep claim sizes down. If you don't like using cookies, use a sessionStorage value and affix via XHR! Easy (2) You're Going to Hit The Database Anyway No you aren't, necessarily? Wth. Also, JWKS paired with JWT gives fantastic rotation security with very minimal configuration across systems. So, maybe you don't even have the database accessible to you. You can still verify your signatures. (3) Redundant Signing Sounds like this is advice for some framework that signs the session cookie? This is silly. "You should use Session IDs instead" Tell me you haven't built a globally distributed system without telling me you haven't built a globally distributed system.
- orange_fritter 4y ago
  I haven't built a globally distributed system, and most people here never will. I'm not against JWTs, despite the constant influx of hackernews articles, but "globally distributed system" is not a valid argument against using session IDs when most of us are working with a single fast db.
  - sgammon 4y ago
    many apps these days are globally distributed virtually by their nature.
sgammon 4y ago
This was definitely written pre Auth0 acquisition, just saying
Terrencees 4y ago
[flagged]
sascha_sl 4y ago
>In this case the requesting party will have a token to prove their identity, and can forward it to the third (or 4th … nth) service without needing to incur a real-time validation each and every time. Someone missed the entire point of audience claims in OIDC - on okta.com no less.
kache_ 4y ago
JWT as a term used to describe signed material should considered harmful (source: me) It's basically just signed authentication material Use it when you need to keep your authentication layer horizontally scalable & stateless Use it when you're transferring trust to an untrusted system, acting on behalf of a user (SAML, OAuth, OIDC) that's it It's just signed material data size limitation (from the blog) is a big meme (source: me). Just pack it into a protobuf lmao eventual consistency of a stateful session will hurt you btw yes yes yes I know. The grey bears gave us protocols, rfcs, etc. MUH PROTOCOLS. just give me a private key and a bud light dude the protocols are important for oidc/oath/saml JWT ISN"T A PROTOCOL i'm tired, I should go sleep
can16358p 4y ago
While I don't necessarily disagree, I think using the globally accepted way of somehow utilizing JWTs outweigh the marginal and exaggerated (24MB for 100K requests is literally nothing in 2022) benefits. If I use JWT I get widely battle tested library support and near-universal acceptance among developers, which is more than enough for most of the folks to go with JWT IMHO.
Myrmornis 4y ago
What an awful article. Why is it talking down to their readers like that?
MikeYasnev007 4y ago
shp0ngle 4y ago
At this point, JWTs are a cargo cult. People do them because everyone else does them, even when it makes 0 reasons in the app itself and they use them as worse session tokens. Nobody was ever fired for using JWT for authentication.
somethingAlex 4y ago
>> “ A mission critical user check needs to run (eg: does this user have enough money in their account to complete the transaction?)” That info wouldn’t be in the session db row either. >> “ A database write needs to occur to persist information (if this information is related to the user, it’s likely that the full user object must also be retrieved from the database” This type of info doesn’t get updated frequently. Email, phone, name, etc, are pretty static. If they are just talking about a join using a userId, well that’s not gonna be any different whether you know the ID from a JWT or normal cookie. >> “ The full user object must be pulled out of the cache / database so that the website can properly generate its dynamic page content” But that’s an upside of keeping more than a cookie with an ID. You can just stash the stuff that doesn’t change much client side (keeping in mind the XSS risks). We certainly don’t pull the user’s email and name every page load even though it’s displayed on every page. >> “ Almost every web framework loads the user on every incoming request. This includes frameworks like Django, Rails, Express.js” That’s a framework issue and should be customizable. Not really a JWT vs cookie w/ ID topic There’s plenty of reasons to choose an ID cookie vs a JWT but the many that the author gives are not among them.
woile 4y ago
Has anyone tried https://www.biscuitsec.org/ https://www.biscuitsec.org/ ? I haven't seen it much discussed, and seems to solve a lot of issues from JWT
camgunz 4y ago
I found Security Cryptography Whatever's treatment of the various session token options super informative [0]. I had some vague unformed skeptical opinions about JWTs, and now I have some reasonably informed rational opinions about them, so can recommend. [0]: https://securitycryptographywhatever.buzzsprout.com/1822302/9020991-what-do-we-do-about-jwt-feat-jonathan-rudenberg https://securitycryptographywhatever.buzzsprout.com/1822302/...
ChicagoDave 4y ago
I’ve been building software for 35 years and web apps since “the beginning.” You couldn’t drag me back to server side state management for anything. OAuth2 and JWT tokens is one of best inventions and has proven itself quite thoroughly. This article was goofy in 2017 and it’s even goofier now.
senko 4y ago
Randall has also given a number of talks on the topic, so if you prefer watching to reading, have a look at https://www.youtube.com/watch?v=JdGOb7AxUo0 https://www.youtube.com/watch?v=JdGOb7AxUo0
deleted 4y ago
[deleted]

91 points by powvans 4y ago

Some concepts to think about: local introspection: validating the validity and lifespan of a jwt by checking it cryptographically. does not need to make a network call, thus very fast and a great way to perform a low stakes operation. remote introspection: validating the integrity and lifespan of a jwt by checking with the server that signed it and/or the server that issued the session. this should happen at least once per call flow, ideally as few times as possible but also every time sensitive information is accessed if you have a heavy call graph, you can do local introspection on everything in the middle. and then, when you go to retrieve pii, do remote introspection. if your token is appropriately short-lived (15 minutes), this means that an attacker can only yield information within that window with token scraping. that means that an attacker can only access data for as long as they have a foothold. i hope you have strong reporting and immutable architecture :) > If you’re building a simple website like the ones described above, then your best bet is to stick with boring, simple, and secure server side sessions. Instead of storing a user ID inside of a JWT, then storing a JWT inside of a cookie: just store the user ID directly inside of the cookie and be done with it. so basically, if your application is doing its own authn/authz (most monolithic applications), you don't need jwts.

hknmtt 4y ago
no, you need to store the jwt in a cookie(or local store) because the jwt is signed. if you would have only cookie with user id then anyone would be able to pretend to be anyone by manually setting the cookie with some user's uid.
- Huh1337 4y ago
  The alternative isn't storing user ID and sending it around but generating a unique session token that's stored for example in your DB. See how PHP does it (session_start etc).
- eurasiantiger 4y ago
  Do not persist or store access tokens anywhere but in-memory. You can use a session cookie as a refresh token, and use it to get a fresh JWT whenever you need.
  - parker_mountain 4y ago
    > Do not persist or store access tokens anywhere but in-memory. Using short lived ATs is one defense against this happening, such as if an attacker compromises one of your services and starts scraping tokens off of it. Ideally, the services should also have some sort of checks (such as service accounts), to ensure that only approved services can talk to each other.
  - hknmtt 4y ago
    using two tokens makes sense only if you have cqrs system. otherwise it's a complexity that brings no value.
- parker_mountain 4y ago
  > if you would have only cookie with user id then anyone would be able to pretend to be anyone by manually setting the cookie with some user's uid. That's what session id (as mentioned in the article) is for.

taywrobel 4y ago

This skips over one other big way that I’ve always seen JWT implementations fall over - sign out/session invalidation. A JWT has all the information for verifying its own lifetime contained within it, which is cool in that you don’t need to hit the DB to verify it… until you want to invalidate it before the embedded expiration is hit. Then you need to hit the database or some cache layer to verify that it isn’t invalidated, and now one of the biggest reasons to use it is gone. They do mention that for CRUD operations you’ll need to hit the DB anyways, which is in the same vein as this issue tho.

mrhands556 4y ago
Why not just have a lower TTL on your JWT?
- cercatrova 4y ago
  Then what's the point? Just use sessions at that point.
fastball 4y ago
Not really true if you use an access/refresh token system. The access token doesn't hit the DB for auth, the refresh token does. You have an access token with a lifetime of say somewhere between 1-10 minutes. If you want to invalidate a session, you just revoke the refresh token and any access tokens will be invalid soon after. In a system where a user is making 10+ requests in a minute, that can be well worth it to reduce stress on the DB without an appreciable loss in security.
- trinovantes 4y ago
  Cookie sessions are usually stored in fast caches like redis so the performance hit is negligible. Most people will never reach the performance ceiling of a beefy single redis instance so why bother complicating the system?
  - LanceH 4y ago

petrocrat 4y ago

PASETO tokens are superior to JWT in just about every important way, it's weird how they are so obscure and have not caught on. [1] https://paseto.io/ https://paseto.io/

sgammon 4y ago
> Our specialty is cryptographically secure PHP development. Hm
- zmxz 4y ago
  If your snarky comment is aimed at PHP, I'm afraid I have bad news for you. > PHP becomes the first programming language with modern cryptography in its standard library thanks to the bundled libsodium https://www.jetbrains.com/lp/php-25/#e_2017_11_30_2 https://www.jetbrains.com/lp/php-25/#e_2017_11_30_2 If the snarky comment is aimed at the developer posting the claim, yet again, wrong target. Don't be like that please.
  - vore 4y ago
    Bundling libsodium in the standard library doesn't really seem to be a mark for or against PHP.
  - Huh1337 4y ago
    What about all the languages that can simply use libsodium directly? I don't think having it in the std lib is really such a distinguished feat.
    - zmxz 4y ago
      > What about all the languages that can simply use libsodium directly Nothing. It's great they do that. I made a comment that refuted a snarky remark that had no basis, I did not compare languages nor post claims about language's awesomeness or anything else, just that it uses libsodium and that silly remarks centered around trashing PHP are based on lack of knowledge.

jongjong 4y ago

JWTs are great for fast, efficient, distributed authentication. You shouldn't store too much stuff in the JWT, just the username and access level is generally enough. The trick is to set it to have a short expiry and keep renewing while the user is online/active.

seandoe 4y ago

Jwts are great for micro/multiple services -- no need to hit the auth db on every request. Determine ttl by considering the context and then balancing performance/security concerns. If you need to invalidate a session before the ttl expires, throw the identifier in a memory cache. But I think this is overkill for most applications. Rather, protect important state changes by asking user to enter password or to provide other form of auth. If the frontend wants access to the jwt data, a pattern I like is splitting the jwt by keeping the header and payload in js readable cookie or local storage, then keep the signature in an http only cookie.

senko 4y ago

Related recent discussions (different articles on a similar topic): https://news.ycombinator.com/item?id=33019960 https://news.ycombinator.com/item?id=33019960 https://news.ycombinator.com/item?id=33018135 https://news.ycombinator.com/item?id=33018135

maxpert 4y ago

Yes for basic websites simple DB based session might be enough. And if you think about these sessions they are essentially opaque and stateful tokens pointing to a row in DB containing the information you need. But saying JWT sucks in plain generic terms is out of context statement, in large micro-service environment if every front-end service starts hitting an identity service the fan out is gonna kill you! You keep a basic set of information in token that is most often used, not every service will need user phone number, and all of his roles. 95% of your read traffic will need some basic ID, email, and basic roles that can be satisfied from JWT token. What OKTA is suggesting essentially is gonna push all the load onto a DB or some sort of datastore, so that it becomes SPOF, and now you have shifted problem to scaling that DB/Datastore. Answer IMO is it depends.

vore 4y ago
The article calls this out: > If you’re building any type of service where you need three or more parties involved in a request, JWTs can also be useful. In this case the requesting party will have a token to prove their identity, and can forward it to the third (or 4th … nth) service without needing to incur a real-time validation each and every time. But it doesn't seem like a good idea to expose the JWTs to the user directly: what if a user updates their phone number? This won't be reflected in already generated JWTs. It seems like a better idea to, at the frontend, generate any JWTs you need to pass to backends and use those to avoid fan-in to whatever identity service, rather than handing those JWTs directly to the client.
- eurasiantiger 4y ago
  To be honest, if your JWT access token expiry is over ten minutes from creation and you have no way of invalidating tokens, you are doing it wrong.

29athrowaway 4y ago

Also from the same author (actual titles): - Multi-Factor Authentication Sucks - Nobody Cares About OAuth or OpenID Connect - What Happens If Your JWT Is Stolen? - Why JWTs Suck as Session Tokens I would rather write an article titled: Why all those blog posts suck

ikiris 4y ago
This is a great summary of why this guy's blog is a waste of time honestly. Thanks for doing the work!
zmxz 4y ago
The titles are misleading (purposely, because it attracts interest), however - you should read what's written before judging. From what you've written, I'd safely bet your attention span is really low and that you haven't read a single one of those before writing the comment here.
- InGoodFaith 4y ago
  > The titles are misleading (purposely, because it attracts interest) I am neutral to this conversation but thought you might not want to justify this point as it is against the spirit of HN. Specifically in the guidelines: > Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize. Which would give the submitter permission to change the title to something more substantive.
  - zmxz 4y ago
    When you read the posts and when you don't rely on titles, you can see the point that the author argues. 2FA does suck, it's not a pleasant experience but it is necessary. If something sucks, it does not mean that you don't have to or should not have to use it. There are things that hinder user experience but are immense for security, like 2FA is. Making judgment based on title is silly, and if the spirit of HN is to judge without facts - then I apologize. Carry on as you were. The strawman argument against the author, based on the title that provokes thought, is not a sign of intellectual discussion.

sgammon 4y ago

JWTs survive in popularity because, by and large, their size is negligible over the wire, internet speeds get faster (not slower), and key agreement across systems is still a surprisingly complex problem. (1) Size Factoring Gzip and HTTP/2 header compression into this, size is no longer an issue, but it's still a reasonably good idea to keep claim sizes down. If you don't like using cookies, use a sessionStorage value and affix via XHR! Easy (2) You're Going to Hit The Database Anyway No you aren't, necessarily? Wth. Also, JWKS paired with JWT gives fantastic rotation security with very minimal configuration across systems. So, maybe you don't even have the database accessible to you. You can still verify your signatures. (3) Redundant Signing Sounds like this is advice for some framework that signs the session cookie? This is silly. "You should use Session IDs instead" Tell me you haven't built a globally distributed system without telling me you haven't built a globally distributed system.

orange_fritter 4y ago
I haven't built a globally distributed system, and most people here never will. I'm not against JWTs, despite the constant influx of hackernews articles, but "globally distributed system" is not a valid argument against using session IDs when most of us are working with a single fast db.
- sgammon 4y ago
  many apps these days are globally distributed virtually by their nature.

sgammon 4y ago

This was definitely written pre Auth0 acquisition, just saying

Terrencees 4y ago

[flagged]

sascha_sl 4y ago

>In this case the requesting party will have a token to prove their identity, and can forward it to the third (or 4th … nth) service without needing to incur a real-time validation each and every time. Someone missed the entire point of audience claims in OIDC - on okta.com no less.

kache_ 4y ago

JWT as a term used to describe signed material should considered harmful (source: me) It's basically just signed authentication material Use it when you need to keep your authentication layer horizontally scalable & stateless Use it when you're transferring trust to an untrusted system, acting on behalf of a user (SAML, OAuth, OIDC) that's it It's just signed material data size limitation (from the blog) is a big meme (source: me). Just pack it into a protobuf lmao eventual consistency of a stateful session will hurt you btw yes yes yes I know. The grey bears gave us protocols, rfcs, etc. MUH PROTOCOLS. just give me a private key and a bud light dude the protocols are important for oidc/oath/saml JWT ISN"T A PROTOCOL i'm tired, I should go sleep

can16358p 4y ago

While I don't necessarily disagree, I think using the globally accepted way of somehow utilizing JWTs outweigh the marginal and exaggerated (24MB for 100K requests is literally nothing in 2022) benefits. If I use JWT I get widely battle tested library support and near-universal acceptance among developers, which is more than enough for most of the folks to go with JWT IMHO.

Myrmornis 4y ago

What an awful article. Why is it talking down to their readers like that?

MikeYasnev007 4y ago

shp0ngle 4y ago

At this point, JWTs are a cargo cult. People do them because everyone else does them, even when it makes 0 reasons in the app itself and they use them as worse session tokens. Nobody was ever fired for using JWT for authentication.

somethingAlex 4y ago

>> “ A mission critical user check needs to run (eg: does this user have enough money in their account to complete the transaction?)” That info wouldn’t be in the session db row either. >> “ A database write needs to occur to persist information (if this information is related to the user, it’s likely that the full user object must also be retrieved from the database” This type of info doesn’t get updated frequently. Email, phone, name, etc, are pretty static. If they are just talking about a join using a userId, well that’s not gonna be any different whether you know the ID from a JWT or normal cookie. >> “ The full user object must be pulled out of the cache / database so that the website can properly generate its dynamic page content” But that’s an upside of keeping more than a cookie with an ID. You can just stash the stuff that doesn’t change much client side (keeping in mind the XSS risks). We certainly don’t pull the user’s email and name every page load even though it’s displayed on every page. >> “ Almost every web framework loads the user on every incoming request. This includes frameworks like Django, Rails, Express.js” That’s a framework issue and should be customizable. Not really a JWT vs cookie w/ ID topic There’s plenty of reasons to choose an ID cookie vs a JWT but the many that the author gives are not among them.

woile 4y ago

Has anyone tried https://www.biscuitsec.org/ https://www.biscuitsec.org/ ? I haven't seen it much discussed, and seems to solve a lot of issues from JWT

camgunz 4y ago

I found Security Cryptography Whatever's treatment of the various session token options super informative [0]. I had some vague unformed skeptical opinions about JWTs, and now I have some reasonably informed rational opinions about them, so can recommend. [0]: https://securitycryptographywhatever.buzzsprout.com/1822302/9020991-what-do-we-do-about-jwt-feat-jonathan-rudenberg https://securitycryptographywhatever.buzzsprout.com/1822302/...

ChicagoDave 4y ago

I’ve been building software for 35 years and web apps since “the beginning.” You couldn’t drag me back to server side state management for anything. OAuth2 and JWT tokens is one of best inventions and has proven itself quite thoroughly. This article was goofy in 2017 and it’s even goofier now.

senko 4y ago

Randall has also given a number of talks on the topic, so if you prefer watching to reading, have a look at https://www.youtube.com/watch?v=JdGOb7AxUo0 https://www.youtube.com/watch?v=JdGOb7AxUo0

deleted 4y ago

[deleted]