Let’s collect auth code revocation solutions: S1: Enforce PKCE + normal token request but without code_verifier. + No additional endpoints + Works for many existing implementations - AS must implement PKCE and enforce it for all clients (bad for testing)
S2: Use specific client_id at the token endpoint. + No additional endpoints - A bit hacky S3: Specify a dedicated token endpoint + One official way - Huge changes required S4: Use token revocation endpoint + Just an extension of existing endpoints - Client cannot know if the AS implements this > Am 06.11.2025 um 08:24 schrieb Neil Madden <[email protected]>: > > 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]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
