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. 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. Cheers, Frederik
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
