> 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)
> It's a bit hacky but has the advantage of likely doing the right thing for most ASes On one hand, this is why I am a fan of expanding the revocation endpoint to support authorization codes - the behavior of when an authorization code is revoked can be made much more explicit. ASs can explicitly declare whether or not they support it, instead of clients assuming the AS implemented the previous specs in the correct way. On the other hand, a revocation endpoint pushes some of the burden of CSRF detection onto the client to properly invoke it (although the same is true of sending a special client_id value!) I still prefer the very explicit approach over deliberately calling the token endpoint incorrectly. On Thu, Nov 6, 2025 at 5:26 AM Neil Madden <[email protected]> wrote: > 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]> <[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]> > 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] >> Web: https://kn.inf.uni-tuebingen.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] > > -- > 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-88468https://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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
