28 ms·

Should I use JWTs for authentication tokens?

• zie 2y ago
  Not to mention it's ridiculously easy to make JWT's insecure.
  • toenail 2y ago
    It's ridiculously easy to make any computer insecure.
    • finack 2y ago
      Some computers make it harder than others.
  • EthanHeilman 2y ago
    Can you provide some examples here using modern JWT libraries? I'm not saying you are wrong or right, but this comment as it is written doesn't add much to the discussion.
    • CiPHPerCoder 2y ago
      https://github.com/firebase/php-jwt/issues/351 https://github.com/firebase/php-jwt/issues/351
      • EthanHeilman 2y ago
        Thanks for providing this, it is interesting vulnerability to read about. In terms of JWT vs other ways of doing this, is there any evidence that JWTs are more vulnerable that other approaches? Clearly there are vulnerabilities is other approaches as well. I buy the statement that bearer authentication JWTs are much worse than proof of possession JWTs, but are bearer authentication JWTs worse than other bearer authentication approaches? What data would you need to argue that position
        • CiPHPerCoder 2y ago
          > In terms of JWT vs other ways of doing this, is there any evidence that JWTs are more vulnerable that other approaches? Clearly there are vulnerabilities is other approaches as well. Contrast JWTs with PASETO implementations when you make that sort of analysis. i.e., pick any that support v3/v4 and try to attack them the same way that JWT implementations have been vulnerable, or worse ways: https://paseto.io https://paseto.io
          • EthanHeilman 2y ago
            Thanks for sharing this. I do a lot of work in this area and I had not come across PASETO before. It is an exciting project. The nonce is especially nice because it makes the token high entropy enough that if only the signature leaks an attacker can't brute force the full token. This isn't always true in OIDC JWTs.
  • bebop 2y ago
    I have not seen an authorization server that makes it easy to configure no signing algorithm or even one that might be considered insecure. Most of the client authentication providers I have used (I.e frameworks) have also forced a secure algorithm, usually starting with rsa 256. So while technically you can use a no algorithm signer, I have never seen this happen.
    • CiPHPerCoder 2y ago
      The vulnerability is usually in verifiers rather than signers. See, for example: https://github.com/firebase/php-jwt/issues/351 https://github.com/firebase/php-jwt/issues/351
• ramesh31 2y ago
  So then why does Auth0 use JWTs for everything..?
  • zaphar 2y ago
    Because their business is auth as a service and because their database is not your database and they don't want you hitting their database directly. A similar question to the articles is whether you actually need Auth0 or not. You might but then you are offloading all the issues of JWT's to Auth0 so in theory, probably not in practice, you don't have to worry about those. For many apps however. You probably don't really need Auth0.
    • CuriouslyC 2y ago
      Need? Maybe not. But it's a time saver out of the gate.
    • FerdSlav 2y ago
      As someone that is just attempting to get a better understanding of this aspect of a tech stack, when you say many apps don’t need Auth0 what is the actual alternative for the whole user authentication story?
      • zaphar 2y ago
        Most web frameworks come with out of the box authentication plugins that will use your own database. It's plenty good enough and you still don't have to roll your own. Adding an external service adds complexity that you may not want to pay for later.
      • angoragoats 2y ago
        Submit a username and password via a form over https. Your backend hashes the password, and checks it against the stored (hashed) password in your database. If it matches, the user provided the correct password. Create a session token (random string is fine) and return it to the user via a cookie in the reply. Store the session token in your database, such that you can map it to the authenticated user. Then on each subsequent request, look up the session token and you have your logged in user. This is how apps were doing it for literally decades, before JWT was invented. And most web frameworks will do all of this for you.
• endisneigh 2y ago
  Jwts are fine, just use them properly.
  • pwpwp 2y ago
    Maybe address any of the issues raised in the post?
    • deleted 2y ago
      [deleted]
  • croes 2y ago
    C/C++ is just fine, just use it properly.
    • shiandow 2y ago
      Rolling your own crypto is fine, just do it properly.
• gizzlon 2y ago
  You can implement a blocklist of all the revoked JWT and publish it to all servers. The list should be small, because only otherwise valid tokens need to be included. It becomes so much more complicated than a simple check-the-db setup though. I don't think I would start with JWT if I did this again.
  • esafak 2y ago
    what would you do?
    • gizzlon 2y ago
      Sessions, like it's 2005 :P See above.
  • brabel 2y ago
    You're talking about tokens in general, not just JWT. The only alternative I know to tokens is to query the DB every time (or perhaps use a cache to make the lookup less often, but then you also have to find a way to invalidate the cache - back to square one?).
    • gizzlon 2y ago
      > You're talking about tokens in general, not just JWT. Yes, all stateless tokens. But I have never seen an in-house token system that was not using JWT's. Yes, query the DB or some sort of storage every time. It sounded so clean and nice and fast to just check JWTs without any network calls. But it ended up very messy and complicated. Might still be worth it in some cases, of course, but I would start my next project with random sessions stored in a db or redis or memcache or .. something :) You can actually do crazy stuff with your sessions as well, to avoid a normal db lookup. But in practice all services I have worked on would/did not suffer noticeably for a fast DB lookup.
  • cryptonector 2y ago
    Having to list the tokens to revoke is a problem in several ways. Obviously publishing the tokens themselves allows attackers to use them before relying parties get the revocation notice, so publish a token hash instead. But even publishing a token hash is annoying because you then have to record all the claims + token hashes issued, and that's a failure point. Instead you'd want to revoke _subjects_ (`sub`), but since tokens don't have to have those... (In enterprise systems though your tokens should name subjects.)
• weinzierl 2y ago
  Using JWT from Keycloak just to obtain a session cookie. Is this a common pattern or a smell?
  • doctorpangloss 2y ago
    It's a good idea. The article conflates authentication with authorization. Your application can authorize many different ways, most do. You can use your session for authorization - your application can decide what a person can and can't do. But facts about the user's identity never change, like their uniquely generated ID in your database, and that's what gets stored in Keycloak's `sub` field, so it's fine to use that for trading a token for a session cookie. Their password does change but that's Keycloak's job, is to turn passwords into authentication tokens. The JWT always stores facts about the principal (aka who or what is doing something), and those don't really make sense to revoke or whatever anyway. Stuff that will never change over time. JWTs can optionally store something like a `role` or similar fact that may change over time, specific to your application. Those facts can be used to decide what you can do in your application, that's authorization. We could talk about when and how that should be done, but it would be too nuanced for these evergreen JWT blogposts.
    • tptacek 2y ago
      The article isn't talking about authz at all.
      • deleted 2y ago
        [deleted]
  • eYrKEC2 2y ago
    Taking complete systems off the shelf and using them smells a lot like money. If/when your app requires enterprise integration, you'll be fanatically happy that you chose Keycloak over having to implement okta... then ldap... then.. Saml... then.. Kerberos... then ldap again with custom mappers..
• davedx 2y ago
  Okay I'll bite... This post doesn't seem to address microservice architectures at all? For me, this is the primary reason to use JWT's -- so you can pass authentication ("claims", or whatever you want to call them) through your chain of microservice service-to-service calls. If you don't have microservices then there's much less reason to use JWT's. I'm not saying the article is a strawman exactly, but it does seem to miss the primary use case of JWT's. At least, the way I've used them in anger. Also, the "JWT's can be insecure if you use the wrong library or configure them incorrectly" argument, while having some points, seems to me more of an argument that you should really do due diligence on any libraries you use for security. The better JWT libraries are not insecure by default. I wouldn't use JWT's if I were making a monolith, but there are lots of companies who (for better or worse) use microservices.
  • doctorpangloss 2y ago
    > so you can pass authentication ("claims", or whatever you want to call them) through your chain of microservice service-to-service calls. This is a misconception about so called zero trust. You can't "just" pass the same token to someone else. They can use it to impersonate or misuse the token later. While you are going to say that "my microservices will not impersonate users because to each other, they are all trusted," you have run directly into the difference between trusted and zero trust.
    • EthanHeilman 2y ago
      > This is a misconception about so called zero trust. You can't "just" pass the same token to someone else. They can use it to impersonate or misuse the token later. Put another way, JWTs used as bearer tokens have vulnerable to intra-audience replay attacks. While this is true for many zero trust architectures, but you don't have to build zero trust architectures this way. Simply have the token commit to a public key of a signing key held by the identity, then you can do Proof-of-Possession and remove these replay attacks. This is the direction zero trust is headed. For instance AWS is slowly moving toward this with sigV4A. Most zero trust solutions aren't there yet.
• EthanHeilman 2y ago
  > By just using a “normal” opaque session token and storing it in the database, the same way Google does with the refresh token, and dropping all jwt authentication token nonsense. Not only is this true, but most actual deployments of JWTs just have you swap a JWT (ID Token) for a opaque session token. That said, I really like having a JWT signed by an IDP which states the user's identity because if designed correctly you only need to trust one party IDP. For instance Google (the IDP) is the ideal party to identify a gmail email address since you already have to trust them for this. I created OpenPubkey to leverage JWTs, while minimizing and in some cases removing trust. OpenPubkey[0, 1] let's you turn JWTs bearer tokens into certificates. This lets you use digital signatures with ephemeral secrets. [0]: https://github.com/openpubkey/openpubkey https://github.com/openpubkey/openpubkey [1]: https://eprint.iacr.org/2023/296 https://eprint.iacr.org/2023/296
  • Aeolun 2y ago
    Aren’t JWT bearer tokens certificates already? Only the issuing server has the private keys, and the public keys are used to validate that server signed them?
    • magicalhippo 2y ago
      This is the other way around. It allows the user (token holder) to sign messages "using" the ID token. To be able to sign a message you not only need the ID token but also the private/signing key, and the corresponding public key is bound to the ID token (using the nonce field). Thus you can prove that not only did Google say you are you, but you possess the signing key associated with the ID token that says so. Thus I can be sure someone else didn't just steal your token in flight or from a log file for example.
    • EthanHeilman 2y ago
      Certificates use a signature to bind an identity to a public key. JWT bearer tokens use a signature to issue an identity, but that don't include the public key of that identity. The issuer has a public key, but the issuee does not. There are plenty of JWTs that are certificates: * proof-of-possession JWTs, * self-issued JWTs, etc...
