Maybe I am missing something here, but wouldn’t it be easier to deprecate the state parameter as CSRF protection, as suggested by RFC 9700? When using PKCE or a nonce, the client will attempt to exchange the authorization code, resulting in a failure (as intended), which should/will invalidate the authz code and stop the attack scenario.
As far as I can tell, this scenario is not discussed anywhere in the slides (the PKCE slides still involve state). Philippe > On 6 Nov 2025, at 16:35, Primbs, Jonas <[email protected]> wrote: > > Hi Frederik, > >> Am 06.11.2025 um 04:00 schrieb Frederik Krogsdal Jacobsen >> <[email protected]>: >> >> Hi Jonas, >> >> On Wed, 5 Nov 2025 at 16:25, Primbs, Jonas <[email protected] >> <mailto:[email protected]>> wrote: >>> yes, calling the token request validly, thereby invalidating the >>> authorization code for future usage by the attacker, and throwing away the >>> token response could also be a solution. >>> However, I am not sure what the implications could be with respect to how >>> authorization servers handle this (e.g., starting a session, which confuses >>> users when they look at the list of active sessions) or how clients handle >>> this (e.g., logging tokens in a potential crash dump). >>> If authorization servers implement token revocation correctly, when >>> authorization codes are used twice, sending a second valid token request >>> with the same authorization code afterwards might ensure that the issued >>> tokens cannot be used anymore. >> >> Good point about the implications wrt. lists of active sessions etc. For >> many cases this is a non-issue, but it might be confusing to some users. >> I don't see how logging tokens as a concern is impacted by using the >> code-exchange invalidation approach. If clients were doing this, they would >> already be doing it now. >> >>> Again, this might fail if the client faces any issues. So I prefer a >>> standardized authorization code invalidation mechanism. >>> One opportunity here, which is already standardized, is enforcing PKCE and >>> sending no code_verifier in the token request intentionally. >> >> Yes, I think this would work for any AS that supports PKCE. >> >>> If there already is a spec for that in CIBA, we should include or at least >>> reference this in the OAuth 2.1 spec. >> >> There is not. My intention was to say that a general invalidation mechanism >> could also be useful for CIBA. >> > > Do you think adding this to OAuth 2.1 and referencing this in CIBA is the > right place to go? > >> >> In general, I don't think form_post is the way to go. At least I don't have >> good experiences with it regarding user drop-off, and there are also the >> concerns mentioned by others on thread. > > What about „client implementers SHOULD use form_post for server-side clients“ > and not deprecating response_mode=query? > Because if developers have good reasons why they need response_mode=query, > they can still to do that, but they should know about the implications of > doing this. > >> >> Cheers, >> Frederik > > _______________________________________________ > OAuth mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
