> On 6 Oct 2020, at 23:05, Aaron Parecki <aa...@parecki.com> wrote:
> 
> 
> Hi all, I have a couple questions for those of you who have implemented 
> refresh token rotation...
> 
> Have you included the option of a grace period on refresh token use, allowing 
> multiple uses within some time window? I'm wondering because a grace period 
> where a refresh token may be used more than once would work around the 
> problem that has been brought up, of a mobile app accidentally using a 
> refresh token more than once during normal operation because different 
> threads are unable to coordinate between themselves. 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.

Right. We’ve avoided adding a grace period for this reason. An attacker in a 
position to steal a refresh token is also presumably in a position to see when 
the legitimate client uses it and then sneak in just afterwards within the 
grace period. You could maybe only allow grace period refreshes from the same 
IP address but I’m not sure that would always hold in the flaky mobile network 
scenarios (eg refresh fails on 2G due to disconnect then client switches to 
Wifi hotspot and retries). 

> If you have implemented a grace period, then how do you handle expiring the 
> additional refresh tokens that have been granted? For example, if RT "R1" is 
> used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" and 
> "R1.2", what happens if "R1.2" is then later used? Would you invalidate 
> "R1.1" at that point? If so, why, and if not, why not?
> 
> It would be most interesting to hear practical experience from people who 
> have already built refresh token rotation into a system.
> 
> Thanks!
> 
> ---
> Aaron Parecki
> https://aaronparecki.com
> 
> _______________________________________________
> 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

Reply via email to