On Wed, Nov 5, 2025 at 10:03 AM Frederik Krogsdal Jacobsen <[email protected]> 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. > This would of course only work with an AS that correctly implements the > security guidance in section 10.5 of RFC 6749: "Authorization codes MUST > be short lived and single-use." > The main problem with this approach is that it is a bit confusing to > explain. > > I also know that in practice, some AS implementers allow multiple uses of > the code, > 😱 Do you have names? > 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) -- Thomas Broyer /tɔ.ma.bʁwa.je/ <https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
