Rework to make updates to RFC 7523 rather than replacing it #7
Conversation
| <spanx style="verb">authorization-grant+jwt</spanx> or | ||
| another more specific explicit type value defined by a specification profiling this specification. | ||
| Authorization grant JWTs not using the explicit type value | ||
| MUST be rejected by the authorization server. |
There was a problem hiding this comment.
I am generally in favour of strong typing - it makes it clear what the purpose of a token is and reduces risk of implementation errors or mix-ups where tokens are used inappropriately (at least, it makes it easier to detect and spot when that happens).
My understanding of the introduction of strongly typed tokens is that it is meant as a type of versioning in this case. It allows implementors to distinguish between tokens they should expect to have the audience constraints needed to mitigate the attack vs ones that may, or may not, have the correct audience constraints. Regardless, the authorization server still needs to check the constraint.
I am concerned about the impact of a MUST on the eco-system of JWT token issuers that are deployed.
For example, Kubernetes Projected. Service Acccount Tokens (first deployed circa 2018) can be used for either workload authentication (now client-authentication+jwt in this draft) or authorisation grant flow (now client-authorization+jwt in this draft). Similarly, SPIFFE defines a JWT (JWT-SVID) that is either typed as JWT or untyped and used by workloads for authentication and authorization grant flows (first deployed circa 2016). Both systems are widely deployed and these tokens can be used with RFC 7523.
The strong typing proposed here appears to prohibit the use of tokens issued by those systems from being used in this specification, even if they strictly comply with the audience constraints needed to mitigate the attack.
Updating existing systems is not just a matter of adding typing to existing tokens being issued, but is a more fundamental change as a workload would now need two tokens, one of each type, depending on what the credential is being used for. It also creates complexity in code as applications now need to be aware of which token to use. In new implementations, this may be feasible. Retrofitting a large eco-system may be problematic with a very long tail.
The potential downside is that the remedies in this specification may not get deployed because of the practicalities of having to support multiple token types that are strongly typed. To put it another way, requiring strong typing may limit the deployment of the mitigation of stricter audience values.
Given that the intent of the typing is to act as a form of versioning which indicates that the audience constraint is applied, could we find language that allows an authorization server to still accept and untyped token, but still reject it if the audience constrain is not applied? There is language earlier in the specification indicating "Furthermore, the authorization server MUST reject any such token that does not contain its own issuer identifier as the sole audience value.", suggesting that this check needs to be performed in any event, regardless of typing.
For example, perhaps the MUST can be relaxed to a SHOULD, to allow for untyped JWTs that have the audience constraint applied? This way JWT typing does not become a barrier to deploying the audience constraint fix, but can still be used as a clear signal that an updated issuer is in fact limiting the audience appropriately.
There was a problem hiding this comment.
Please file an issue with your comment, @PieterKas. Thanks!
There was a problem hiding this comment.
Even from a structural standpoint, I still believe that it'd be more straightforward to build up from https://datatracker.ietf.org/doc/html/draft-campbell-oauth-rfc7523redux (acknowledging it's little more than an outline currently) rather than reworking. But to the extent things are moving in that direction, I'm good with it.
We should update or add ref to https://eprint.iacr.org/2025/629 per Tim at some point too.
This PR updates the spec to only make changes to RFC 7523, rather than replacing it, as was decided at IETF 122.
It also removes the updates to RFC 9101, also per input at IETF 122.
It does not yet update the treatment of authorization grants or SAML. That will happen in a subsequent set of changes.
I wanted to get the structural changes to the spec in place first.
Cc: @RalphBragg @PedramHD @SECtim @ve7jtb