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] > <mailto:[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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
