[OAUTH-WG] Re: Browser-Swapping

["Primbs, Jonas" <[e-mail]>]

+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 <max=[e-mail]>:
> 
> 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 <frederik.krogsdal=[e-mail] <mailto:[e-mail]>> wrote:
>> On Wed, 5 Nov 2025 at 11:13, Thomas Broyer <[e-mail] <mailto:[e-mail]>> 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 -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]