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 wrote: > On Oct 6, 2020, at 16:05, Aaron Parecki 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 > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Implementation questions around refresh token rotation
On Oct 6, 2020, at 16:05, Aaron Parecki 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
Re: [OAUTH-WG] Implementation questions around refresh token rotation
> Am 07.10.2020 um 09:20 schrieb Neil Madden : > > > >>> On 6 Oct 2020, at 23:05, Aaron Parecki 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). We did not implement a grace period for the same reason. Refresh token rotation is a countermeasure against refresh token theft and replay for public client. A grace period to some degree limits it effectiveness against exactly this attack. best regards, Torsten. > >> 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 smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
