[OAUTH-WG] Re: Browser-Swapping

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

Hi Frederik,

> Am 06.11.2025 um 04:00 schrieb Frederik Krogsdal Jacobsen <[e-mail]>:
> 
> Hi Jonas,
> 
> On Wed, 5 Nov 2025 at 16:25, Primbs, Jonas <[e-mail] <mailto:[e-mail]>> wrote:
>> 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.
> 
> Good point about the implications wrt. lists of active sessions etc. For many cases this is a non-issue, but it might be confusing to some users.
> I don't see how logging tokens as a concern is impacted by using the code-exchange invalidation approach. If clients were doing this, they would already be doing it now.
> 
>> 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.
> 
> Yes, I think this would work for any AS that supports PKCE.
>  
>> If there already is a spec for that in CIBA, we should include or at least reference this in the OAuth 2.1 spec.
> 
> There is not. My intention was to say that a general invalidation mechanism could also be useful for CIBA.
> 

Do you think adding this to OAuth 2.1 and referencing this in CIBA is the right place to go?

> 
> In general, I don't think form_post is the way to go. At least I don't have good experiences with it regarding user drop-off, and there are also the concerns mentioned by others on thread.

What about „client implementers SHOULD use form_post for server-side clients“ and not deprecating response_mode=query?
Because if developers have good reasons why they need response_mode=query, they can still to do that, but they should know about the implications of doing this.

>  
> Cheers,
> Frederik