4 ms·

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 authe

• 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.
    • doctorpangloss 2y ago
      Well a lot of value in application architectures like this is, I want to give something access to my Google Calendar forever, to schedule tasks and read stuff, expressly without user intervention. Most people want token exchange - that an all-powerful user token gets exchanged for a token with the privileges specific to the service that holds onto it. I don't really want Google or Apple or whoever has, for idiosyncratic reasons, possession of a private key, to sign every request I make to Google Calendar, because they will inevitably revoke it sooner for obnoxious business reasons than any good security reason. And if I give a signing key to the service doing this deed for me, it's kind of redundant to an ordinary exchanged JWT. Really the ergonomics are why this hasn't been adopted more readily. I wonder why it's possible to have OpenTelemetry inject a header into thousands of different APIs and services for dozens of programming languages, more or less flawlessly. But if I wanted to do this at process boundaries, and the content of my header was the result of a stateless function of the current value of the header (aka token exchange + destination service): you are shit out of luck. Ultimately platform providers like Google, Apple and Meta lose their power when people do this, so I feel like the most sophisticated and cranky agitators are more or less right that the user experience is subordinate to the S&P top 10's bottom line, not real security concerns.
      • EthanHeilman 2y ago
        The first case sounds more like a case for OAuth which doesn't have to use JWTs or digital signatures. > I don't really want Google or Apple or whoever has, for idiosyncratic reasons, possession of a private key, to sign every request I make to Google Calendar, because they will inevitably revoke it sooner for obnoxious business reasons than any good security reason. Can you provide more context on this? I would assume asymmetric signing keys are less likely to be revoked than say an HMAC key since an HMAC key must be securely stored at both the client and server whereas you can just put a asymmetric signing key in an HSM at the client and be done with it.
        • radicalbyte 2y ago
          Which we have in modern computers and mobiles (the EU identity wallet concept is built around them).
  • davedx 2y ago
    If someone nefarious steals your <secret something> then yes you have problems, this isn’t anything unique to JWTs
    • ummonk 2y ago
      It makes a pretty big difference whether you have to send the secret down the wire to prove you possess it (e.g. a JWT, unlike say a private key).
  • DaiPlusPlus 2y ago
    The audience and scope claims exist to address that problem. Provided that RPs reject JWTs issued for other audiences than themselves there’s no security weakness here. This is why JWTs are used in OIDC (e.g. “Sign-in with Google”: any website can use it, and it doesn’t make Google’s own security weaker. I’ll concede that small, but important, details like these are not readily understood by those following some tutorial off some coding-camp content-farm (or worse: using a shared-secret for signing tokens instead of asymmetric cryptography, ugh) - and that’s also where we see the vulnerabilities. OAuth2+OIDC is very hard to grok.
    • rwdf 2y ago
      It's also why we use DPoP for serious stuff.
      • dadadad100 2y ago
        I hadn’t heard of DPoP until this mention. Please tell us more. Google tells me it is Demonstrating Proof of Possession, but is it supported by any products?
        • unscaled 2y ago
          DPoP described in RFC9449 - you can see from the RFC number it's quite new. I don't think there's wide support for it, but at least Okta supports it[1] and I think Auth0 are also working on adding DPoP. Is it good? I'm not a fan. To use DPoP safely (without replay attacks), you need to add server-side nonces ("nonce") and client-generated nonces ("jti", great and definitely not confusing terminology there). You need to make sure client-generated nonces are only used once, which requires setting up... wait for it... A database! And if you'll be using DPoP in a distributed manner, with access tokens then, well, a database shared across all services. And this is not an easy-to-scale read-oriented database like you'd have to use for stateful tokens. No, this is a database that requires an equal number of reads and writes (assuming you're not under a DDoS attack): for each DPoP validation, you'd need to read the nonce and then add it to the database. You'd also need to implement some sort of TTL mechanism to prevent the database from growing forever and implement strong rate limitation across all services to prevent very easy DDoS. It seems like the main driving motivation behind DPoP is to mitigate the cost of refresh tokens being exfiltrated from public clients using XSS attacks, but I believe it is too cumbersome to be used securely as a general mechanism for safe token delegation that prevents "pass-the-token" attacks. [1] https://developer.okta.com/docs/guides/dpop/nonoktaresourceserver/main/ https://developer.okta.com/docs/guides/dpop/nonoktaresources...
• EthanHeilman 2y ago
  > If you don't have microservices then there's much less reason to use JWT's. Fair point. This post assumes a single database which opaque tokens can be mapped to. That said, a lot of smaller webapps are and should be monoliths.
• deleted 2y ago
  [deleted]
• johnnyAghands 2y ago
  Yeah I agree, but I think this post is for those cases where this design might be inappropriate, mainly monoliths with single dbs. I disagree with the whole "you're not Google/FB"/"over arbitary RPS" logic though. If the design makes sense then it makes sense, end of story. Just understand it.. lol
• wg0 2y ago
  Side question, anyone knows where the phrase "used in anger" comes from? I know it means using something in production but where does it come from? Is it about battlefield and such?
  • louthy 2y ago
    It’s military based isn’t it? First time you use a weapon “in anger” is to test its effectiveness in real world conflict
  • mceachen 2y ago
    I've always heard it as a shorter alternative to "holy hell this tool is horrible but I'm unaware of an alternative, or cannot apply an alternative solution."
    • dagss 2y ago
      Are you sure? I have never interpreted it this way and it is the first way I hear this interpretation. My understanding: To use something "for real" on an actual project, not just toy around with it. (What you use can be good or bad, expression doesn't say)
      • Zecc 2y ago
        My interpretation has always been the same as mceachen's, but other comments in this sub-thread have thought me I am wrong and your understanding is correct. Today I learned. For what it's worth[0]: > If you do something in anger, you do it in a real or important situation as it is intended to be done, rather than just learning or hearing about it [0] https://dictionary.cambridge.org/dictionary/english/in-anger https://dictionary.cambridge.org/dictionary/english/in-anger
    • 7sidedmarble 2y ago
      No, it's a military term. Firing a cannon in anger for instance means firing at the enemy, rather than in training.
  • deleted 2y ago
• Ozzie_osman 2y ago
  Even with microservices, you still have the invalidation problem. I guess you could use non-Jwt for external auth and jwt between the services, but then you lose the benefit of standardization (and still don't get full zero-trust). Or you could standardize on jwt, but then, invalidation problem again.
  • jupp0r 2y ago
    It's pretty rare in practice to be able to make authz decisions solely based on the information in JWT claims. Space in HTTP headers is limited and any moderately complex system will have a separate authz concept anyways that can be used to check for token invalidation.
    • hyperadvanced 2y ago
      Exactly. Learned this the hard way. JWT is good for “this token is legit and has XYZ role or group”, and letting it go to the next layer. The next layer should do some addition checking that token has legit claims on modifying a resource or taking other actions, however that might be.
  • davedx 2y ago
    Depends on your business. Most b2b companies probably don’t need to care about invalidation, at least not in the startup phase. For B2C it’s going to be more important. But ask yourself “why do I need to pre-emptively invalidate tokens?”
• thayne 2y ago
  Same applies to non-micro service architectures.
• ak217 2y ago
  > doesn't seem to address microservice architectures at all Or just, you know, service architectures. Most microservice architectures I've seen go way too far down the route of breaking up services and their infrastructure to an impractical level. But all you need in order to make JWTs really useful is two federated services. This happens all the time, often in the course of some partnership, acquisition, or just an organizational structure meant to decouple 2+ teams from each other. Based on their mention of a single framework connecting to a single database, OP seems to have never moved past the point of developing a single service. Which is fine! It makes things simpler for sure, and you can get very far with that. But they are then dispensing advice about things they don't seem to know much about.