This makes me wonder if we could in fact have a special client_id value that indicates that the AS should revoke the code (and any tokens if issues)? It's a bit hacky but has the advantage of likely doing the right thing for most ASes, as Tim mentions. Something like client_id=csrf_detected_revoke_please.
> On 6 Nov 2025, at 13:04, Tim Würtele <[email protected]> > wrote: > > Hi Jonas, > > a minor (but imho relevant to this discussion) nitpicking inline. > > Best, > > Tim > > On 05.11.25 16:25, Primbs, Jonas wrote: >> Hi Frederik, >> >> 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. >> >> 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. > The issue with that is the (historically grown) lack of precision in the > specs as to when exactly an authZ code is to be invalidated by the AS. Let me > elaborate a bit: > > RFC 6749 says (in 4.x) the client MUST only use the code once and the AS MUST > deny all but the first request with a given code (and SHOULD revoke > associated tokens). In 10.5, we have "Authorization codes MUST be [...] > single-use." - without being explicit about whether this statement applies to > the "user" of the code (the client), the AS, or both; although I'd argue that > interpreting this as "the client may only use it once" is a justifiable > interpretation (especially because the subsequent sentences in 10.5 also just > repeat the SHOULD statement from 4.x). > > RFC 6819, 4.4.1.1 does say "The authorization server should enforce a > one-time usage restriction (see Section 5.1.5.4)."; but the language there is > not normative ("may", "may want", ...); the same is true for 5.2.1.1. > > OIDC is even more vague (3.1.3.2): The AS MUST ... "If possible, verify that > the Authorization Code has not been previously used." > > ... just a few examples. > > Using PKCE does not change this ambiguity; RFC 7636 does not talk about code > invalidation at all. > > > > In other words: An error response from the AS's token EP, e.g., due to a > wrong/missing code_verifier does not guarantee that the code has been > invalidated. And as others have pointed out in this thread, there are AS > implementations out there that do accept a code multiple times (be it "on > purpose", or due to CAP). Of course, one might argue that these are not > standards-compliant, but I don't think there's a very strong case for that > claim, given the (historically) inaccurate wording... > > That being said: If I were to implement a client today, I would make such a > "wrong" token request to at least give the AS a chance of detecting the > attack - and if the AS follows the SHOULD-advise from 6749, any tokens issued > for that code would then immediately be invalidated, which of course does not > prevent an attack, but may help to limit the damage. > > Side note: This "best effort" damage control strategy does not even need > PKCE, just sending the code with a wrong client_id should lead to the same > result (from a "did the AS implement 6749's SHOULD" perspective). > >> >> If there already is a spec for that in CIBA, we should include or at least >> reference this in the OAuth 2.1 spec. >> >> Greetings, >> Jonas >> >> >>> Am 05.11.2025 um 04:02 schrieb Frederik Krogsdal Jacobsen >>> <[email protected]> <mailto:[email protected]>: >>> >>> Hi Jonas, >>> >>> Thanks for the detailed explanation of the attack and possible mitigations. >>> >>> It seems to me that your suggestion 3 could be implemented by the client by >>> simply exchanging the code and throwing away the token response when the >>> initial CSRF is detected. >>> This would of course only work with an AS that correctly implements the >>> security guidance in section 10.5 of RFC 6749: "Authorization codes MUST be >>> short lived and single-use." >>> The main problem with this approach is that it is a bit confusing to >>> explain. >>> >>> I also know that in practice, some AS implementers allow multiple uses of >>> the code, so it may be interesting to look into defining a specific "cancel >>> request" that uses up a code without returning a token. >>> Defining such a request might also make the approach easier to explain. >>> In fact, many OIDC providers already define custom "cancel" requests to >>> mitigate phishing. A "cancel" request might also be useful for OpenID CIBA >>> [1]. >>> >>> Do you see any problems with this approach? >>> >>> Cheers, >>> Frederik >>> >>> [1]: >>> https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html >>> >>> On Tue, 4 Nov 2025 at 05:10, Primbs, Jonas <[email protected] >>> <mailto:[email protected]>> wrote: >>>> Hi all, >>>> >>>> according to Aaron’s recommendation, I have created a PR for OAuth 2.1: >>>> https://github.com/oauth-wg/oauth-v2-1/pull/230 >>>> >>>> It references OpenID Connect’s response modes (fragment and form_post) as >>>> solutions for Browser-Swapping attacks, which I have presented in today’s >>>> OAuth WG meeting. >>>> If you have missed my presentation, but are still interested, here are my >>>> slides: >>>> https://datatracker.ietf.org/meeting/124/materials/slides-124-oauth-sessa-browser-swapping-01 >>>> >>>> I’m interested in your feedback on this first draft, which currently >>>> covers only recommendation #2 from my slides, because this is probably the >>>> least controversial change. >>>> If you are attending onsite, also feel free to speak to me in the hallway. >>>> My company gave me enough of the „No, PKCE…“ t-shirts for the rest of the >>>> week, so that it’s easier for you to find me. @Brian & Mike: I have >>>> learned from the best ;-) >>>> >>>> Greetings, >>>> Jonas >>>> >>>> >>>> Jonas Primbs M.Sc. >>>> University of Tübingen >>>> Faculty of Science >>>> Department of Computer Science >>>> Sand 13, 72076 Tübingen, Germany >>>> Tel.: (+49) 7071 / 29-70512 >>>> Mail: [email protected] <mailto:[email protected]> >>>> Web: https://kn.inf.uni-tuebingen.de <https://kn.inf.uni-tuebingen.de/> >>>> _______________________________________________ >>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >> >> >> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > -- > Tim Würtele, M.Sc. > Room V38 2.434 > Institute of Information Security - SEC > Universität Stuttgart > Universitätsstraße 38 > D-70569 Stuttgart > Germany > Phone: +49 (0) 711 685-88468 > https://sec.uni-stuttgart.de > <https://sec.uni-stuttgart.de/>_______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