• tobystic 2y ago
  Isn’t JWT plaintext? Just remember your security controls https://owasp.org/www-chapter-vancouver/assets/presentations/2020-01_Attacking_and_Securing_JWT.pdf https://owasp.org/www-chapter-vancouver/assets/presentations...
  • ozim 2y ago
    I still can put JWT in http only secure cookie.
• jameshart 2y ago
  Browser sessions are not the only authentication scenario. > absolutely no one who is not Google/Facebook needs to put up with the ensuing tradeoffs. If you process less than 10k requests per second, you’re not Google nor are you Facebook What's the magic property that flips when you pass 10K requests per second? Are we sure it's at 10K requests per second, not 8K? or 5K? In general, at that kind of scale I'd think JWTs would become less appealing - AWS operates on IAM for example. And why are Google and Facebook the best examples of companies who are operating at scale? There are different kinds of scale than just 'ad auctions per second'. I would imagine the access management concerns of, say, JP Morgan Chase are at least as complex and challenging to scale as those of Facebook.
  • EthanHeilman 2y ago
    I once operated a very low usage webservice that used JWT for auth. We got hit with a DDoS and it was trivial to mitigate by using AWS API gateway to drop HTTP requests that didn't contain a valid JWT for the IDPs we supported. Making authentication only require a signature verification at the edge (JWT) vs authentication middleware that needs to do a DB read (opaque), can be a life saver even if you have 10 requests a second most of the time.
    • etothepii 2y ago
      This is a great point. 10 requests per second is likely to be sufficient scale that you are noticeable to people that might want to attack you. The ability to validate the key before doing anything with it could be a huge time (and resource) saver on AWS.
      • logifail 2y ago
        > The ability to validate the key before doing anything with it [..] Q: What about the endpoint that's issuing the tokens?
        • EthanHeilman 2y ago
• conradludgate 2y ago
  A big problem not addressed when not using a signature based authorization scheme is that you need to hit your database for every access attempt. This makes you much more susceptible to ddos attacks. You need to be able to turn away malicious users as fast as possible. If you take the time to check a database first, that's a precious resource they can consume. "Add a cache!", you might say? What if they use random client id and client secret for every request, how do you cache against that?
  • candiddevmike 2y ago
    The client ID should be a primary key or some other indexed value, making those database hits fairly cheap. You'd also typically have some kind of rate limiting.
  • Y-bar 2y ago
    We use a rate-limiting rule in the existing firewall on the /auth endpoint. Our default is on five failed attempts in a five minute window gets you a one hour ban.
    • dclowd9901 2y ago
      How do you fingerprint the requests? IP address?
      • tebbers 2y ago
        The problem I had with IP address fingerprints is that we have a large number of customers all behind one hospital’s single IP address.
      • Y-bar 2y ago
        Two ways, default key is [IP address + User ID] we also have a fallback with a higher limit on [IP address] only when we expect lots of attempts from e.g. a VPN.
    • moduspol 2y ago
      The issue from parent comment is that it needs to be on every access request, not every login request.
• 5cott0 2y ago
  fine with me as long as you don't pronounce it "jay double-u tee"
  • chrisweekly 2y ago
    ok I'll bite; how do you pronounce it?
    • selectnull 2y ago
      jot https://datatracker.ietf.org/doc/html/rfc7519#section-1 https://datatracker.ietf.org/doc/html/rfc7519#section-1
      • chrisweekly 2y ago
        Awesome, thank you! > The suggested pronunciation of JWT is the same as the English word "jot". 1 syllable instead of 5 FTW
• rendall 2y ago
  While I could agree with the sentiment "consider using opaque auth tokens instead of JWTs in most use cases" I can't get behind the opinion-presented-as-factual-statement tone of the article. There are valid use cases to offload authentication to the client rather than verifying an opaque token with every request. One advantage is that community support for JWTs is large, but home-grown, ad-hoc opaque token solutions not so much. Another is that any claim at all can be stored in the JWT: IP address, user name, opaque token, whatever makes your app secure. While these same claims could be stored in a database, now you have extra overhead and maintenance dealing with them. I would like to see an open-source project from this author that uses his proposed solution.
  • angoragoats 2y ago
    IMHO the stateful opaque token approach is simple enough that it can (and often does) get baked into whatever language/framework you’re using to write your app. In addition, the very nature of session tokens is such that the logic for what the token actually means/represents lives in your app, on the server. So, that may be why we don’t see more “opaque session token” standards/libraries out there as an alternative to JWTs. But if you want an existing example, Devise for Rails [1] has been around a while. [1] https://github.com/heartcombo/devise https://github.com/heartcombo/devise
  • finack 2y ago
    What? Session tokens have been around for like 30 years now, and every web framework worth using has a rock-solid implementation; you haven't had to do it yourself since Full House was putting out new episodes.
    • rendall 2y ago
      Binding a session to client details like IP addresses and user agents requires enough fiddling that it's no longer the no brainer to use session tokens over JWTs that the article makes out, is my point.
      • angoragoats 2y ago
• bebop 2y ago
  I would add two pros of jwts (I guess oauth 2 and oidc more specifically) 1. It standardizes your auth system. While sessions auth is mostly implemented in the same way across systems, learning oauth and oidc gives you a standard across the industry. 2. Jwts give an easy path to make “front end” applications and api authentication work in the same way. This in theory reduces your security surface area as all of your authnz code can be shared across your offerings.
  • andoando 2y ago
    3. Easy to implement. 4. Dont need to hit db. 5. Can store some information with the claim which is very convenient
    • pests 2y ago
      How do you revoke tokens if a one gets leaked without hitting a db? How long are your users vulnerable to attack?
      • moomoo11 2y ago
        Use low TTL and put rate limits and other mechanisms in place?
        • jjice 2y ago
          I think you're right, but it seems like you get into a tricky territory that'll never be great (as everything with security has compromised). Too long is an issue for attacks, but convenient for users. Too short and you have to do an initial re-auth over and over again, partially defeating the benefits. Even if the TTL is short, there are plenty of ways to compromise a token and use it immediately in an automated system. If you're using JWTs, I'd lean shorter TTLs and embrace this as a potential concern. Not sure what the best re-auth frequency is though. I'd be really interested to see other's thoughts on that.
          • 2y ago
• adeptima 2y ago
  JWT is not a protocol but kind of a message format from my perspective. https://www.rfc-editor.org/rfc/rfc7519 https://www.rfc-editor.org/rfc/rfc7519 It can be signed with HMAC SHA-256 algorithm: {"typ":"JWT", "alg":"HS256"} Ripping off JWT from surrounding context is a road to hell. It's worth to study JWT in context of OIDC (OpenID Connect) IDP providers. You will quickly bump into buzzwords like client (RP), server (OP), PKCE, Token Exchange, mTLS and all kind of Implicit. Hybrid flows. My biggest regret I didn't go through JWT related RFCs and OpenID Connect specs earlier. [1]: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth https://openid.net/specs/openid-connect-core-1_0.html#CodeFl... 3.1. Authentication using the Authorization Code Flow [2]: https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth https://openid.net/specs/openid-connect-core-1_0.html#Implic... 3.2. Authentication using the Implicit Flow [3]: https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth https://openid.net/specs/openid-connect-core-1_0.html#Hybrid... 3.3. Authentication using the Hybrid Flow [4]: https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication https://openid.net/specs/openid-connect-core-1_0.html#Client... 9. Client Authentication [5]: https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens https://openid.net/specs/openid-connect-core-1_0.html#Refres... 12. Using Refresh Tokens [6]: https://openid.net/specs/openid-connect-discovery-1_0.html https://openid.net/specs/openid-connect-discovery-1_0.html OpenID Connect Discovery 1.0 incorporating errata set 1 [7]: https://www.rfc-editor.org/rfc/rfc7523.html https://www.rfc-editor.org/rfc/rfc7523.html JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [8]: https://www.rfc-editor.org/rfc/rfc7636.html https://www.rfc-editor.org/rfc/rfc7636.html Proof Key for Code Exchange by OAuth Public Clients [9]: https://www.rfc-editor.org/rfc/rfc8693.html https://www.rfc-editor.org/rfc/rfc8693.html OAuth 2.0 Token Exchange [10]: https://www.rfc-editor.org/rfc/rfc8628.html https://www.rfc-editor.org/rfc/rfc8628.html OAuth 2.0 Device Authorization Grant [11]: https://www.rfc-editor.org/rfc/rfc8705.html https://www.rfc-editor.org/rfc/rfc8705.html OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" If you dont have patience for RFCs and specs, just go play with open sources IDP or better start from OpenID Connect client and server library, and try to integrate it into your "hellohell" app ;) Very soon you will find out why developers keep building their own IDPs and how simple OpenID Connect can become a full time business Go back here and here http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... And reflect yourself Trust nobody
