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. 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]>: > > 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]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
