I've read several articles along these lines now I tend to think the arguments are pretty weak.
In this media rich age, the data size argument is a bit silly.
The "you're going to hit the database anyway" argument whilst probably accurate in most cases, doesn't invalidate that JWT allows for one or more fewer database hits on every request.
Having built-in integrity checking is definitely a feature. Just because you can do it without JWT doesn't mean that it's not useful that JWT does it.
IMHO the biggest argument against the use of JWT is that you can't easily invalidate JWT sessions. Should you need to dump a users session or if the information contained in that session token has become invalid then you might be in trouble. For my use cases so far however this hasn't been a problem.
JWT is a fine solution for quite a lot of use cases. As with everything tech, just be aware of the limitations and choose wisely.
I've been fond of [1] and [2] for a more focused argument against JWT for sessions.
The JOSE standards (of which JWT is a member) are error-prone and have had numerous critical security-affecting bugs due to how they were designed. [3]
To remedy that, I proposed PASETO. [4]
I still don't recommend PASETO for sessions, because of the arguments laid out in [1] and [2].
I concur with the author about session usage of JWT since it has little value (and if you did, just use it for it's signing feature and still have it just contain a random session identifier). The reasons for defending it in that use seem to be about what's not bad, but rarely about what's good.
But JWTs have value for API tokens as they can embed an expiration date for the caller in a known format. But the idea of stateless JWTs with a bunch of valid data for use on successive calls by the server is a bit much. You should contact your auth store of record per invocation for various reasons.
Like you said, be aware of the issues with chosen sig algorithms and be exact on what you choose and just leverage JWT as the format, not blindly following the generation libraries without investigation.
For signout we use token and user revocation lists represented as bloomfilters that services can poll or query directly if they need more consistency. This actually does work well in practice at very large scales efficiently we found.
> The "you're going to hit the database anyway" argument whilst probably accurate in most cases, doesn't invalidate that JWT allows for one or more fewer database hits on every request.
Using random session cookies does not prevent you from using caches.
> In this media rich age, the data size argument is a bit silly.
JWTs aren't cached, and cookies are sent on every request, so there's a much bigger multiplier on JWT size cost than there is on media size cost.
For invalidating, you just need to store the JTI (id, as a UUID) of the token in the DB. On challenge, you just compare the JTI of provided token to the one stored, and if there's a mismatch you 401. For doing the actual revokation, you can just clear the active JTI and have app code that would reject that. It's certainly arguable if this is worse or better than session tokens, but it's not unsolvable.
I have trouble understanding why session invalidation with JWT's is challenging. The JWT itself contains an IAT (issued at time) describing when the token was created. To invalidate all sessions, you can store (in your DB, or other persistence service) a 'invalidated at' date. Any request with a JWT that was issued before this 'invalidated at' date can be considered to be invalid.
>> IMHO the biggest argument against the use of JWT is that you can't easily invalidate JWT sessions
That's true. JWT is great for WebSocket connections because you can make the expiry really short (you could even make it 1 minute) and you could re-issue a new token in real-time every 50 seconds just before the previous one expires. Then if the user goes completely offline for 1 minute, then they lose their session (the JWT becomes invalid).
I think the most important part of that is "you're going to hit THE database". A single session token is more efficient but tightly couples all services. There's a single point of failure at whichever server does auth. Unlike JWTs, degradation or outages in token servers ripple through the whole system.
So when would you use session tokens? When you have a small application that you confidently predict will never outgrow being a monolith.
"In this media rich age, the data size argument is a bit silly."
I couldn't agree more !! Its just so much easier to do JWT specially if you got more than one server(api)
Not a huge fan of this article (despite being a huge fan and consumer of Okta). The author is making a number of assumptions that are bad architectural practices these days. These include:
1) Stateful services everywhere (assuming you always have a database)
2) That you are only doing interactive sessions, and not web services
3) That you have a single issuing authority that is non-federated
For stateful CRUD applications that don't need to scale, and have a centralized authority, by all means, use session cookies.
If, on the other-hand you have a application that needs multiple authentication sources, has a API on the other end that doesn't want to know a separate authentication path, or run stateless functions, JWT is a fairly good choice.
For most modern applications, session cookies create far more problems then the simple universal decision to use JWT across the board.
The one example this author gives for an appropriate use of JWTs isn't really any different than his previous ("bad") examples. In it, he suggests the case of an ensemble of services coupled to an authentication service, with an SPA front-end. The front-end obtains a JWT from the auth service and uses it to make API requests of the rest of the ensemble. Because the requests are "small" and "frequent", there's a savings to be had in using stateless authentication for them.
But SPA applications (and, for that matter, classic AJAX applications) have been making small, frequent API requests for 15 years. There is a standard solution to the problem of repeated session database lookups: caching. And in the unlikely instance of an application with significant enough usage that session lookups are problematic but no preexisting caching strategy, the standard answer here is simply to move sessions to a fast lossy database like Redis.
All the previous problems with JWTs remain in play in the author's "good" example.
There are better reasons to avoid JWT than are provided in this article, but it does a fine job of communicating the fundamental nut of the problem. You can easily do better, both for performance and for security, than JWT does. Chances are, your framework's existing session store already is better than JWT. Rails, for instance, has had stateless signed cookies for something like a decade.
We recommend you avoid JWT. If you want to be cool and use a non-default session token format, look into Macaroons.
We see JWT a lot. It's usually an accident and not really solving a problem.
Some notes for this blog post:
- It does not cover the worst issue with JWT (IMO): you don't get revocation by default. Some vendors use JWTs and still have revocation, but they do this via CRL management. CRL management is not easier than a session in a database.
- In the context of OAuth2, JWT is often a bearer token. This introduces a number of subtle flaws that OAuth1.0a did not have. Notably, in OAuth 1.0a, if I steal your credential for service X, I can't do anything with that without also having service X's credential. In OAuth2.0, it's a bearer token, so game over. You could argue this is an OAuth2.0 flaw -- or perhaps not even an OAuth2 flaw, because OAuth2.0 doesn't force you to do this. But OAuth2 and JWT make it the obvious choice, and so this model is now ubiquitous.
- It uses the phrase "signing" a lot. In JWT, signing usually means MACing, specifically with HMAC-SHA256. in other contexts "signing" often means using asymmetric cryptography: a separate verification and signing key. JWT supports both -- because JWT, in its folly, supports everything.
I think anyone who gives an article the now cliche "Why [popular thing] sucks" doesn't care about receiving charitable responses.
His use case at the end is describing microservice architecture. Microservice architecture is trending, ergo JWTs are trending. I don't see the problem.
This is ridiculous. It's 2018 and you're complaining about a few MB of bandwidth and a few seconds of CPU time? The whole point of JWT is that they are basically cookies for places where using cookies uniformly is not feasible. The author's solution is to go back to using cookies, which just doesn't work well enough. I'll stick with tokens for now thanks.
> ...a few MB of bandwidth and a few seconds of CPU time
Many people are on cell phones with low data limits. A "few MB", let's say 3MB == a few, represents 0.1% of someone's data limit. Sure, it's not that much on its own, but it adds up.
Likewise, a few seconds of CPU time is fine if you're on the latest iPhone, but if you're in a developing country on an inexpensive Android phone that few seconds of CPU time is going to turn into a world of hurt.
This cavalier attitude towards bandwidth and CPU time is outright hostile to certain classes of users.
Very weak reasons for not using jwt. If 24 megs a month is the reason you could easily remove an image from a high traffic page to get the sake savings.
You are hitting the database anyways reason applies to a limited subset of of use cases.
Sessions are simplier use them on multipage websites. SPA or apps jwt is perfect.
I like to keep things lean where I can, but saying I have to pay 24mb per 100k requests doesn't sound like a huge deal. And like you say, keeping an eye on your image sizes will net you much bigger savings.
One of the biggest downsides in my opinion is that session invalidation becomes non-trivial. Your best bet (assuming you don't want to do any additional network requests) is to reduce the session length to the smallest amount you (or users, depending) will tolerate and perform some kind of re-authentication; i.e. force a logout and do a fresh login or check if they can get a new token based on the old one transparently. For example, a user changing their password should kill all tokens that are in use immediately for good security. You can't do that with JWT. All tokens will stay valid until they expire.
I haven't used JWT but the way you solve this is by having a refresh token that lasts several days that lets you "login" without a password. The refresh token is then used to get the real session token with has a low expiration, perhaps 5 minutes. When the session token expires you just "login" again.
But honestly I don't see the need for the vast majority of applications. Most frameworks cache the permissions, etc on login so the database doesn't have to be accessed on every request.
« If we store the ID in a cookie, our total size is 6 bytes. »
No. What? No.
You can't compare a signed JWT with a bare user ID. The proper comparison is a signed JWT vs. a cryptographically random session identifier with sufficient entropy. It's still smaller than the JWT, pretty much by definition, but make the right comparison, please.
He -does- indicate "For storing a simple user session, that is a ~51x size inflation on every single page request in exchange for cryptographic signing (as well as some header metadata)."
So he admits that the signed part is the tradeoff. But I totally agree with you, barely mentioning that, when that's the whole point (JWTs are used for authentication/authorization, not just easily faked identification), is incredibly disingenuous. Never identify users on the client side with something that isn't cryptographically secure. Somewhere, you or another developer will end up implicitly believing that ID is trustworthy, and you just introduced a critical security flaw.
The offered solution to use a centeral memcache/Redis server is exactly why we moved to JWT.
First memcache and then Redis sessions were a continuous centeralized source of failure we could remove, and honestly didn’t scale very cleanly approaching millions of users.
Removing moving parts from our stack was a major win.
That’s not to say JWT is without thorns, but overall it’s better than a centeralized point of failure.
Biggest complaints about JWT is the inability to sign out a user. You can, yes, delete the cookie on the client side, but if the JWT is stolen you can’t be sure that it won’t be used again ( invalidate ).
Same happens on reset password, where by the book you need to sign out the user from every device. Good luck with that having standard JWT implementation.
My employer just started using Okta and I find it hard to take anything they say about security seriously after seeing some of the obvious bullshit in the immediate user-facing aspects of their product:
- allowing security questions to reset passwords
- allowing sms resets of passwords
- allowing sms 2-factor in combination with sms resets
I understand that my company is largely at fault for enabling these, but it's scary that they're even options. It's also pretty stupid that their password requirements are 8 characters, mixed case, and at least 1 number.
(Disclaimer: I work at Okta) One thing I've learned at a visceral level is how different threat models are from one organization to the next.
And while I agree that the things you brought up don't meet my personal standards for security, there are many organizations where those features are acceptable given their use case.
The reason why you should limit cookie sizes is request round trip.
A typical GET request involves multiple headers, including cookies. Cookies are sent for every request for any resource for a given domain. The more cookies you have, and the bigger they are, the bigger your request. The bigger your request, the more likely it is to take longer to send and receive it. The more of them you send, the more latency accumulates.
The model the author is complaining about is far too widespread unfortunately. I've seen a much worse incarnation at a huge corporation that I won't name but whose identity sleuths can doubtless figure out.
Here's how this goes:
When a user authenticates, the system sends them a public key encrypted blob inside a cookie. When the user makes further HTTPS requests the blob will be sent back, the system can decrypt it with the private key and get back the data inside. Components of the system would squirrel away per-user data inside this blob and so the cookie might get updated as they surfed around the site or did things.
One day, people behind a local component using this contraption asked me for some "advice". They'd "filled up" the blob and there didn't seem to be a way to add more data but they needed to store something else, I worked for a different part of the company but I knew about cryptography, what should they do now? They'd found that there didn't seem to be a "cipher mode" option for public key cryptography...
And so that's the point where I couldn't decide whether to laugh or cry, after that I spent a few hours on international conference calls basically telling people that they're idiots and nobody should have even _designed_ this let alone built it.
Part way through that I explained that encryption doesn't magically mean bad guys can't change the inside of the blob AND that it doesn't magically prevent bad guys from stealing blobs they found in one place and using them elsewhere. So what is this even for? In mitigation the engineers who built it explained that, er, actually the first thing they do with the blob after decrypting it is to check their session database to ensure all the data matches up, if not it's invalid and the user just gets logged out silently. Thus, at the end of the day, it's just functioning as a session ID checked against a database anyway. All this cryptographic effort is in fact completely wasted and achieves nothing in practice except to make the system far more complicated and fragile. Brilliant. /facepalm
JWTs are good for a bunch of things, one example being when you do NOT want to hit the database on every request, to speed up latency.. eg. in high-throughput IoT setups where you want to validate or discard the request before touching any DB at all
With http 2, repeatedly sending the same header value over a persistent connection should cause just a pointer to the previous value to be sent so I don't really buy the size argument here.
The unencrypted nature of these is something that gets overlooked a lot of times.
If you are transmitting metadata about some item, such as a song or a video, that’s one thing, but when it’s user info and the payload is not encrypted, you end up essentially leaking that data.
Other issues arise when you throw in logging and crash reporting - you may not even realize that that JWT session token just got logged and now you have user data where it doesn’t belong.
Most people here seem to fail to understand that apps rarely get slow and bloated through a single decision.
It is tons of 1% or 0.1% decisions.
Reading arguments here that this decision doesn't matter for size reasons, decoding performance, etc, is silly.
You can argue the same thing about any of the other 100 individual decisions that, in the aggregate, made your app slow and bloated.
Besides various other issues (design and implementation-wise) and the fact that it's a useless optimization anyway, minting tokens is just such a headache in general. Avoid it entirely if at all possible.
If you think you need JWTs or similar tech, you don't need JWTs or similar tech.
EDIT: I misunderstood what was meant by minting tokens, my entire comment is pointless. Save yourself the time.
What's the headache about minting tokens? You create a new uuid() on the server, store it in the DB in its own table which has references to accounts, keep an isValid field next to it for server-side invalidation, and store it in localStorage in the client. Is there a security flaw or something in this?
I've read so many of these anti-JWT articles, and I don't think I've ever come across a single reasonable complaint against them. What is wrong with people?
I've even read security reports by supposedly reputable security consultants also claiming that JWTs are bad but their arguments are hand wavy and make no sense.
>> Let’s say that your website gets roughly 100k page views per month. That means you’d be consuming an additional ~24MB of bandwidth each month.
Negligible.
>> You’re Going to Hit the Database Anyway
Yes, but less often. So your DB will be able to service more users overall. For some use cases, we're talking orders of magnitude more users.
> I've even read security reports by supposedly reputable security consultants also claiming that JWTs are bad but their arguments are hand wavy and make no sense.
Inability to do immediate revocations is a real drawback and a valid complaint.
If a trusted machine with a privileged token on it is compromised somehow, it will likely take the attacker some time to search for and discover the token. If you use centralized auth and you realize there was a breach before this happens (say from monitoring/anomaly alerts), you can revoke the token and prevent unauthorized access. If your token is JWT and it doesn't expire for another 45 minutes, you're in much worse shape.
This isn't the only factor to consider, but it's an important one.
[+] [-] AndrewSChapman|7 years ago|reply
In this media rich age, the data size argument is a bit silly.
The "you're going to hit the database anyway" argument whilst probably accurate in most cases, doesn't invalidate that JWT allows for one or more fewer database hits on every request.
Having built-in integrity checking is definitely a feature. Just because you can do it without JWT doesn't mean that it's not useful that JWT does it.
IMHO the biggest argument against the use of JWT is that you can't easily invalidate JWT sessions. Should you need to dump a users session or if the information contained in that session token has become invalid then you might be in trouble. For my use cases so far however this hasn't been a problem.
JWT is a fine solution for quite a lot of use cases. As with everything tech, just be aware of the limitations and choose wisely.
[+] [-] CiPHPerCoder|7 years ago|reply
The JOSE standards (of which JWT is a member) are error-prone and have had numerous critical security-affecting bugs due to how they were designed. [3]
To remedy that, I proposed PASETO. [4]
I still don't recommend PASETO for sessions, because of the arguments laid out in [1] and [2].
[1] http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...
[2] http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...
[3] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
[4] https://paseto.io
[+] [-] kodablah|7 years ago|reply
But JWTs have value for API tokens as they can embed an expiration date for the caller in a known format. But the idea of stateless JWTs with a bunch of valid data for use on successive calls by the server is a bit much. You should contact your auth store of record per invocation for various reasons.
Like you said, be aware of the issues with chosen sig algorithms and be exact on what you choose and just leverage JWT as the format, not blindly following the generation libraries without investigation.
[+] [-] xae342|7 years ago|reply
[+] [-] lvh|7 years ago|reply
Using random session cookies does not prevent you from using caches.
> In this media rich age, the data size argument is a bit silly.
JWTs aren't cached, and cookies are sent on every request, so there's a much bigger multiplier on JWT size cost than there is on media size cost.
[+] [-] _asummers|7 years ago|reply
[+] [-] sgslo|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] jondubois|7 years ago|reply
That's true. JWT is great for WebSocket connections because you can make the expiry really short (you could even make it 1 minute) and you could re-issue a new token in real-time every 50 seconds just before the previous one expires. Then if the user goes completely offline for 1 minute, then they lose their session (the JWT becomes invalid).
[+] [-] inlined|7 years ago|reply
So when would you use session tokens? When you have a small application that you confidently predict will never outgrow being a monolith.
[+] [-] rawoke083600|7 years ago|reply
[+] [-] InTheArena|7 years ago|reply
For stateful CRUD applications that don't need to scale, and have a centralized authority, by all means, use session cookies.
If, on the other-hand you have a application that needs multiple authentication sources, has a API on the other end that doesn't want to know a separate authentication path, or run stateless functions, JWT is a fairly good choice.
For most modern applications, session cookies create far more problems then the simple universal decision to use JWT across the board.
[+] [-] tptacek|7 years ago|reply
But SPA applications (and, for that matter, classic AJAX applications) have been making small, frequent API requests for 15 years. There is a standard solution to the problem of repeated session database lookups: caching. And in the unlikely instance of an application with significant enough usage that session lookups are problematic but no preexisting caching strategy, the standard answer here is simply to move sessions to a fast lossy database like Redis.
All the previous problems with JWTs remain in play in the author's "good" example.
There are better reasons to avoid JWT than are provided in this article, but it does a fine job of communicating the fundamental nut of the problem. You can easily do better, both for performance and for security, than JWT does. Chances are, your framework's existing session store already is better than JWT. Rails, for instance, has had stateless signed cookies for something like a decade.
We recommend you avoid JWT. If you want to be cool and use a non-default session token format, look into Macaroons.
[+] [-] lvh|7 years ago|reply
Some notes for this blog post:
- It does not cover the worst issue with JWT (IMO): you don't get revocation by default. Some vendors use JWTs and still have revocation, but they do this via CRL management. CRL management is not easier than a session in a database.
- In the context of OAuth2, JWT is often a bearer token. This introduces a number of subtle flaws that OAuth1.0a did not have. Notably, in OAuth 1.0a, if I steal your credential for service X, I can't do anything with that without also having service X's credential. In OAuth2.0, it's a bearer token, so game over. You could argue this is an OAuth2.0 flaw -- or perhaps not even an OAuth2 flaw, because OAuth2.0 doesn't force you to do this. But OAuth2 and JWT make it the obvious choice, and so this model is now ubiquitous.
- It uses the phrase "signing" a lot. In JWT, signing usually means MACing, specifically with HMAC-SHA256. in other contexts "signing" often means using asymmetric cryptography: a separate verification and signing key. JWT supports both -- because JWT, in its folly, supports everything.
[+] [-] faitswulff|7 years ago|reply
> It’s important to note that I don’t hate JWTs. I just think they’re useless for a majority of websites.
...and lays out a nuanced perspective of when they're an improvement over cookies at the end.
[+] [-] gramstrong|7 years ago|reply
His use case at the end is describing microservice architecture. Microservice architecture is trending, ergo JWTs are trending. I don't see the problem.
[+] [-] unquietcode|7 years ago|reply
[+] [-] Mister_Snuggles|7 years ago|reply
Many people are on cell phones with low data limits. A "few MB", let's say 3MB == a few, represents 0.1% of someone's data limit. Sure, it's not that much on its own, but it adds up.
Likewise, a few seconds of CPU time is fine if you're on the latest iPhone, but if you're in a developing country on an inexpensive Android phone that few seconds of CPU time is going to turn into a world of hurt.
This cavalier attitude towards bandwidth and CPU time is outright hostile to certain classes of users.
[+] [-] cwyers|7 years ago|reply
Ah, yes, 2018, the Year Where Everything On The Internet Is Connected To A Cable.
[+] [-] nine_k|7 years ago|reply
[+] [-] wolco|7 years ago|reply
You are hitting the database anyways reason applies to a limited subset of of use cases.
Sessions are simplier use them on multipage websites. SPA or apps jwt is perfect.
[+] [-] have_faith|7 years ago|reply
[+] [-] istvanp|7 years ago|reply
[+] [-] imtringued|7 years ago|reply
But honestly I don't see the need for the vast majority of applications. Most frameworks cache the permissions, etc on login so the database doesn't have to be accessed on every request.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] phyzome|7 years ago|reply
No. What? No.
You can't compare a signed JWT with a bare user ID. The proper comparison is a signed JWT vs. a cryptographically random session identifier with sufficient entropy. It's still smaller than the JWT, pretty much by definition, but make the right comparison, please.
[+] [-] lostcolony|7 years ago|reply
So he admits that the signed part is the tradeoff. But I totally agree with you, barely mentioning that, when that's the whole point (JWTs are used for authentication/authorization, not just easily faked identification), is incredibly disingenuous. Never identify users on the client side with something that isn't cryptographically secure. Somewhere, you or another developer will end up implicitly believing that ID is trustworthy, and you just introduced a critical security flaw.
[+] [-] donatj|7 years ago|reply
First memcache and then Redis sessions were a continuous centeralized source of failure we could remove, and honestly didn’t scale very cleanly approaching millions of users.
Removing moving parts from our stack was a major win.
That’s not to say JWT is without thorns, but overall it’s better than a centeralized point of failure.
[+] [-] gm-conspiracy|7 years ago|reply
[+] [-] drinchev|7 years ago|reply
Same happens on reset password, where by the book you need to sign out the user from every device. Good luck with that having standard JWT implementation.
[+] [-] sudovoodoo|7 years ago|reply
[+] [-] pkulak|7 years ago|reply
[+] [-] daveFNbuck|7 years ago|reply
- allowing security questions to reset passwords
- allowing sms resets of passwords
- allowing sms 2-factor in combination with sms resets
I understand that my company is largely at fault for enabling these, but it's scary that they're even options. It's also pretty stupid that their password requirements are 8 characters, mixed case, and at least 1 number.
[+] [-] jf|7 years ago|reply
And while I agree that the things you brought up don't meet my personal standards for security, there are many organizations where those features are acceptable given their use case.
[+] [-] devicenull|7 years ago|reply
[+] [-] peterwwillis|7 years ago|reply
A typical GET request involves multiple headers, including cookies. Cookies are sent for every request for any resource for a given domain. The more cookies you have, and the bigger they are, the bigger your request. The bigger your request, the more likely it is to take longer to send and receive it. The more of them you send, the more latency accumulates.
When The Cookie Crumbles https://yuiblog.com/blog/2007/03/01/performance-research-par...
Reduce Cookie Size https://developer.yahoo.com/performance/rules.html#cookie_si...
Performance Limits https://stackoverflow.com/a/6963585
[+] [-] tialaramex|7 years ago|reply
Here's how this goes:
When a user authenticates, the system sends them a public key encrypted blob inside a cookie. When the user makes further HTTPS requests the blob will be sent back, the system can decrypt it with the private key and get back the data inside. Components of the system would squirrel away per-user data inside this blob and so the cookie might get updated as they surfed around the site or did things.
One day, people behind a local component using this contraption asked me for some "advice". They'd "filled up" the blob and there didn't seem to be a way to add more data but they needed to store something else, I worked for a different part of the company but I knew about cryptography, what should they do now? They'd found that there didn't seem to be a "cipher mode" option for public key cryptography...
And so that's the point where I couldn't decide whether to laugh or cry, after that I spent a few hours on international conference calls basically telling people that they're idiots and nobody should have even _designed_ this let alone built it.
Part way through that I explained that encryption doesn't magically mean bad guys can't change the inside of the blob AND that it doesn't magically prevent bad guys from stealing blobs they found in one place and using them elsewhere. So what is this even for? In mitigation the engineers who built it explained that, er, actually the first thing they do with the blob after decrypting it is to check their session database to ensure all the data matches up, if not it's invalid and the user just gets logged out silently. Thus, at the end of the day, it's just functioning as a session ID checked against a database anyway. All this cryptographic effort is in fact completely wasted and achieves nothing in practice except to make the system far more complicated and fragile. Brilliant. /facepalm
[+] [-] aaaaaaaaaab|7 years ago|reply
[+] [-] hakanito|7 years ago|reply
[+] [-] clhodapp|7 years ago|reply
[+] [-] sologoub|7 years ago|reply
If you are transmitting metadata about some item, such as a song or a video, that’s one thing, but when it’s user info and the payload is not encrypted, you end up essentially leaking that data.
Other issues arise when you throw in logging and crash reporting - you may not even realize that that JWT session token just got logged and now you have user data where it doesn’t belong.
[+] [-] DannyBee|7 years ago|reply
[+] [-] blattimwind|7 years ago|reply
If you think you need JWTs or similar tech, you don't need JWTs or similar tech.
[+] [-] nickthemagicman|7 years ago|reply
[+] [-] bobberkarl|7 years ago|reply
[+] [-] _sdegutis|7 years ago|reply
What's the headache about minting tokens? You create a new uuid() on the server, store it in the DB in its own table which has references to accounts, keep an isValid field next to it for server-side invalidation, and store it in localStorage in the client. Is there a security flaw or something in this?
[+] [-] jondubois|7 years ago|reply
I've even read security reports by supposedly reputable security consultants also claiming that JWTs are bad but their arguments are hand wavy and make no sense.
>> Let’s say that your website gets roughly 100k page views per month. That means you’d be consuming an additional ~24MB of bandwidth each month.
Negligible.
>> You’re Going to Hit the Database Anyway
Yes, but less often. So your DB will be able to service more users overall. For some use cases, we're talking orders of magnitude more users.
[+] [-] CiPHPerCoder|7 years ago|reply
https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
https://blogs.adobe.com/security/2017/03/critical-vulnerabil...
These were critical vulnerabilities enabled by an error-prone cryptographic design that broke real systems.
Don't pretend it's hand-wavy.
[+] [-] danenania|7 years ago|reply
If a trusted machine with a privileged token on it is compromised somehow, it will likely take the attacker some time to search for and discover the token. If you use centralized auth and you realize there was a breach before this happens (say from monitoring/anomaly alerts), you can revoke the token and prevent unauthorized access. If your token is JWT and it doesn't expire for another 45 minutes, you're in much worse shape.
This isn't the only factor to consider, but it's an important one.