• rblatz 2y ago
  Oh man, he goes straight to stateful services as an alternative to JWTs. What an absolute nightmare, if JWTs are too hard stateful services are certainly more difficult.
  • tptacek 2y ago
    Stateful services meaning the default way every web framework has structured a web application since 2005?
    • vundercind 2y ago
      Longer, if we allow “web application” to mean “anything with a login, on the web”. All those popular forums, likely also stuff like yahoo mail, even gaming services (yes, browser-based game matchmaking services existed in the 90s, Microsoft ran one, among others) probably just because anything else would have been needlessly complicated and expensive.
      • finack 2y ago
        Amazing how using a session ID stored in a cookie was entirely possible in 2005, but is somehow out of our reach with today's hardware.
        • kbolino 2y ago
          A simple session cookie does not protect against CSRF. In 2005, session IDs were generated with low quality RNGs and too few bits making them easy to guess. OWASP happened for a reason.
        • rblatz 2y ago
          It’s not hard to stand up, managing state across sessions and versions of your app is hard. For example a site I use frequently the Morgan Stanley portal is stateful and you can only be logged in from a single device/tab at once. Most websites don’t need it, and it makes things harder to manage when rolling out new versions of your services. Life got significantly easier once I moved away from stateful services.
• lvlabguy 2y ago
  You should not use JWT if you have a single application in your organization. However, whenever you have multiple applications, you need some form of central authentication / authorization service. Otherwise, you would have to maintain auth databases in each application, each application will need to be logged-in separately, you won't be able to implement a simple "suspend a user's accounts after X unsuccessful auth attempt", you won't have a central auth log.
• zemo 2y ago
  External services use jwts pretty often, so if you have to handle jwts anyway, using jwts means that there's only one primitive, set of libraries, and concepts for your devs to know. "You don't need all of that!" sure but you probably already have it somewhere in your codebase and it's pretty universal. You also probably don't utilize every feature of http itself, that isn't a cogent argument against using http. JWTs are supported by a large number of tools, libraries, middleware appliances, etc; there's a huge ecosystem out there to support it. You also might delegate auth to a third party like Auth0 or FusionAuth so that you don't handle any PII, because all of the PII is handled by a vendor, and you only store application-specific data. "You want to implement logout" means a few things; in most apps you just ... have the client forget the token and you go about your day and it's fine. "but what about if a nefarious actor stole the token!!!" you might say, but hand-rolled session tokens have the same problem. "You want to turn off access for all users" is something you can do in http middleware; e.g., I have used middleware that do things like "only allow through requests that have jwts with the 'admin' role in their claims because we have turned off the system from users for downtime", and that works fine. (specifically I wrote a traefik plugin to do this in an afternoon). "You want to ban a single specific user really quickly" is a thing JWT won't do out of box.
  • tptacek 2y ago
    The problem isn't the mechanisms inside of JWT (though they are gross and worth avoiding on their own), it's the systems-level tradeoffs you have to make to use them idiomatically, particularly around refresh tokens and revocation. If you read this and think "this doesn't apply as long as I have to use JWTs for some service I rely on, anyways", you missed its point.
    • zemo 2y ago
      refreshing the refresh token is always a database hit, and in the case of using a third party like Auth0 or FusionAuth, you can invalidate refresh tokens at the individual and at the user level. Saying "the refresh token is the real token" as the article does is pretty misleading; the refresh token always goes to the same system that would accept the username/password, but the jwt itself gets carted around to other systems. So again, in the auth0/fusionauth case, the refresh token is sent to auth0/fusionauth, not your app, so even without any particular knowledge of what's going on, the application developer is forced to utilize them in different ways. There's a big assumption in this article that you're talking about a monolithic system where logins are processed by the same application that handles all requests. Even if you do prefer to structure your application as a monolith and avoid microservices, once you delegate auth to a third party or a system separate from your app, the bearer token versus refresh token thing starts to matter a lot. I think there's a cyclic thing that's been happening for years where people in the security community like to talk about how bad jwt is, but then not produce anything that meets application developers needs in a meaningful way. I spent years avoiding jwt and ultimately found avoiding jwts wasn't actually a good use of my time.
• firefoxd 2y ago
  Some people made the distinction here, jwt on the front end vs the micro services across the network. I've experienced more than once, issues where the auth service has bugs and the logged out session is still valid for a long time. Or an attacker that figured out the micro services blueprint and now had authed access to the entire network. Jwt is still useful between services, however the front end can do just fine with a session id that can be easily revoked.
• Galanwe 2y ago
  The article misses the point of JWT: it's dead simple to implement. I don't implement JWT because I fancy big data terascale technologies. I do it because it's mostly stateless, meaning it's very easy to mock locally, and easy to deploy. > You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request. No, you just remove the JWT from the local storage. Sure, the user could then relogin if he copied it, but if it's on his own will, why not. And if he got his JWT stolen before logout, bah anyway any token could have been stolen that way, whatever the tech. > You need to be able to block users entirely, so you check a “user active” flag in the database. You hit the database on each request. Right but that contradicts the whole premise of the article, being that you probably don't need fancy features. 99.9% of websites don't need to ban users _instantly_. If you have a fair JWT expiration, it's usually OK. I'd argue for the exact opposite of the article. If you want dead simple Auth, without fancy tech, just use JWT.
  • CiPHPerCoder 2y ago
    > The article misses the point of JWT: it's dead simple to implement. Implementing it securely, however, is far from dead simple. https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-library-if-you-absolutely-must/ https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l...
  • pjerem 2y ago
    > And if he got his JWT stolen before logout, bah anyway any token could have been stolen that way, whatever the tech. The thing is, with the good old "token in the database" method, logging out means deleting the token from the database so no, you can’t reuse a stolen token after a logout.
    • gkbrk 2y ago
      If the user can somehow get their token stolen from the browser, they can also get their username/password stolen from the browser.
      • 2y ago
• menthe 2y ago
  Everyone’s talking about how you MUST hit the database for revocations / invalidations, and how it may defeat the purpose. How is no one thinking of a mere pub-sub topic? Set the TTL on the topic to whatever your max JWT TTL is, make your applications subscribe to the beginning of the topic upon startup, problem solved. You need to load up the certificates from configuration to verify the signatures anyways, it doesn’t cost any more to load up a Kafka consumer writing to a tiny map.
  • deleted 2y ago
    [deleted]
  • akerl_ 2y ago
    So, basically a database where you store a replica in memory on every edge node.
    • ak217 2y ago
      Not really. A pub/sub bus cluster (or PaaS) is pretty different from a database.
      • akerl_ 2y ago
        I’m not talking about the pub sub cluster. If you have a pub sub cluster that you push revocation details into, and running servers subscribe to that feed and then track a rolling list of tokens that would otherwise still be active but have been revoked, you are effectively storing a revocation database on every edge node.
        • ak217 2y ago
          Again not really. If the pub/sub broker is persistent, you don't have to persist the revocation list on edge nodes. And just pointing out that it's a db in some loose sense of the word doesn't help with the actual challenge of organizing the flow of data reliably in a federated system (i.e. one that can't share a single database).
  • 2y ago
• meling 2y ago
  A former student of mine (Vera Yaseneva) redesigned our old auth architecture using jwts and I’m pretty happy with how it turned out. Maybe it is overkill for our simple autograder server, but it was fun getting it to work and I’m sure it is more secure than the old architecture which had many many flaws… it was a maintenance nightmare for years. After the redesign it has been a breeze. Here is the project https://github.com/quickfeed/quickfeed https://github.com/quickfeed/quickfeed The security arch is mainly in web/auth and web/interceptor packages if anyone is interested in learning from the code. It uses connectrpc, which has a nice interceptor arch. Happy to share Vera’s thesis report if anyone is interested…
  • hu3 2y ago
    Thank you for sharing! I took a look at the code. Looks clean. Please share her thesis. I'm interested.
    • meling 2y ago
      Here it is https://uis.brage.unit.no/uis-xmlui/bitstream/handle/11250/3022596/no.uis%3ainspera%3a92613534%3a6420238.pdf?sequence=1&isAllowed=y https://uis.brage.unit.no/uis-xmlui/bitstream/handle/11250/3...
      • hu3 2y ago
        Thank you! I'm looking to write a paper about a software I'm developing and this will help immensely since it's a fitting format.
• phendrenad2 2y ago
  I'm thankful every day I don't have to work on a team where JWTs are a valid solution, and nobody suggests them regardless. What a nightmare.
• dathinab 2y ago
  It's the wrong question. It's like asking what language should I use for programming a game? A common question, but of which the answer isn't a language choice. Instead it is that you approach the problem from the wrong direction. The more useful question is what framework/service/library do I use for handling that, and then you use whatever it uses. Which most times means use whatever your web framework provides (as the blog author concluded). The next question is what do you concretely hope to get from doing so and are there easier ways to get it (likely yes, and not some vague "but statles is better argument"). Then ask yourself how do you handle revocation? A question which is essential when using JWT and other stateless auth tokens (a answer of idk./I will think later about don't count. I don't can be a valid answer, but only very very rarely). I think it's not an understatement to say that the huge majority of custom JWT usage falls under harmful premature optimization. I wrote "custom" because sometimes you don't have a choice, e.g. you need to use OIDC for social login as the main form of AuthN & AuthZ and then already have some service (not just library) which fully handles OIDC/JWT including revocation for you (i.e. you don't validate the JWT stateless but ask the service every time). Through that approach (especially the later part) can have scaling limits but, eh, we are back at premature optimization ;)
• bakugo 2y ago
  The beauty of JWTs is that, if you have to ask "do I need JWTs?", you probably don't need JWTs.
• jonplackett 2y ago
  I’d like to hear a reply from someone at Supabase
