I am also a general fan of extending the revocation endpoint to support authorization codes.
One snag with that approach - if the attacker downgrades or otherwise manipulates the response mode (e.g. changes it from form_post to query) then there is a significant chance the client will not properly parse out the authorization code, and will not be able to call the revocation endpoint. Clients need to implement redirect handlers for all possible response modes to properly detect the attack - or clients would additionally need to use PAR to prevent manipulation of the response mode by an attacker entirely. On Wed, Nov 5, 2025 at 3:38 AM Frederik Krogsdal Jacobsen <[email protected]> wrote: > On Wed, 5 Nov 2025 at 11:13, Thomas Broyer <[email protected]> wrote: > >> 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. >>> >> >> That's what I was thinking as well, but also immediately revoking the >> token, not just throwing it away, to be extra-safe. >> > > Sure, if the AS implements RFC 7009, but otherwise I don't think this is > possible for the client to do? > > >> I also know that in practice, some AS implementers allow multiple uses of >>> the code, >>> >> >> 😱 Do you have names? >> > > Quickly searching "authorization code reuse", I got several results on the > first page. E.g. Azure AD B2C allowed this at least until the end of last > year (and maybe still does) [1,2]. > Usually the argument for allowing it is something along the lines of > "keeping state in a distributed system is too hard," e.g. [3]. > Sometimes the impact is mitigated by using e.g. the OIDC nonce value. > > 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]. >>> >> >> I see no reason why the revocation endpoint couldn't support revoking >> authorization codes as well (that would need to be spec'd, and then >> implemented, and deployed; so in the meantime: exchange the code for a >> token, and immediately revoke it, assuming –because that's how it MUST be– >> the authorization code is single-use) >> > > I agree that extending the revocation endpoint is probably the way forward > when the client detects CSRF. > In the meantime, exchanging the code and immediately revoking (if > possible), then throwing away the token should be a quick way to mitigate > the attack. > It might be worth mentioning this approach in OAuth 2.1? > > Cheers, > Frederik > > [1]: > https://learn.microsoft.com/en-us/answers/questions/1179021/how-to-prevent-reuse-of-oauth-authorization-code > [2]: > https://learn.microsoft.com/en-sg/answers/questions/2131783/invalidate-authorization-code-after-use > [3]: https://github.com/kanidm/kanidm/issues/2775 > _______________________________________________ > 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]
