3 ms·

My biggest problem with JWT is that it's way overhyped, leading less experienced devs to believe JWT is the only way to implement auth, unless you use a 3rd par

by senko 4y ago

My biggest problem with JWT is that it's way overhyped, leading less experienced devs to believe JWT is the only way to implement auth, unless you use a 3rd party provider. JWT is a solution to a problem 95% of us don't have: https://apibakery.com/blog/tech/no-jwt/ https://apibakery.com/blog/tech/no-jwt/

candiodari 4y ago
Yes, but what developers want from JWT is: 1) not having to worry about authentication in their app (and not about security issues, exploits, account recovery, fake accounts, bots, ...) 3) the ability to use it in any framework they want (e.g. the Go standard library "framework") 4) the ability to "upgrade" to full microservice authorization And yes, these are sort-of kind-of not-quite-but-almost provided in Django, Spring and Ruby On Rails, but if you want to use whatever framework you want ... JWT is definitely the closest thing available, or at least it seems so.
goodpoint 4y ago
Like most web stuff and the blockchain, JWT sound fancy but it is a very trivial thing.
- deleted 4y ago
  [deleted]
hbrn 4y ago
To add to that, even if you have microservices everywhere on the backend, JWT is still rarely a good choice. Those services are typically exposed to customers via some sort of API Gateway/BFF. So if your clients don't speak to microservices directly, authentication between those services could easily be done via plain old HTTP Basic Auth. Stripe has been doing that for their public API since forever, and that's one of the big reasons why it is so easy to work with them.
- tobyjsullivan 4y ago
  It's worth noting this coconut pattern (hard auth facade, soft interior), while popular and helpful for dev efficiency, is a weak security practice. Using simple pre-shared keys between internal services excludes any meaningful access controls over user data. Whether that's important depends on the domain. For stripe, though, I'm surprised they wouldn't want to ensure internal data requests are being made on behalf of customers who should actually have access to the data. Also, for bigger companies (although, why not smaller ones?), you hit a point where you can't keep blindly trusting every service. Better to have internal security controls. As for when these tradeoffs are appropriate, hard to say. But a good rule of thumb could be when the product is big enough to need an SOA.
  - hbrn 4y ago
    > As for when these tradeoffs are appropriate, hard to say And that is my biggest problem. If you don't know whether you need something, you don't need it. Or you just don't have enough expertise to understand why you need it, but that means you will implement it the wrong way anyway.
    - marcosdumay 4y ago
      > If you don't know whether you need something, you don't need it. That's a bad approach for security. Starting with the solution is the wrong way to do it, but you certainly need to actively look if you have problems.
      - hbrn 4y ago
        Let's say you're a startup that's hiring it's 5th engineer. Should you do criminal background checks? Install spyware on laptops? Forbid hiring from other countries? Restrict developer access to production env? Invest all your development time into security features until you run out of those? If you actively look for problems, you will justify all of those. Security is not about knowing which problems exist and fixing them all. It's about knowing which risks are acceptable at your current stage. If you don't know which risks are acceptable, applying random security practices is worse than no security at all. At least when there's no security you are aware of it. If you can't come up with an attack vector where HTTP Basic Auth causes significant problems, you don't need JWT to secure communication. And even if you can come up with an attack vector, is it really easiest one to execute? Speaking of attack vectors, how many of the folks that use JWT for inter-service communication actually rotate encryption keys when anyone who has access to them leaves the company? My bet is very few.