• Aldipower 2y ago
  Fair enough, access token/refresh token pairs all have those issues described in the article. But why hating against JWTs (pronounced 'JOT' btw) in general? There are other stateless techniques making use of a JWT, which are very easy and secure to implement. For examples the single auth token approach, with maybe a 2 days expiry and a renew window if the user is active. For some scenarios this is perfectly fine, it is stateless and has no refresh token. User logs out by just deleting the token client side.
  • oxidant 2y ago
    Not saying you're wrong about the pronunciation, but "jot" is the suggested pronunciation, not the required one [0]. I used "jay double-you tee" for a long time and it doesn't bother me how people pronounce it. [0] https://datatracker.ietf.org/doc/html/rfc7519#section-1 https://datatracker.ietf.org/doc/html/rfc7519#section-1
• jupp0r 2y ago
  "Just use the normal session mechanism that comes with your web framework and that you were using before someone told you that Google uses jwt. It has stood the test of time and is probably fine." You don't need to be Facebook or Google to have more than one service in your infrastructure that needs to authenticate a user's existing session without forcing the user to log in again. Sharing the session across multiple services is its own distributed systems problem with numerous security implications to be aware of and bearer tokens might be a good alternative. If all you have is a single monolith web app that is the identity provider, makes all authentication decisions etc then yes, you don't need JWTs probably. There is a huge gap between that and being Google/Facebook. Apart from that, Google and Facebook don't even use JWTs between the browser and backends after the initial login but actually do have some sort of distributed session concept last time I checked.
  • _heimdall 2y ago
    This is a perfect example of "it depends" being the right answer. Should a project use sessions or JWTs? One isn't right or wrong, it all depends on the context of the project.
    • wokwokwok 2y ago
      I mean, to be fair, the article literally calls out a fairly reasonable checklist. Do you maintain a database of JWT session tokens for refresh and revoke? Do you have a real session that you load for every user every request anyway? If the answer is 'yes', then the answer to 'use JWT' isn't 'it depends'. It's no.
      • _heimdall 2y ago
        The author here seems to be arguing that you should effectively never use JWTs. That, in my opinion, is a mistake. JWTs have absolutely been over-hyped for the last 8-10 years, but they do have a use and you don't have to be at the scale of Google for it to be the right approach. Software isn't as simple as creating a checklist of a few basic categories and saying there is always a right or wrong answer. The answer should be "it depends" because there are many more factors at play when deciding something as fundamental as authentication and authorization.
• dudeinjapan 2y ago
  At TableCheck we use JWTs to enable user logins across several sub-apps, using an auth service we built in-house using Elixir. It’s a well-documented standard and we’ve never had an issue with them since launching. The supposed drawback that sessions must live for X minutes, is just not a problem in practice.
  • unscaled 2y ago
    I'm happy that it works for you, but you've just been lucky. Statistically speaking, JWT attacks are far more common in the wild than attacks against stateful tokens or other token formats (such as PASETO). The author of this essay even gave us a few example links[1][2][3]. Most users of JWT didn't go through a security incident, but a large enough percentage did. Far larger than you get with any other method. > It’s a well-documented standard I beg to differ at this point. Yes, the base standard itself is well-documented, but a safe way to use it is not. The JWS and JWE specify a great many algorithms without recommending which one of them is safest to use. Some of these algorithms (e.g. most types of RSA in the spec, AES-GCM with KW) are unsafe without extra precaution. The also doesn't mandate any claim (including the "exp" claim!) and does not mandate setting up key ids (which are necessary for key rotation). If you need to encrypt your token contents the standard also doesn't help you: It just gives examples of how you'd use an unauthenticated encrypted JWT[4] or a "sign-then-encrypt" JWT-in-JWE with RSAES-PKCS1-v1_5[5]. I cannot stress this enough, but BOTH examples in the standards are very obviously insecure. The first example has no signature or authentication at all (i.e. everybody can forge this "encrypted JWT"), while the second example uses a naive sign-then-encrypt scheme with the worst protocol for this type of scheme: RSA PKCS #1 v1.5, which is vulnerable to Bleichenbacher's attack[6]. If you want to use JWT securely (assuming you're ok with 5 minutes access tokens that cannot be revoked and you'll still be maintaining a database for refresh tokens), here is what you need to do to use it safely: 1. Use the HS256 algorithm for monoliths or services behind a single proxy or API pgateway. 2. If you want to distribute authentication across multiple services without making it possible for the various services to generate tokens, use Ed25519 (as per RFC 8037). Unfortunately, this is not supported by many libraries out there. ES256 is not terribly insecure for signing tokens, but there are enough caveats (such as its behavior when the RNG fails) that scare me. 3. Encrypted tokens should be avoided. If you really need them, they can only be used symmetricly (i.e. same way you'd use HS256). They should be done by embedding a JWE payload inside a JWS. The JWE should use alg="A256KW" and enc="AES_256_CBC_HMAC_SHA_512". 4. "exp", "iat" and "jti" claims are mandatory. "jti" should include a 64 byte random value encoded as base64url. 5. "sub", "aud" and "iss" claims are mandatory and should be verified. 6. A "scope" claim containing the tokens scope should be included and verified. 7. A "clid" or "azp" claim containing the Client ID should be included and verified, to identify the client. 8. All keys MUST have a "kid" specified, to allow rotation. Or you could just use PASETO v4.local/v4.public and get most of that work done within the library itself. [1] https://nvd.nist.gov/vuln/detail/CVE-2024-22513 https://nvd.nist.gov/vuln/detail/CVE-2024-22513 [2] https://www.howmanydayssinceajwtalgnonevuln.com/ https://www.howmanydayssinceajwtalgnonevuln.com/ [3] https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/critical-vulnerabilities-in-json-web-... [4] https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.1 https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.1 [5] https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.2 https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.2 [6] https://datatracker.ietf.org/doc/html/rfc8017#section-7.2 https://datatracker.ietf.org/doc/html/rfc8017#section-7.2
• tzahifadida 2y ago
  Probably a waste of time to answer due to the long thread here. But short answer: you can store tokens in a server session which will manage it for you. In case you need to refresh it, you are redirected to the idp and get a refreshed token which again stored inside the session. So you can handle any "microservice" scenario as was called here, not sure why micro is important... Also, it is a misconseption that the tokens,as it where, are not stored on the oidc providing service. How are you going to logout someone or invalidate or simply track devices? It is going to be stored somewhere and there is nothing wrong with it. It is matter of scale, if you are not facebook the addition is miniscule, especially with distributed cache. Again, a misconseption it is not being used already, e.g. on keycloak if you want HA you have to enable distributed cache. So really naive thinking that session is bad or jwt is bad. They are simply tools used by protocols and the only question is usually what do you prefer unless you get to the edge cases of performance which unless you are facebook, my face would look daughtful to begin with if you raise this argument.
  • Arch-TK 2y ago
    It's super common to see websites which don't properly invalidate sessions because they use JWTs without tracking them anywhere.
• YetAnotherNick 2y ago
  > In this setup the refresh token, not the authentication token, is the real session token Yes, and why is that a problem? It is the best of both worlds as the verification of access token is standardized and fast while refresh token could be used at the first call of the session. Yes, it could happen that the user is logged in for 5 more minutes if the user is in middle of session, but it's really such a edge case which most companies don't need to worry about.
• snowstormsun 2y ago
  One huge benefit of random session tokens is also that you can't include arbitrary metadata that is sent to the client. Decoding JWTs of web apps can give you a lot of suprises like the account email address or even password being stored inside them. For devs that don't know the difference between signing and encrypting JWTs are a footgun and even for those that do it can be confusing. The specifications are also a hard read. A handful of RFCs where you don't really know which one to lookup. JWT, JWK, JWE, JWA, WTF? It seems to do everything at once, signing and encryption, symmetric and asymmetric, and the format is always quite similar! On the other side, if you are able to avoid the many pitfalls, JWTs can be very useful in the right place when used properly. You could probably write an equally or more secure JSON based token format from scratch without that much effort by just keeping it simple and restrictive/opinionated, though.
  • tored 2y ago
    One huge benefit of using a non-randomized token is that you can verify that you created it.
• therealfiona 2y ago
  Here I was hoping someone was using the James Webb Telescope to do some crazy authentication process that I never could have imagined. Was hoping something like the Cloudflare lava lamp wall, but much slower.
• jurassic 2y ago
  The more confidently people make blanket pronouncements, the less you should believe them. There are a lot of use cases for OAuth2 and OIDC that are not covered by “just use a web session”. The real thing to push back on is the logout requirement. Everyone pretends they need this, when what almost everyone should do is just mandate appropriately short token lifetimes and revoke refresh tokens as needed.
  • Aeolun 2y ago
    > revoke refresh tokens as needed That’s a logout requirement?
    • jurassic 2y ago
      Not as I understand it. When I've seen this discussed, a "logout requirement" has usually meant some stakeholder thinks they need a way to prevent previously issued access tokens from being used even though the tokens are signed by the trusted authorization server and not expired (i.e. still valid). This requirement asks that you find a way to instantly shut off access even though the auth server has previously issued access tokens that should entitle the bearer to perform actions against protected resources until the token expires. Blocking refresh in the authorization server is trivial, but trying to implement the same on access tokens in the resource server at the point of use breaks the entire security model of JWT. It's unreliable, because now every resource server has to take on partial responsibility for authorization which multiplies opportunities for mistakes. As the OP points out, you need to keep track of some sort of block list and lose out on many of the benefits of JWT (i.e. a resource server being able to rely fully on claims in a signed token before allowing an action). When people show up with this kind of requirement, in my experience, it is often because they foolishly configured a client with a very long expiration on access tokens (e.g. ~months/years instead of ~minutes/hours). This creates a problem when some aspect of a user's access needs to change (e.g. disgruntled employee was fired, customer didn't pay their bill, etc). You can address this more easily by pairing a short access token lifetime with a long refresh token lifetime.
      • Aeolun 2y ago
