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.
> 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.
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.
It limits your ability to compartmentalize your infrastructure, establish security perimeters, and provide defense-in-depth against vulnerabilities in your dependencies.
> 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.
My interpretation is that the audience and scope claims, as other features like nonce, are in place to prevent tokens from being intercepted and misused, not to facilitate passing tokens around.
Don’t see how those prevent tokens from being misused? They just prevent anyone from issuing tokens as you. Not by themselves, but if you implement your server correctly.
> Don’t see how those prevent tokens from being misused?
The purpose of a nonce is to explicitly prevent the token from being reused.
The purpose of the other claims is to prevent them from being accepted (and used) in calls to other services.
If you implement your server correctly, each instance of each service is a principal which goes through auth flows independently and uses its own tokens.
Large companies have fallen into this trap [1]. So you are right that aud addresses the problem, but it's widespread enough to question if it really affects just coding camp content farms. Hard to grok is probably possibly in some way a design flaw.
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?
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.
I agree that DPoP - especially the nonce - is quite complex, but I don't think it's as bad as you make out.
Proof tokens can only be used for a narrow window of time (seconds to minutes), so you just need a cache of recently seen token identifiers (jtis) to do replay detection. And proof tokens are bound to an endpoint with the htm and htu claims. They can't be used across services, so I don't see a need for that replay cache to be shared across all services.
The main issue for us was not the size of the cache, but distributing a guaranteed single-use cache (CP in CAP theorem) across multiple regions and handling traffic from all microservices that can read the token (we have hundreds and plan to support thousands, so I admit our case is quite extreme).
Please note that I am talking about using DPoP to verify _every_ request, not just a token refresh request (where OAuth 2.1 is setting DPoP as an alternative to issuing a new refresh token and revoking the old one). When using DPoP for every request, the amount of client-generated nonces ("jti"s) is quite high, since you need a new one for every request.
And yes, you can rely on "htu" to distinguish between services and have a separate nonce cache for every service, but this would require deploying and maintaining additional infrastructure for every service. Depending on your organization this may or may not be an issue, but this is a big issue for us.
What did we decide on instead? Request Signature and Mutual TLS binding (RFC 8705) where possible. Request Signatures without nonces do not work well for repeatable requests (like the Refresh Token Grant), but this is not our use case.
DPoP is an OAuth extension that defends against token replay by sender constraining tokens. It is a new-ish spec, but support is pretty widespread already. It's used in a lot of European banking that has pretty strict security requirements, and it's supported by some of the big cloud identity providers as well as the OAuth framework I work on, IdentityServer. We have sample code and docs etc on our blog: https://blog.duendesoftware.com/posts/20230504_dpop/
It's a new proposed standard. Where I work (in healthcare in Europe) we have it as a requirement for any new APIs we offer public access to.
We have our own auth service, but looks like Okta already offers DPoP.
> 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.
Bearer tokens are vulnerable to man-in-the-middle impersonation.
It's right in the name.
Anyway, zero trust architecture are wildly overrated and used in way more places than they should. But the entire thread is correct in that you can't build them with bearer tokens.
Man-in-the-middle impersonation is not the biggest threat because TLS 1.3 does a decent job of protecting the token in transit. The biggest issue is the endpoints:
1. The client that holds the token can't use an HSM or SSM to protect the token because they need to transmit it. Thus a compromise of the client via an XSS or Malware, results in the token leaking.
2. The server that receives the token, might be compromised and they can replay the token to other servers or leak it accidentally e.g., with a log file or to an analytics service.
Both of these problems go away if you uses OpenPubkey or Verifiable Credentials with JWTs. The JWT is now a public value, and the client holds a signing key.
1. The client can protect the signing key with an HSM or SSM (modern web browsers grant javascript access to a SSM).
2. The server only receives the JWT (now a public value) and a signature specific to that server. They don't have any secrets to protect.
> But the entire thread is correct in that you can't build them with bearer tokens.
You can and people do, but it is far better to use proof of possession JWTs than bearer JWTs. Even better to use JWS instead of JWTs so you can make use of multiple JWS signers (a JWT is a type of JWS, but a JWS with more than one signer can not be a JWT).
To pitch my own project, OpenPubkey[0], it is designed for exactly this use case. OpenPubkey let's you add a public key to an ID Token (JWT) without needing any change at the IDP.
1. Alice generates an ephemeral key pair (if she is using a browser she can generate the key pair as a "non-extractable key"[1]).
2. Alice gets ID Token issued by Google that commits to their public key,
3. Alice signs her API request data to Service A and sends her ID Token to Service A.
4. Service A checks the ID Token (JWT) is issued by Google and that the identity (alice@gmail.com) is authorized to make this API call, then it extracts Alice's public key from the ID Token and verifies the signature on the data in the API call. Then it passes the signed data to Service B.
5. Service B verifies everything again including that the data is validly signed by Alice. Service B could then write this data and its cryptographic prominence into the database.
Technically OpenPubkey uses a JWS, but it is a JWS composed of a JWT (ID Token) with additional signatures. OpenPubkey signed messages, like the ones passed via the API are also JWS.
I'm working on a system where each service in the path adds their signatures to the signed message so you can cryptographically enforce that messages must pass through particular services and then check that at during the database write or read. Using signature aggregation, you don't get a linear increase in verification cost as the number of signatures increase. It doesn't seem to add much overhead to service meshes since they are already standing up and tearing down mTLS tunnels.
The main question to me is how much autonomy do you want to give to your services. There are cases in which you want services to query each other without those services having to prove that the call originated from a specific authorized user.
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.
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.
I thought the EU wallet was using JWTs that attest to public key. You don't use them as bearer tokens, you use them as certificates and then do verifiable credential presentation via proof of possession and SD-JWTs.
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.
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.
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.
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?”
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."
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)
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
I don't think it necessarily means using it in production but rather using it on some non-trivial capacity that exposes you to it's various complexities and nuances such that you have more than just a surface level understanding. That probably coincides with using things in production a lot of the time, but that's not strictly necessary.
> 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.
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
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.