Jonas, We can ignore (1) because as you pointed out, the problem is not CSRF it's the browser swapping, so let's focus on (2)
The problem with (2) that I'm stuck on is your reasoning here: > The attacker then uses CSRF to inject the authorization request (including the attacker’s code challenge) into the user’s session and lets the user sign in to the authorization server. How exactly are you expecting that the attacker could inject in the CSRF to inject the authorization request? If the attacker has to compromise the application, the none of this matters as the attacker an directly compromise the usage, and no protection would be sufficient. At that point, we're back to my original points where there is no solution to this problem without the browsers making fundamental changes. On Thu, Nov 6, 2025, 16:55 Philippe De Ryck < [email protected]> wrote: > Maybe I am missing something here, but wouldn’t it be easier to deprecate > the state parameter as CSRF protection, as suggested by RFC 9700? When > using PKCE or a nonce, the client will attempt to exchange the > authorization code, resulting in a failure (as intended), which should/will > invalidate the authz code and stop the attack scenario. > > As far as I can tell, this scenario is not discussed anywhere in the > slides (the PKCE slides still involve state). > > Philippe > > On 6 Nov 2025, at 16:35, Primbs, Jonas <[email protected]> > wrote: > > Hi Frederik, > > Am 06.11.2025 um 04:00 schrieb Frederik Krogsdal Jacobsen < > [email protected]>: > > Hi Jonas, > > On Wed, 5 Nov 2025 at 16:25, Primbs, Jonas <[email protected]> > 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 > > > _______________________________________________ > 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