yencabulator 4y ago
Worse than that, even when JWT is a solution to a problem you have, it's a bad solution. https://web.archive.org/web/20180324054020/https://storify.com/jcuid/thomas-h-ptacek-don-t-use-json-web-tokens https://web.archive.org/web/20180324054020/https://storify.c... https://twitter.com/FiloSottile/status/1300946068411121665 https://twitter.com/FiloSottile/status/1300946068411121665 https://insomniasec.com/blog/auth0-jwt-validation-bypass https://insomniasec.com/blog/auth0-jwt-validation-bypass https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
feoren 4y ago
> This brings us back to how we implement authentication in Node projects you generate with API Bakery. If you've read all of the above, no surprise here - we use bearer tokens. WTF? They just spent the whole article talking about how bearer tokens were stupid (everything they said about JWT applies to all bearer tokens). And then they say "instead of this thing we said was stupid, we use the exact same thing but named differently". WTF?
- jsmith45 4y ago
  Nonsense. Issues like inability to revoke JWTs don't apply to bearer tokens where the API server needs to query the token issuer to found out who the user is (which can then implment revoking the token simply by dropping the record for the token from the DB, all further calls will fail the lookup!) Remember they stated: > Major advantage of JWT compared to bearer tokens [...] is that they don't require looking up the token. Other problems with JWTs vs opaque bearer tokens they listed include: - increased attack surface due to complexity of JSON parsing/validation - misconfiguring JWT libraries to allow no signature - leaking data to users because you thought JWTs were encrypted Now you are right that some of the complexities involved with JWTs like refresh token can apply with arbitrary bearer tokens, especially if you want to limit the lifespan of the access token, but those are implementation choices. Technically you can just have a single long lived bearer token instead of a long lived refresh token, and a short lived access token.
  - feoren 4y ago
    Hold on, this is backward. They said: > You should not use Thing X because the advantage it has over Thing Y is not an advantage. In fact both Thing X and Thing Y have the same disadvantage. Except that Thing X has a workaround and Thing Y doesn't. But that workaround adds (gasp!) complexity! Obviously, we only ever use Thing Y and you're a bad developer if you use Thing X. It's smoke and mirrors. They never give an advantage of bearer tokens over, well, JWT barer tokens, which are a type of bearer token, the thing they said they use. They just said JWTs don't actually have one specific advantage, except when they do. That's not an argument against JWTs! > increased attack surface due to complexity of JSON parsing/validation People who use JWTs are already parsing JSON everywhere. It's not hard. If it's not valid JSON, clearly you don't authenticate. > misconfiguring JWT libraries to allow no signature You can misconfigure anything. You can misconfigure your server to not actually check the bearer token. Why is it more likely you'll forget to check the JWT signature than the bearer token? This is something you write one time and never touch; it takes an afternoon at most. > leaking data to users because you thought JWTs were encrypted Yes, you should not put sensitive data in a JWT, encrypted or not. This is a fair criticism. > Technically you can just have a single long lived bearer token instead of a long lived refresh token, and a short lived access token. Which, as they pointed out in that article, is a disadvantage of long-lived bearer tokens.

by senko 4y ago

candiodari 4y ago

Yes, but what developers want from JWT is: 1) not having to worry about authentication in their app (and not about security issues, exploits, account recovery, fake accounts, bots, ...) 3) the ability to use it in any framework they want (e.g. the Go standard library "framework") 4) the ability to "upgrade" to full microservice authorization And yes, these are sort-of kind-of not-quite-but-almost provided in Django, Spring and Ruby On Rails, but if you want to use whatever framework you want ... JWT is definitely the closest thing available, or at least it seems so.

goodpoint 4y ago

Like most web stuff and the blockchain, JWT sound fancy but it is a very trivial thing.

deleted 4y ago
[deleted]

hbrn 4y ago

To add to that, even if you have microservices everywhere on the backend, JWT is still rarely a good choice. Those services are typically exposed to customers via some sort of API Gateway/BFF. So if your clients don't speak to microservices directly, authentication between those services could easily be done via plain old HTTP Basic Auth. Stripe has been doing that for their public API since forever, and that's one of the big reasons why it is so easy to work with them.

