+1 to Max Enforcing a specific response_mode at the AS is much simpler for developers than having to handle query, fragment, and form_post callbacks just in case a downgrade attack happens. If I had seen form_post in the wild, I would assume that the GET endpoint for the redirect URI would not even have been implemented at all, leading to a successful URL sharing attack.
PAR reduces this attack vector by shifting the downgrading attack to the backend. However, for frontend-clients this could still be an attack vector. > Am 05.11.2025 um 08:43 schrieb Max Gerber <[email protected]>: > > 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] > <mailto:[email protected]>> wrote: >> On Wed, 5 Nov 2025 at 11:13, Thomas Broyer <[email protected] >> <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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]