• aranchelk 2y ago
  Even running in smaller environments: 1) You may not want your application servers having direct access to your auth service or auth database. You may not have the resources to control employee access to sensitive data when it’s shared across services. You may want to spend limited resources for security audits on the systems that contain the most sensitive data, and having them separated from everything else is helpful. 2) Depending on what 3rd party services you use it may not even be practical to have connectivity between auth and other services, and if you do, the latency may be bad enough that you wouldn’t want it to be blocking every request. This is especially compelling for hybrid environments, e.g. the 20 year old database in a colo with your user data, and a new service being built for you by consultants on a PaaS. 3) People act like revocation is such a nightmare, but you only need the auth service to sign invalidation tokens to be passed to the client-facing services, and those services only need to retain them for the max TTL of the auth tokens, after which they can be evicted. Yes, that’s something that could be motivated by having a massive environment like Google, it could also just be a way to keep costs down when you’re paying by the byte of storage or by the outbound request on some cloud. You could try to make the argument that storing invalidation data is just as bad as storing session data, but the key questions are “Where?” and “For how long?”, and then in some circumstances it breaks down very quickly. 4) You may not want sensitive user data stored in the jurisdictions where you want to host your apps. That’s not a big company problem, it’s dependent on the nature of the services you provide.
• greenthrow 2y ago
  This post is not very good. JWTs exist for good reasons. They may not fit your needs, and if not, don't use them. But they exist to allow Entity A to tell Entities B through Z that A had authenticated the user and authorizes them without needing to make API calls, and they serve that purpose well.
• egberts1 2y ago
  Wrote a brief recap of "permission" and "login" for authentication from my work in JavaScript malwares. It was a rush outline article with citations. Large binning, salting of hash, and revocatable are my criteria. Some toolkits that went out the window firstly are: * auth0, * Fusion auth, and * Gluu. So, some of the basic criteria are: * User and password login instead of plain HTTP session cookies. * HTTP-only over TLS v1.2+ (secured HTTP, HTTPS) * ECDSA 1K or better * SameSite [1] * __Host prefix [1] * preload HTTP Strict-Transport-Security header line [2] * Bearer token supplied by API clients * Don’t listen on port 80… like ever. Or revoke token if over non-port 443. * DO NOT use JWT [3] * DO NOT use CORS [4] Hope the citations help more. JWT, not recommended, IMHO. https://egbert.net/blog/articles/authentication-for-api.html https://egbert.net/blog/articles/authentication-for-api.html
  • banish-m4 2y ago
    Do not outsource auth to a third-party. The Okta failure was bad enough.
• flexterra 2y ago
  no
• thayne 2y ago
  So first of all, JWT is part of the OpenID Connect specification. So if you want to be either a service provider or identity provider for OIDC, you need to use JWTs as an authentication token in at least some cases. Secondly, you don't have to hit the database on every request. Unless you have really strict security requirements, you can have a short expiration time on the jwt with a refresh mechanism, and then you only have to check the database say once every 5 minutes. Related to the above point, the database you check for the "session" token isn't necessarily the same as the one used for other data used in the request, even if you are much smaller than Google or Facebook. It might not even ve the same type of database. Finally, even if it makes sense to use a "traditional" session cookie for brower sessions, that probably doesn't make sense for an external API, where the client may not have persistent cookies at all, and there may not really be a concept of a session. So as was mentioned in another comment, I think the answer to the title question is a solid "it depends".
• Savageman 2y ago
  Maybe it's irrelevant but for JWT to be passed as a Bearer in the header Authentication header, it needs to be accessible from the browser? Aren't httpOnly cookie safer in this regard? Or do we see set the JWT in the cookie too?
  • 4star3star 2y ago
    Some people advocate for a secure httpOnly session cookie for the client, letting the server hold onto the JWT and manage refresh. This gets you the benefit of server to server access via the token as well as the "session" concept and the warm fuzzy feeling of knowing the client doesn't hold the token.
    • Savageman 2y ago
      Sounds a nice compromise, thanks
