Ok thanks for the input here everyone. I'm not seeing much of a consensus, but these are all excellent points and I've collected them for discussion during the meeting on Friday.
---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk> On Mon, Jul 22, 2019 at 8:12 AM Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > 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. _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
