7 ms·

Don't use JWT: https://fly.io/blog/api-tokens-a-tedious-survey/ https://fly.io/blog/api-tokens-a-tedious-survey/ (by @tptacek)

by senko 5y ago

mooreds 5y ago
I respectfully disagree. (Full disclosure: I'm the author of the post and work at a company with software that produces a lot of JWTs.) Like any tool, JWT can be misused and you can do insecure things with it. I actually quote @tptacek in a different article about JWTs: https://fusionauth.io/learn/expert-advice/tokens/building-a-secure-jwt https://fusionauth.io/learn/expert-advice/tokens/building-a-... However, JWTs have strengths too. They are: * flexible * widely supported * standardized * stateless * portable * relatively easy to understand * extendable They also have libraries (often open source) to help you generate and consume them in almost every programming language, which is a huge help when it comes to using a tool securely. Edit: fixed typo (relative -> relatively).
- merlincorey 5y ago
  Why not PASETO?
  - mooreds 5y ago
    Widespread support is the biggest obstacle to PASETO adoption. Classic chicken and egg problem. I am also not aware of it being standardized (a brief google shows it is in progress, which is nice). Other than that, it seems nice. A better JWT than JWT with some of the sharp edges removed. I've actually filed an issue for our product to support PASETO and it's gotten some community support, but not an overwhelming amount.
    - deleted 5y ago
      [deleted]
- Sohcahtoa82 5y ago
  > stateless This is a bug, not a feature, especially if you make your tokens long-lived. If your implementation is completely stateless, then there's no way to invalidate a token to allow a user to log out. If a JWT somehow gets stolen, the user has no way to terminate the stolen session. At best, you could create a blacklist of tokens that have been invalidated, which would delete rows as time goes on and the tokens reach their natural expiration date to avoid the database growing forever. But at that point, it's no longer stateless.
  - mooreds 5y ago
    > especially if you make your tokens long-lived Agreed! You should never make tokens long lived. Seconds to minutes is what we typically see. "But won't users have to log in whenever the token expires?" Nope, that's what the refresh grant (in the OAuth world) is for. I am not as familiar with other uses of JWT, but I suspect there is a similar process that relies on the issuer for them. > But at that point, it's no longer stateless. Agreed, it is an architectural choice. You can choose the benefits of statelessness (scale) at a cost of revocation difficulties. You can get revocation, but you have to re-introduce state. Is there some token solution out that that I'm unaware of that gives you statelessness and revocation? Would love to learn more about it if so.
    - tptacek 5y ago
      The refresh grant is itself a long-lived, difficult-to-revoke token. TANSTAAFL.
      - daveidol 5y ago
        Just like a session cookie is long-lived? At least with a refresh token you can keep things like specific roles etc. out of it and treat it much like an opaque session cookie (perhaps just containing nothing but the user's ID, which can be looked up to get the real roles/permissions for the short-lived access tokens). I think it's dubious to call refresh tokens "difficult-to-revoke" but call sessions easy to revoke. Both require some kind of state. The difference is that you are (hopefully) doing far more grants and checks on tokens than you are doing revokes - so why not optimize for that flow?
rahulpadalkar 5y ago
Why use JWT? https://www.educative.io/edpresso/why-should-you-use-jwts https://www.educative.io/edpresso/why-should-you-use-jwts There are downsides for almost everything out there. Outright dismissing JWTs is not correct.
ivanhoe 5y ago
IMHO rule of the thumb is: If you can get away with simple random tokens, use that. If you can't (high-traffic distributed apps, microservices, serverless, etc.) JWT is probably the next easiest solution.
- senko 5y ago
  That's reasonable. I see so many cases where someone asks "what should I use for auth" and immediately the answer given is JWT, where simple random tokens or session auth would be just fine. And simpler to implement, since they're supported out-of-the box in many frameworks.
  - robotdan 5y ago
    This is a good point. Keeping it simple is always a good engineering choice. I think one of the reasons JWTs come up so often is that if you are going to use OAuth2/OpenID Connect - ideally the Authorization Code grant, then tokens become an important component. And many IdPs implement the OAuth2 access token as a JWT. So it may be that your IdP ends up making this choice for you. Then you have to learn how to deal with JWTs.
LVB 5y ago
I do wonder what percentage of folks are actually in a position to choose? For a lot of people they’re going to be interacting with JWTs because they’re dealing with someone else’s auth, so the more they know about this structure the better.
- mooreds 5y ago
  That's a great point. As a dev, lots of times you're working with an auth provider, either from a social login like Google or from a centrally managed service. In either case, you can suggest "let's use <X> token" where X is paseto or something else, but you can't dictate it (Google certainly won't listen and change formats :) ).
