Hi Neil, > On 22. Jul 2019, at 13:59, Neil Madden <neil.mad...@forgerock.com> wrote: > >> In addition, a public client which does not use its refresh token in an >> “offline” manner may have theft go unnoticed for a considerable period of >> time, and the operational model of public clients usually puts detection of >> local token theft in the hand of the end user and client software, not an >> administrator or organizational security staff. > > Given that a refresh token has to be used at the AS, isn't the situation here > *better* for refresh tokens? Every time an attacker uses a stolen refresh > token you get a nice ping against your centralised token endpoint, giving you > a great opportunity to run contextual checks to decide if something looks > fishy.
I agree with your assessment. That why the Security BCP (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4..12) requires authorisation servers to detect refresh token replay. Even if the refresh token cannot be sender constraint, one-time refresh tokens (or refresh token rotation) is a viable option when used in combination with conditional revocation of the active refresh token if something looks fishy. kind regards, Torsten.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
