Re: [OAUTH-WG] Refresh tokens

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 <torsten@lodderstedt.net>
wrote:

> Hi Neil,
>
> > On 22. Jul 2019, at 13:59, Neil Madden <neil.madden@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
>