rad_gruchalski 5y ago
Why not? The article does not really answer why not. > This is a problem because the ability to read your user profile isn’t a good identity proof. You might grant that capability to applications for reasons having nothing to do with whether they can “log in with Twitter” to a dating app. People found a bunch of vulnerabilities. > Enter OpenID Connect (OIDC). OIDC is the demon marriage of OAuth 2.0 and a cryptographic token standard called JWT. OIDC’s is unambiguous: it gives you an “Identity Token”, JWT-encoded, that tells you who’s logging in. Ah, so it’s more of a case “don’t use jwt… incorrectly“. I also recommended looking at UMA2 and resource servers. Keycloak has, what I’d call, my to go reference implementation.
phendrenad2 5y ago
Agreed, JWTs fill a niche, and there are also several footguns, and most people are better off avoiding them.
makeitdouble 5y ago
It's jarring to me how much tptacek's comments are usually very succinct and heavily factual, and this blog is ....long for no reason, very rambling (I don't need biblical references in technical discussions...), and way too emotional to be convincing. My main takeaway from it that JWTs aren't magical, there's exploit vectors that need to be taken into account, and as any security related thing, you need to do your homework to have a decently secured application. That's pretty far from "don't use JWT"
- tptacek 5y ago
  It's jarring to you because someone else reframed the post as "don't use JWT" (a thing I believe!), and that's not what it's about. See, here, the power of people to control the terms in which people read and think about subjects by creating their own titles to things!

Don't use JWT: https://fly.io/blog/api-tokens-a-tedious-survey/ https://fly.io/blog/api-tokens-a-tedious-survey/ (by @tptacek)

by senko 5y ago

Don't use JWT: https://fly.io/blog/api-tokens-a-tedious-survey/ https://fly.io/blog/api-tokens-a-tedious-survey/ (by @tptacek)

mooreds 5y ago

I respectfully disagree. (Full disclosure: I'm the author of the post and work at a company with software that produces a lot of JWTs.) Like any tool, JWT can be misused and you can do insecure things with it. I actually quote @tptacek in a different article about JWTs: https://fusionauth.io/learn/expert-advice/tokens/building-a-secure-jwt https://fusionauth.io/learn/expert-advice/tokens/building-a-... However, JWTs have strengths too. They are: * flexible * widely supported * standardized * stateless * portable * relatively easy to understand * extendable They also have libraries (often open source) to help you generate and consume them in almost every programming language, which is a huge help when it comes to using a tool securely. Edit: fixed typo (relative -> relatively).

merlincorey 5y ago
Why not PASETO?
- mooreds 5y ago
  Widespread support is the biggest obstacle to PASETO adoption. Classic chicken and egg problem. I am also not aware of it being standardized (a brief google shows it is in progress, which is nice). Other than that, it seems nice. A better JWT than JWT with some of the sharp edges removed. I've actually filed an issue for our product to support PASETO and it's gotten some community support, but not an overwhelming amount.
  - deleted 5y ago
    [deleted]
Sohcahtoa82 5y ago
> stateless This is a bug, not a feature, especially if you make your tokens long-lived. If your implementation is completely stateless, then there's no way to invalidate a token to allow a user to log out. If a JWT somehow gets stolen, the user has no way to terminate the stolen session. At best, you could create a blacklist of tokens that have been invalidated, which would delete rows as time goes on and the tokens reach their natural expiration date to avoid the database growing forever. But at that point, it's no longer stateless.
- mooreds 5y ago
  > especially if you make your tokens long-lived Agreed! You should never make tokens long lived. Seconds to minutes is what we typically see. "But won't users have to log in whenever the token expires?" Nope, that's what the refresh grant (in the OAuth world) is for. I am not as familiar with other uses of JWT, but I suspect there is a similar process that relies on the issuer for them. > But at that point, it's no longer stateless. Agreed, it is an architectural choice. You can choose the benefits of statelessness (scale) at a cost of revocation difficulties. You can get revocation, but you have to re-introduce state. Is there some token solution out that that I'm unaware of that gives you statelessness and revocation? Would love to learn more about it if so.
  - tptacek 5y ago
    The refresh grant is itself a long-lived, difficult-to-revoke token. TANSTAAFL.
    - daveidol 5y ago
      Just like a session cookie is long-lived? At least with a refresh token you can keep things like specific roles etc. out of it and treat it much like an opaque session cookie (perhaps just containing nothing but the user's ID, which can be looked up to get the real roles/permissions for the short-lived access tokens). I think it's dubious to call refresh tokens "difficult-to-revoke" but call sessions easy to revoke. Both require some kind of state. The difference is that you are (hopefully) doing far more grants and checks on tokens than you are doing revokes - so why not optimize for that flow?

rahulpadalkar 5y ago

Why use JWT? https://www.educative.io/edpresso/why-should-you-use-jwts https://www.educative.io/edpresso/why-should-you-use-jwts There are downsides for almost everything out there. Outright dismissing JWTs is not correct.

ivanhoe 5y ago

IMHO rule of the thumb is: If you can get away with simple random tokens, use that. If you can't (high-traffic distributed apps, microservices, serverless, etc.) JWT is probably the next easiest solution.

senko 5y ago
That's reasonable. I see so many cases where someone asks "what should I use for auth" and immediately the answer given is JWT, where simple random tokens or session auth would be just fine. And simpler to implement, since they're supported out-of-the box in many frameworks.
- robotdan 5y ago
  This is a good point. Keeping it simple is always a good engineering choice. I think one of the reasons JWTs come up so often is that if you are going to use OAuth2/OpenID Connect - ideally the Authorization Code grant, then tokens become an important component. And many IdPs implement the OAuth2 access token as a JWT. So it may be that your IdP ends up making this choice for you. Then you have to learn how to deal with JWTs.

LVB 5y ago

I do wonder what percentage of folks are actually in a position to choose? For a lot of people they’re going to be interacting with JWTs because they’re dealing with someone else’s auth, so the more they know about this structure the better.

mooreds 5y ago
That's a great point. As a dev, lots of times you're working with an auth provider, either from a social login like Google or from a centrally managed service. In either case, you can suggest "let's use <X> token" where X is paseto or something else, but you can't dictate it (Google certainly won't listen and change formats :) ).

rad_gruchalski 5y ago

Why not? The article does not really answer why not. > This is a problem because the ability to read your user profile isn’t a good identity proof. You might grant that capability to applications for reasons having nothing to do with whether they can “log in with Twitter” to a dating app. People found a bunch of vulnerabilities. > Enter OpenID Connect (OIDC). OIDC is the demon marriage of OAuth 2.0 and a cryptographic token standard called JWT. OIDC’s is unambiguous: it gives you an “Identity Token”, JWT-encoded, that tells you who’s logging in. Ah, so it’s more of a case “don’t use jwt… incorrectly“. I also recommended looking at UMA2 and resource servers. Keycloak has, what I’d call, my to go reference implementation.

phendrenad2 5y ago

Agreed, JWTs fill a niche, and there are also several footguns, and most people are better off avoiding them.

makeitdouble 5y ago

It's jarring to me how much tptacek's comments are usually very succinct and heavily factual, and this blog is ....long for no reason, very rambling (I don't need biblical references in technical discussions...), and way too emotional to be convincing. My main takeaway from it that JWTs aren't magical, there's exploit vectors that need to be taken into account, and as any security related thing, you need to do your homework to have a decently secured application. That's pretty far from "don't use JWT"

tptacek 5y ago
It's jarring to you because someone else reframed the post as "don't use JWT" (a thing I believe!), and that's not what it's about. See, here, the power of people to control the terms in which people read and think about subjects by creating their own titles to things!