Re: [OAUTH-WG] Implementation questions around refresh token rotation

In the past, customers brought to our attention that some clients were not
able to receive a new refresh_token and use it right away. For that use
case we added a different type of rotation. The new refresh_token was
exactly the same as the given one. Except that it had a new expiration
date, lifetime and such. It was usually tight to exactly one scope valid
scope value.
Since customers were able to configure this behaviour for specific clients,
they used this feature for single or a limited number of use cases.
Other than that, a used refresh_token became invalid once it was used with
no overlap.

Regards,
Sascha

On Sat, 10 Oct 2020 at 13:42, David Waite <david=
40alkaline-solutions.com@dmarc.ietf.org> wrote:

> On Oct 6, 2020, at 16:05, Aaron Parecki <aaron@parecki.com> wrote:
> > However that also kind of defeats the purpose since attacks within that
> grace period would be hard to detect. I'm looking for an idea of where
> people have landed on that issue in practice.
>
> This is effectively a race condition, and a grace period hides your
> ability to detect the race. Because of the race condition is no guarantee
> that the second refresh token is the one that is retained, the client could
> still fail once it needs its next access token.
>
> Instead, an ideal system would allow you to make a security exception and
> turn off rotation, possibly only until the client revises their logic.
>
> -DW
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>