tobyjsullivan 4y ago
It's worth noting this coconut pattern (hard auth facade, soft interior), while popular and helpful for dev efficiency, is a weak security practice. Using simple pre-shared keys between internal services excludes any meaningful access controls over user data. Whether that's important depends on the domain. For stripe, though, I'm surprised they wouldn't want to ensure internal data requests are being made on behalf of customers who should actually have access to the data. Also, for bigger companies (although, why not smaller ones?), you hit a point where you can't keep blindly trusting every service. Better to have internal security controls. As for when these tradeoffs are appropriate, hard to say. But a good rule of thumb could be when the product is big enough to need an SOA.
- hbrn 4y ago
  > As for when these tradeoffs are appropriate, hard to say And that is my biggest problem. If you don't know whether you need something, you don't need it. Or you just don't have enough expertise to understand why you need it, but that means you will implement it the wrong way anyway.
  - marcosdumay 4y ago
    > If you don't know whether you need something, you don't need it. That's a bad approach for security. Starting with the solution is the wrong way to do it, but you certainly need to actively look if you have problems.
    - hbrn 4y ago
      Let's say you're a startup that's hiring it's 5th engineer. Should you do criminal background checks? Install spyware on laptops? Forbid hiring from other countries? Restrict developer access to production env? Invest all your development time into security features until you run out of those? If you actively look for problems, you will justify all of those. Security is not about knowing which problems exist and fixing them all. It's about knowing which risks are acceptable at your current stage. If you don't know which risks are acceptable, applying random security practices is worse than no security at all. At least when there's no security you are aware of it. If you can't come up with an attack vector where HTTP Basic Auth causes significant problems, you don't need JWT to secure communication. And even if you can come up with an attack vector, is it really easiest one to execute? Speaking of attack vectors, how many of the folks that use JWT for inter-service communication actually rotate encryption keys when anyone who has access to them leaves the company? My bet is very few.

yencabulator 4y ago

Worse than that, even when JWT is a solution to a problem you have, it's a bad solution. https://web.archive.org/web/20180324054020/https://storify.com/jcuid/thomas-h-ptacek-don-t-use-json-web-tokens https://web.archive.org/web/20180324054020/https://storify.c... https://twitter.com/FiloSottile/status/1300946068411121665 https://twitter.com/FiloSottile/status/1300946068411121665 https://insomniasec.com/blog/auth0-jwt-validation-bypass https://insomniasec.com/blog/auth0-jwt-validation-bypass https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

feoren 4y ago

> This brings us back to how we implement authentication in Node projects you generate with API Bakery. If you've read all of the above, no surprise here - we use bearer tokens. WTF? They just spent the whole article talking about how bearer tokens were stupid (everything they said about JWT applies to all bearer tokens). And then they say "instead of this thing we said was stupid, we use the exact same thing but named differently". WTF?

jsmith45 4y ago
Nonsense. Issues like inability to revoke JWTs don't apply to bearer tokens where the API server needs to query the token issuer to found out who the user is (which can then implment revoking the token simply by dropping the record for the token from the DB, all further calls will fail the lookup!) Remember they stated: > Major advantage of JWT compared to bearer tokens [...] is that they don't require looking up the token. Other problems with JWTs vs opaque bearer tokens they listed include: - increased attack surface due to complexity of JSON parsing/validation - misconfiguring JWT libraries to allow no signature - leaking data to users because you thought JWTs were encrypted Now you are right that some of the complexities involved with JWTs like refresh token can apply with arbitrary bearer tokens, especially if you want to limit the lifespan of the access token, but those are implementation choices. Technically you can just have a single long lived bearer token instead of a long lived refresh token, and a short lived access token.
- feoren 4y ago
  Hold on, this is backward. They said: > You should not use Thing X because the advantage it has over Thing Y is not an advantage. In fact both Thing X and Thing Y have the same disadvantage. Except that Thing X has a workaround and Thing Y doesn't. But that workaround adds (gasp!) complexity! Obviously, we only ever use Thing Y and you're a bad developer if you use Thing X. It's smoke and mirrors. They never give an advantage of bearer tokens over, well, JWT barer tokens, which are a type of bearer token, the thing they said they use. They just said JWTs don't actually have one specific advantage, except when they do. That's not an argument against JWTs! > increased attack surface due to complexity of JSON parsing/validation People who use JWTs are already parsing JSON everywhere. It's not hard. If it's not valid JSON, clearly you don't authenticate. > misconfiguring JWT libraries to allow no signature You can misconfigure anything. You can misconfigure your server to not actually check the bearer token. Why is it more likely you'll forget to check the JWT signature than the bearer token? This is something you write one time and never touch; it takes an afternoon at most. > leaking data to users because you thought JWTs were encrypted Yes, you should not put sensitive data in a JWT, encrypted or not. This is a fair criticism. > Technically you can just have a single long lived bearer token instead of a long lived refresh token, and a short lived access token. Which, as they pointed out in that article, is a disadvantage of long-lived bearer tokens.