• osigurdson 2y ago
  What if you want to use AzureAD or Auth0? Aren't those services completely built around jwts?
  • hnbad 2y ago
    AzureAD is built around OIDC. Yes, the tokens use JWT but that can be treated as an implementation detail. The mechanism here is OIDC, not specifically JWT. The tokens can be treated as mostly opaque. Also in that case you aren't using JWTs for authentication, AzureAD is and you're integrating with it. And as I said, you're integrating with it via OIDC.
    • whizzter 2y ago
      opaque apart from that you should verify that the JWT token is issued by a trusted party and fulfills claims that your service requires? :P (Unless those parts are handled by a library you've configured to check this).
      • hnbad 2y ago
        The point is that when logging in with AzureAD your app needs to talk to AzureAD using OIDC but JWT is an implementation detail of that specifically and there's no reason this means you need to or should be using JWT throughout the rest of your architecture. If you're using AzureAD for IAM, you're not "using JWT for authentication tokens", you're using AzureAD. This isn't what the article is about. The article is about building your own services that generate and process JWTs. And yeah, if you use an OIDC API you likely use an OIDC library instead of rolling your own. So as far as your own code is concerned the token is entirely opaque.
    • osigurdson 2y ago
      Wouldn't an app normally at least need to look at some claims in the jwt (email for example)? Otherwise, how do you identify the user?
      • hnbad 2y ago
• drivebycomment 2y ago
  The main claim of the article is: > jwt as authentication tokens are constructed for Google/Facebook scale environments, and absolutely no one who is not Google/Facebook needs to put up with the ensuing tradeoffs. The first sentence is factually incorrect. Google doesn't use JWT for most of its own authentication. Try analyzing their traffic - web and mobile apps - and you'll find that none of their 1st party applications / web use JWT. They do use JWT for OIDC, for third parties, which makes sense since with OIDC/JWT, third party sites can verify the token without talking to Google using a standard. This is largely similar for Facebook. JWT RFC starts with: > JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. Notice "between two parties". Of course, nothing stops from a single party to use JWT, but claiming JWT was invented for "Google/Facebook scale environments" implying they are using it for their 1st party authentication is just factually wrong. JWT was always meant to be an information transport between two separate parties, like OIDC. "Ensuing tradeoffs" here is essentially about stateless authentication vs stateful authentication, and even there, this "absolutely no one" is simply incorrect. There are many scenarios where stateless authentication is sufficient, even for the authentication for a single party (let alone between two separate parties). Not all applications and use cases require the security properties of stateful authentication - a sufficiently short expiration would provide sufficient security in many cases, making the loss of any security worth it for the added benefit of simplicity and reliability with the stateless authentication. Now with more nitpick: The article claims, since "denylist" would require a database read, it's equivalent to stateful authentication. Theoretically that's true. In practice, denylist has some nice properties, that makes it worthwhile if server-side logout is the only missing feature you need from JWT. Denylist is often very small - if most users of your application or service do not explicitly log out, the number of denylist will remain very small. With the expiration, the size can not grow indefinitely either. Thus, the denylist you maintain can be much smaller than the record of all stateful authentication - which makes it cheaper/easier to replicate / cache across your systems than the full authentication records. So "denylist" is definitely a legitimate design option, with slightly different trade-offs than a full stateful authentication. --- If I re-interpret the main claim of the article in the way I think would make sense, it would be: services should prefer stateful authentication, and the cost of stateful authentication is lower than people imagine it to be. That I can be behind 100%. As written, the article is at best some big exaggeration with incorrect details and hidden assumptions.
• deleted 2y ago
  [deleted]
• teliskr 2y ago
  Some people get entirely too dogmatic about their “XYZ is wrong, don’t do it!” beliefs. At the time I implemented JWT in our system, many years ago; it was the most straightforward way to solve the problems that I had. I read about the pitfalls and have yet to experience any of them. So in short.. “no regrats” from this heathen.
  • hot_gril 2y ago
    Isn't JWT's main benefit being a standard interchange format? 3 parts: header, payload containing user info, signature from whatever authenticated the user. Can be encoded for URLs and decoded to JSON. Seems pretty innocent to me.
• apatheticonion 2y ago
  I typically use a service like AWS cognito (using their built-in hosted UI) to handle authentication for my apps. That gives me MFA, Google/Facebook login, email verification, etc for free and has a generous free tier. I have a template that's backed by terraform and the authentication client is in lambda so the whole thing is serverless, self-contained and practically free. So I just run "terraform apply" and I have scalable auth for my new service. https://github.com/alshdavid/template-cognito https://github.com/alshdavid/template-cognito (only 1 dependency on AWS, everything else is stdlib) If any service I create is lucky enough to break out of the free-tier and cost is an issue, then I can just move to another OAuth2/OIDC provider. The auth mechanism Cognito uses is just a specification meaning I am not coupled to any one service provider (though the user accounts themselves are). Cognito, Auth0, IdentifyServer, or whatever - I can migrate if cost becomes a problem. The big issue with JWTs are that, if lost, they give permissions to attackers without revocability. For this reason, I keep auth-tokens short lived and refresh them often. Refresh-tokens are revocable and live for a few days. This means that a lost auth-token is only harmful for a few minutes while a lost refresh token is only harmful until revoked or expired. Tokens are stored as path-specific http-only cookies so the only vector for attack is if a user physically opens devtools and gives an attacker the token - or if the attacker has access to the computer (physically or via a malicious terminal script). High risk operations (e.g. delete account, delete content, anything high risk) requires "step-up" authentication - so a user is asked to re-authenticate in those cases. Overall, when you consider that rolling your own authentication comes with the liability associated with holding user data (companies must announce a breach to users, etc) - if a service provider like Cognito is compromised, you won't be liable or the only one affected. JWTs have security concerns, but on balance, when used with third party provider, a sensible configuration and considering the risk of rolling your own - they are fine.
• pan69 2y ago
  My take on it is; JWTs are good for server to server communication (short lived at ~5 minutes). Sessions are for clients (browsers, apps, anything controlled by a person) to communicate with a server/api.
• grepLeigh 2y ago
  JWT make the most sense for zero trust machine to machine authentication, where you might also want to authorize certain verbs/actions/roles after confirming the requester's identity. For example, I use a JWT-based authentication and role-based authorization scheme for a fleet of Raspberry Pis communicating with each other on a LAN or network overlay, and also with a multi-tenant API on a public internet-facing VM. The Pis manage 3D print jobs. For users/people/apps, I usually rely on session-based authentication. Sometimes I need light RBAC at this layer too (users, teams, admins, etc).
• 4star3star 2y ago
  I'm unconvinced of the author's actual understanding of common JWT usage. Suppose you use Azure. You may have one or more app registrations with defined roles as well as apis exposed within the Azure config. It's convenient to acquire an access token that can be sent to various apis, each of which can accept the token without having to worry about session state or really anything to do with authentication other than validating the token's legitimacy. If I wanted to roll my own security, maybe JWT isn't how I would choose to do it, but I definitely don't want to do that.
• jongjong 2y ago
  JWT is the simplest and most versatile authentication mechanism we have. I have no idea why there is so much gaslighting about them. People keep pointing to implementation complexity, yet there exist proven, heavily used implementations for almost every language and engine imaginable. That issue is an issue of the past. It is doubly ironic that people try to point to 'complexity' as an argument against them when most of them are addicted to over-engineered software stacks... JWTs are amazingly simple when compared to most other concepts in this industry. The aversion towards JWT is weird. I used to think it's probably because some people got burned badly due to past implementation flaws and still hold a grudge... But the sheer persistence of the any-JWT movement leads me to think there may be an agenda behind it. How could anyone possibly claim that keeping track of sessions on the back end and passing around session IDs is superior? It's way more expensive on the database/datastore, adds latency, it's hard to scale, you often end up with stale sessions because it's not fail-safe (e.g. how to clean up previously active sessions when a worker crashes? Especially if you have multiple workers.). Session IDs are MUCH more work.
  • angoragoats 2y ago
    I disagree strongly. And I'm wondering if you can comment on the points raised in the article regarding how you handle logging out with JWTs? It seems you've got two options: 1. Don't implement logging out 2. Implement logging out by keeping your JWT expiration time short (which is probably good practice anyway) and using a refresh token to issue new JWTs periodically. With the latter, you've gone right back to server side session storage. So JWTs are just an added (unnecessary, for most apps) layer of complexity on top. Again, all of this was discussed in the article.
    • jongjong 2y ago
      With #2, you don't need a 'refresh token', the JWT itself is the refresh token, you can just sign a new one some time before the old one is set to expire. You don't need to store a separate session object on the back end, that's the whole point, just have the valid JWT token attached to the connection or request; if the user has an existing valid JWT attached to their socket or request, you can just use that one as the basis to create and sign a new one with the same data but a new expiry date. I find this works really well with stateful connections like WebSockets (especially since each frame has little overheads in terms of headers). You can re-issue JWTs in real time periodically (e.g.) with short 10 minute expiries or you can make the user request a new one periodically as well. There are pros and cons to either approach though the second one is more common. So to summarize, JWTs save you from having to store and maintain a session object. You just don't need one. A blacklist or ban list is a lot easier to manage than session data, only a small number of users will be blacklisted. You could also add an isBanned field to the user's account object itself. No need to maintain a separate 'session'. For log out, you just make the client remove their JWT from wherever they have it stored; e.g. memory, localStorage or sessionStorage. Once all valid signed JWTs have been physically deleted from wherever they were held, the user is logged out. Even if you consider edge cases; e.g. If an attacker managed to grab hold of a user's JWT just before the user logged out; it begs the question, how did the attacker manage to do that? An XSS vulnerability in your front end? Well, once resolved, you'd probably want to invalidate all your previously issued JWT tokens (for all users) by changing your auth signing key on the back end... Just to be safe right? It's kind of neat that you can invalidate all previously issued JWT just by changing the signing key. It's instant and doesn't cost any resources unlike deleting large numbers of session objects from a datastore. I can't think of any situation where you'd urgently want to invalidate a single JWT/session that couldn't be handled better by adding a single isBanned field to an account object or via some kind of IP blacklist. If you're using sessions with session IDs and the user is banned, you'd want to add some kind of flag to their account object itself right? Not just the session... With JWTs, you just need this flag to exist in 1 place, not 2.
• deleted 2y ago
  [deleted]
• deleted 2y ago
  [deleted]
• oppositelock 2y ago
  JWT's are perfectly fine if you don't care about session revocation and their simplicity is an asset. They're easy to work with and lots of library code is available in pretty much any language. The validation mistakes of the past have at this point been rectified. Not needing a DB connection to verify means you don't need to plumb a DB credentials or identity based auth into your service - simple. Being able to decode it to see its contents really aids debugging, you don't need to look in the DB - simple. If you have a lot of individual services which share the same auth system, you can manage logins into multiple apps and API's really easily. That article seems to dislike JWT's, but they're just a tool. You can use them in a simple way that's good enough for you, or you can overengineer a JWT based authentication mechanism, in which case they're terrible. Whether or not to use them doesn't really depend on their nature, but rather, your approach.
  • fefe23 2y ago
    You are confusing simplicity (it's easy to understand and straightforward to implement safely) with convenience (I have zero understanding of how it works and couldn't implement it securely if my life depended on it, but someone already wrote a library and I'm just going to pretend all risk is taken care of when I use it).
    • oppositelock 2y ago
      Am I confusing them? It's not difficult to implement JWT's, the concept is simple, however, with authentication code, the devil is in the details, and that's true for any approach, whether it's JWT's, or opaque API tokens, whatever. There are many, many ways to make a mistake which allows a bypass. Simple concepts can have complex implementations. A JWT is simply a bit of JSON that's been signed by someone that you trust. There are many ways to get that wrong! Convenience, when it comes to auth, is also usually the best path, and you need to be careful to use well known and well tested libraries.
• jongjong 2y ago
  > Now, let’s assume you are not Google. Check which of these apply to you: > You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request. A JWT is like a keycard. If a hotel gives you a keycard to access your room, the card itself holds the credentials which give you access to the room. That's the core principle behind JWT. If you want to ban someone due to malicious conduct, then you need some kind of ban mechanism but this is a concern of spam prevention and attack mitigation. You need such mechanism regardless of what session mechanism you use. With JWT, you may need to do 1 lookup to check the account object (you can keep an isBanned flag on the account itself), with regular session IDs, you need 2 lookups (1 for the account object and 1 for the session object). JWT still saves you 1 lookup... Also, if gives you a lot of flexibility. For example, you may be able to keep a 'blacklist' in-memory and separate for each worker (that may be appropriate for certain use cases); you're not necessarily forced to hit a datastore or database as claimed. Banning and spam prevention should be seen as a separate concern. Also, at small scale, there are scenarios where you don't even need a blacklist. Maybe your app is being served on an internal private network or maybe it's public but it's not so critical that you can't wait for 10 minutes or 1 hour (or whatever) for the JWT to expire for the ban to take effect. I mean, with the physical hotel scenario as an example; your keycard remains active until it expires. There are many such scenarios in the software industry where a ban doesn't need to take effect immediately. When you need instant blocking for DDoS protection (where immediacy of the ban/block really matters), you typically rely on IPs, not specific account or session IDs. > You need to be able to block users entirely, so you check a “user active” flag in the database. You hit the database on each request. As above. > You need additional relationships between the user object and other objects in the database. You hit the database on each request. The number of times you hit the database (and the reason for each lookup) matters and it's important not to mix up different concerns. > Your service does anything at all with data in the database. You hit the database on each request. This is just a variation which has the same flaws as previous arguments. The author claims that Session IDs provide: > Greatly reduced complexity. No need to manage a secure jwt signing/authentication key You can provide the auth key as an environment variable when you launch the service. This is well supported in all environments at any scale including Docker, Kubernetes... anyway, 99% of services rely on various secrets like API keys so you need to pass secrets as env vars anyway, what's the issue with having just one more env var to hold the JWT signing auth key? There is no added complexity there as the mechanism for handling such secrets already exists in most applications. It's rare to see an application which doesn't have secret API keys... You need them for payments (e.g. Stripe API), for database API services (e.g. MongoDB cloud), Amazon AWS, etc... On the other hand, managing sessions on the back end requires weird workarounds like setting and constantly refreshing expiries on the session keys or running complex cleanup cron jobs because you end up with complicated situations where your worker might crash and leave behind stale sessions. Session IDs are much more complicated. Not to mention that session lookups becomes a single point of failure and can become a bottleneck for your application as you get more users. It's really difficult to scale well. You're going to run a Redis cluster just to manage sessions? Hello LATENCY!!! Welcome DDoS headache!!! Did anyone say backpressure issues??? How are you going to clean up stale sessions when a worker crashes? Good luck. I hope you're billing for your development work by the hour, coz you're gonna need a lot of those! I hope your health insurer covers Panadol! Don't be surprised when GlaxoSmithKline opens up a new factory next to your office.
• menacingly 2y ago
  We don't use JWTs because we think we're google scale, we use them because they're kinda cool. Cheap, stateless auth across services is really handy. If I rolled my own solution, it would just look like a shitty jwt. There are definitely arguments to me made against ridiculous over-engineering, modern web dev has taken the problems of 1% of engineers and made them problems for 100% of engineers, but I think this is a bit of a silly one to focus on
  • j16sdiz 2y ago
    We don't use JWT because we are NOT google scale. A centralized database for sessions, and we can extend/revoke any token anytime.
    • rezonant 2y ago
      What's interesting about this argument is that nothing is stopping you from doing this same thing using JWTs. Just generate your token and store it as a claim in the JWT. You can check the revocation of the stored token without even validating that the token is genuine, if that is fortuitous. What this buys you is the ability to attach clear text information with the token, and, if you are doing asymmetric validation, the ability to validate both the security credential and the included plaintext information in an untrusted (client side) setting.
    • menacingly 2y ago
      I actually think the revocation argument is the over-engineering case here. I'd argue that people who need to avoid hitting their database on every request outnumber people who need sub-minute revocation
    • hot_gril 2y ago
      I don't see how this solution means you cannot use JWTs.
• jankboy 2y ago
  Yes if the JWT token can only become invalid based on an expiration time. You can add the expiration time in the token and check it during authentication. No if the token can become invalid due to other reasons because lets say the user deletes the token because it got leaked. But since you have no way of invalidating the token other than changing the encryption key, you can't selectively invalidate that one token.
• rezonant 2y ago
  Since JWTs can't handle revocation on their own, the main benefit (other than the ability to do validation without a central authority) of JWTs over opaque tokens is the ability to embed data that an untrusted holder (ie client) can make use of. For example, attach the display name of the user and their avatar profile, so that even after the token expires the application can represent to the user who the token is (could be used for example to show a "Sign back in, Tom" view). This makes a Switch User feature very elegant to implement: the application need only store the signed authentication tokens, and those tokens are self describing. Additionally, when using asymmetric validation, you can rely on JWTs as licenses: Your software can restrict offline features based on a locally stored token, simply by checking that the JWT was signed by the authority. In tandem with the ability to store metadata, your app (with code held by the untrusted user) can use the token to determine the user's license features without requiring an always on connection. (Obviously patching out the license checks is another matter) These features can be layered on top of opaque tokens, but since a JWT has all the benefits of an opaque token (store the opaque token as a claim just like the rest of the metadata), it's actually a complete package that does it all without needing to roll it yourself.
  • cryptonector 2y ago
    > Since JWTs can't handle revocation [...] Revocation is just hard. Even PKI's CRLs/OCSP don't have a subscription mechanism by which an end-point can get revocations of some small set of certificates. Even a public feed of revocations could be problematic if you're going to terminate employees because the timing has to be perfect: too early and you're tipping off employees, too late and you're allowing disgruntled employees run malware on your systems and network. In practice being late to revoke access is generally accepted as acceptable as long as it's not too late.
• shermantanktop 2y ago
  So what’s “Facebook scale”? Is there an edge TPS number? Number of discrete major services? If you are consistently doing 10TPS on 3 services, sure. But many systems are bigger than that. Everyone wants to be big. You can either frontload those problems, and risk drowning in irrelevant complexity, or defer them. The problem with deferring is that switching lanes appears like it will be expensive and time consuming. The secret is that if you solve actual problems, rather than dreams and future hopes, the answers are almost always obvious. The work may be painful and people may be angry, but the rationale will be clear.
• abalone 2y ago
  I see a flaw in the argument. He shifted from saying you'd use a 5 minute access token timeout to querying the DB on every request. There can actually be a big difference between those two scenarios. Some web APIs can be bursty. Even caching credentials for 5 minutes could take significant load off the DB.
  • rezonant 2y ago
    I'm pro JWT, but reducing load on the DB itself isn't a massive argument in favor of JWTs, because an opaque token solution can simply cache the result of a revocation check at whatever time interval is comfortable for the use case of the token. So assuming the API has access to a cache layer, there isn't a difference there. If there is no cache layer, there probably should be. In a hyperscaler situation things are different, but we should avoid treating that as the norm.
• ahasani 2y ago
  While mignt not agreeing with all the reasons mentioned, verifying signature for every resource access is cpu intensive (your commercial compute provider would love you though). Comparing session id to a map is cheap. For me jwt to authenticate and random session token for resource access, problem solved
• crunchybeeftaco 2y ago
  I’m confused though. JWT isn’t hard to configure. Why not just use it?
  • ruszki 2y ago
    I don’t understand this article and thread either. Using OpenID is not rocket science. You can start to use it in matter of minutes. The question should be rather why you should care at all to use anything else at this point.
• begueradj 2y ago
  The article completely ignores single page applications where these JWT can be needed a lot.
• redwoolf 2y ago
  I keep reading criticism of JWTs that involves impersonation or replay attacks. With JWT (or non JWT bearer tokens) you use a refresh token. It seems to me that if an attacker gets a JWT they also have the refresh token. So how are JWTs inherently more insecure than other authentication methods? Almost all data passed over the wire nowadays is TLS encrypted. In my projects, we have used encrypted JWTs and it seems to me a fine solution. Log out can be implemented in a user facing client by deleting the JWT and refresh token. Given a short enough expiration time, this is sufficient for most use cases involving user facing applications. Isn’t it? Generally, at least in the domains of the applications I’ve worked on, users only intend to log out of their current application when logging out. Meaning if they are signed in on their phone and on their desktop browser, when they sign out in the browser they don’t intend to also log out of their phone application. The only downside I see is that if you want to log out of all sessions it is impossible to implement without maintaining session state in the server.
  • mikeryan 2y ago
    It seems to me that if an attacker gets a JWT they also have the refresh token. No they don’t. JWTs can be used with third party services that should never see a refresh token. Those are the requests that should be presumed vulnerable.
    • redwoolf 2y ago
      I’ve not come across such a use case as I’ve only ever written applications where we own both the service and the clients. Thanks for the explanation.
  • cryptonector 2y ago
    > So how are JWTs inherently more insecure than other authentication methods? Almost all data passed over the wire nowadays is TLS encrypted. JWT's security -and that of all bearer token systems- depends utterly on the use of TLS. The security of JWT used correctly is comparable to that of Kerberos or PKI. There are some things to look out for, like that it's way way too easy to write implementations that fail open (e.g., you don't recognized a signature algorithm so you don't validate the signature but also fail to fail), but other than that there's nothing particularly bad about JWT. > Log out can be implemented in a user facing client by deleting the JWT and refresh token. Logout has to be implemented either by letting time pass w/o re-authenticating (i.e., let the session expire) or telling the server that you're logging out. You can login again, even with the same token as before (IFF it's not expired yet). There is no reason to have to "burn" a token, and that would add a significant amount of complexity akin to revocation. > The only downside I see is that if you want to log out of all sessions it is impossible to implement without maintaining session state in the server. Sessions imply session state. What you probably meant is that if you want to revoke access then you need a revocation system, and that effectively bolts on extra state on your servers (and a pub/sub system). Generally no one wants that headache.
• unscaled 2y ago
  Here's the thing: neither Google, nor Facebook is using JWT for their access or refresh tokens. The only place they use JWT, as far as I know, is for the ID Token in their Open ID Connect Flow, since this is a mandatory (and terribly misguided) part of the spec. I keep seeing the idea that JWT was designed for Google or Facebook scale being repeated over and over, but the reality is that neither company uses it. Last time I checked, both used rather short access and refresh tokens and it appears that at least the refresh token (if not both) is stateful. Implementing stateful tokens on a global scale and sharing them across hundreds of service is HARD, but it's easier when you are Google or Facebook, and you've got enough resources to throw at this trouble. And if you do need to implement a stateful token, you've got every reason to choose your own format. Your applications are using your own authentication libraries and infrastructure (e.g. API gateways), so you don't have to worry about complicating their life with a non-standard format. The upside for using your own stateless format is that you avoid all the design issues with JWT (alg=none, algorithm confusion, questionable support for outdated algorithms from the 1970s) and you can design a far more compact format that takes a fraction of the size of JWT[1]. There's a reason JWT got popular with scrappy startups, enterprises hobby projects and Udemy/Medium tutorial authors: they're very easy to spin up and library support is everywhere. I don't mean to say JWT is the right choice for any of these uses — it probably isn't. But it's the easy choice, the worse-is-better solution. The worse solution needs only be better in one respect to win: it should be easier to implement, copy and spread. In the end of the day, JWT is not a good solution for either Google-scale companies or small startups. But it's the small startups that usually lack the resources and awareness to adopt another solution. [1] https://fly.io/blog/api-tokens-a-tedious-survey/#protobuf https://fly.io/blog/api-tokens-a-tedious-survey/#protobuf
• Joel_Mckay 2y ago
  In general, a breadcrumb or cookie with symmetrically encrypted session UUID, epoch time, IP, and transaction counter is wise. You should also permute the servers hash salt with date daily to boot session campers. If for some unknown reason the recovered client transaction counter losses its expected position, than you know someone has tampered with the session, and or stolen your clients session token. Donate to the FOSS project of your choice if you find this useful. =3
• devdiary 2y ago
  Start with usual session based authentication. Keep it until you see the absolute need to move to JWT. And make sure you understand JWT and "invalidating JWT" before using it - https://github.com/gitcommitshow/auth-jwt?tab=readme-ov-file#invalidating-jwt https://github.com/gitcommitshow/auth-jwt?tab=readme-ov-file...
• nine_k 2y ago
  Yes. I mean, no; you should use macaroons [1] instead, which are better than JWTs but are built on similar ideas. [1]: https://fly.io/blog/macaroons-escalated-quickly/ https://fly.io/blog/macaroons-escalated-quickly/
• axelv 2y ago
  What about jwt's in a session cookie? I think the whole story needs more nuance. JWT's have many purposes.
• alex_young 2y ago
  “No.” Whenever I see such a simple answer to a complex question, I know it’s probably an oversimplification. The real answer is a solid “it depends on what you want to achieve.” Say you handle invalidation by maintaining a cached table of revoked tokens. Is this table larger or smaller than the table of all users? Perhaps you would like to embed some RBAC info in the token. Is validating both the token and it’s absence from your revocation table more efficient than looking up all of the other information? Perhaps you need to do this on a distributed basis. Is the overhead of maintaining such a table more or less than making all the DB calls and creating a central choke point in your architecture?
• DeathArrow 2y ago
  I don't get why he is pretty sure everybody has only one database which stores user data and application data. At work we have user data in Keycloack and application data in at least 20 different databases.
• hansoolo 2y ago
  Off topic: the domain name is great!
• 1penny42cents 2y ago
  It’s a great analysis but I think it’s too either-or. If you have a monolith anyways then yes, why use a distributed systems solution like JWT? Completely agree. But if you already have an auth service, making it optional for the majority of requests is a distributed systems win. Even if you need to implement forced logout or some other features which require hitting the auth database, they can be optional requests. If the auth service is available, you get better security, otherwise the services can decide whether to continue or not. This is better than your entire app going down or slowing down with the auth service. Though the refresh token bit is still a challenge, it’s a smaller one than a hard dependency on the auth service on every request. Again, if your auth service is just a component in your monolith, the author is completely right. It’s context-specific.
• vldb7 2y ago
  I don’t think it is either-or type of choice. A lot, if not all arguments against that use of JWT disappear if you’re ok with compromise solution: user management actions will take time to propagate. If JWT lifetime is 5 mins, it means that all actions like logout, deactivating account etc will take 5 mins to finalize - and you’d be hitting the database exactly once per 5 mins for the purpose of checking if user is still active, refresh token is not barred by log out etc.
• koliber 2y ago
  Nothing wrong with JWT bearer tokens as a technology. However, too many times they're implemented incorrectly or without forethought. I've seen a few teams who used the bearer token, set the age really high, and never bothered to implement a refresh mechanism. Fast forward a few months and someone says it is not possible to log someone out of our service.
• winternewt 2y ago
  Without JWT, how do you support log in using third party identity providers like Office 365, Google or Facebook?
• ChicagoDave 2y ago
  The JWT has some extra fluff for the client, but only the Bearer token is used for secure communication. And every call to an API validates the Bearer token with an identity service. There is no automatic security because you have a token. That Bearer token (not the JWT) must clearly be validated and also validated with whatever functionality (Claims) is potentially being requested. The meta data in the JWT is sort of a short cut to let the front-end make assumptions, but it has no bearing on the actual capabilities. Only a valid Bearer token can determine if a call is secure (authenticated) and has the correct permissions (authorized). So, you don't need a JWT, but without it, you're still going to need a way to send mundane meta data back to the front-end. This used to be (and still can be) a separate call for "config" or "permissions" data, but why bother. Just create claims in your identity server, mark your API's with those claims and token validation, and you're in great shape.
  • gizzlon 2y ago
    Changing the JWT because the frontend suddenly requires "middle name" is a PITA. Also, the JWT can become become large.
    • ChicagoDave 2y ago
      That’s not meta data. Claims are usually user scopes based on actor definitions. Some users can view, some can edit, some are admins. Claims are often, but not always, about resources.
• datarez 2y ago
  The main advantage of jwt is that is stateless, so it reduces load on database and or caching layer when checking user session. Alongside being able to share the public key to verify the token across different services
• tracker1 2y ago
  Authentication is often the first thing I want to break out of the application and backend anyway. Good password hashing is expensive... Why should an entire application have to go down when your login is being DDoSed? More so, A revocation list on something like Redis can expire with a token and a lot less expensive than an rdbms lookup with joins. Not too mention, why add extra load with extra DB calls in the first place? You don't have to be Google scale to want to separate logins from the main service. And that's just for starters.
• mstaoru 2y ago
  JWTs are rather convenient for API access, especially for APIs that are hit at high req/s rate, as they allow to decouple auth check and actual request processing. In more complicated cases you can use JWT subject for some simple preflight ACL checks as well.
• PaulHoule 2y ago
  Here is a quote from a comment in that article: I feel like this subject comes up every couple of months with another iteration of why people think JWTs are bad. The regularity which with this subject comes up makes me think of how Triplebyte used to pay off bloggers in the day to write posts with the title “hiring is broken”. I don’t have the proof but I am picking up a bad smell here. Gotta be yet another of the vendors which is selling some authentication system that they host. I remember trying to promote an open source user management system in the early 2000s and nobody cared until they added killer feature “our service will get shut down when we get acquired” which somehow drew the pointy haired boss like a moth to a flame.
• stanac 2y ago
  1. You can set JWT as cookie value, I think author is describing OAuth 2 problems, not JWT problems. Interestingly JWT is not mentioned in OAuth 2 spec [0]. 2. JWT doesn't have to contain user details, it can be a simple reference token used for introspection [1]. This approach removes problems with invalidation and logout since identity service should store invalidated tokens. 3. JWT can contain refresh token id (or hash) and check for invalidated refresh tokens in (distributed) cache. Cache entry should not be long lived, and refresh token shouldn't be long lived if you are using proper refresh token rotation with family invalidation in case of a leak. That being said cookies are still simplest and safest bet for simple monolith applications. [0] https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/rfc6749 [1] https://datatracker.ietf.org/doc/html/rfc7662 https://datatracker.ietf.org/doc/html/rfc7662
• blntechie 2y ago
  I have used OAuth2 with and without JWTs as bearer tokens and pretty much used them the same way. JWT helps with fetching the user details without having to hit the DB/backend, and that's basically was the only difference to me. I believe the issues he is describing is more OAuth2 rather than JWT.
• cryptonector 2y ago
  This is a bit nonsensical. Using the same logic regarding logout/revocation you would also be opposed to using Kerberos, say. So let's discuss the whole logout/revocation case. In a typical Windows/AD or Unix installation you might have Kerberos (definitely in the Windows/AD case, possibly in the Unix case) and a directory (definitely in both cases, though in the Unix case it might be purely local), and you use the authentication system (Kerberos, say) in such a way that it allows you to elide some directory lookups on Windows/AD or not at all on Unix. Either way you get a worst-case latency for revocation of the user's service ticket's lifetime (Windows) or whatever you do to stop locked user processes (Unix). Well, that's the theory, but in practice many SSHv2/whatever implementations do not force session end at ticket expiration. So Windows/AD uses group policy for revocation. On the Unix side... we don't really have a standard solution, but essentially one can build a daemon that periodically looks for and kills processes running as now-locked users. (For SSHv2, if you build re-authentication into a KEX, like GSS-KEX does, then you can force re-authentication and session end when authentication expires. In practice on Unix systems it's not really possible to elide a directory, so this is not necessary.) Now for HTTPS apps it's a different story. You can use cookie expiration and force re-authentication so that revocation latency is bearer token lifetime, then keep bearer token lifetimes short. If you don't control the token issuer then you can still impose a shorter cookie lifetime in your app and demand a fresh token when you force re-authentication. In any case, one does not need a revoked token/ticket/whatever list! But it is true that bearer tokens don't completely elide the need for a directory for things like SSH logins onto hosts. But they do for HTTPS apps. So I think TFA is just wrong.
• jmartrican 2y ago
  I worked in a backend team that introduced JWT, before I got there. The problem we had with JWT was that the data was stale. Even if it wasn't stale, it needed to be treated as stale because every service wanted the up to date data, even within 1 sec that data is old. The user could have changed something in their account from the time that the JWT was issued. I removed JWT and went back to the old UUIDs as tokens.
• dwhitney 2y ago
  oof - this article is pushing bad advice - general disclaimer: use a third party authentication system like Okta or Cognito. It's going to save you so much grief down the road. They pretty much all use the same pattern (OIDC), so you just need to learn it once, and you're good for at least another decade. Authentication is one of the easiest and most important things to take off of your plate. Do it.
• skywhopper 2y ago
  This article has a pretty narrow view of what uses a JWT can be put to. Yeah, in his limited examples, JWT is overengineered. And for non-distributed systems, JWT is overengineered. But there are plenty of use cases where JWT can simplify things and minimize complexity. Eg, when network connectivity is restricted and the consuming service cannot talk to the issuing service. Or when using a single token to auth against multiple remote systems. Or when latency is high between the central auth system and the consuming service. Or when you don’t have tight TTL/revocation concerns and you just want to auth once a day or week. Or when you just need a one-time token to establish some other service relationship. Or when you want to scope down permissions to subsets of what’s possible, or embed arbitrary auth metadata into the token, JWT has solutions for you. But if you just think of this author’s narrow view of what system designs look like, then skip the JWT.
• benced 2y ago
  I like the idea of using JWTs as opaque tokens. It sets you up nicely to migrate to using them semantically and there's very little downside (you just need a JWT library where the tokens are minted and then it's just string equality everywhere else) if you never actually end up using JWTs.
• nu11ptr 2y ago
  The article is just as wrong as articles that say you should use JWTs. They are both wrong because they lack context, at least in their opening. Interestingly, the article eventually does give context, but saying "it depends on what you need to do" apparently doesn't get as many clicks as starting by saying "no". For the record, I use JWTs, I have hardly any scale at all. I have none of the requirements that would hit the database on each request. It works just fine and I didn't need to consult an article to tell me what to think because, and this is the crazy part I know, I'm able to break apart my business requirements and decide for myself what is needed (or not). JWTs work just fine in my case. YMMV.
• fennecbutt 2y ago
  I personally love jwts. It's been suggested in other comments that you can just store tokens in a dB or something. Why would I, I can just issue a jwt and move on, I don't need to store anything apart from a key to check it with. And using jwts with nodejs (which I use most frequently) is a super simple and easy npm install, it's almost zero effort to use a jwt.