An AS may decide refresh token rotation is useful for other reasons (such as if the token is an encrypted value and the AS cluster does key rotation), or may decide to rotate all tokens for consistency.
Eventually best practices may indicate sender constrained tokens for public clients. At that point, refresh rotation may not be security practice but could still be something an AS does as part of its own design. And an AS may elect to do this often so that clients fail (and correct their logic) faster. -DW > On Oct 12, 2020, at 03:15, Torsten Lodderstedt > <torsten=40lodderstedt....@dmarc.ietf.org> wrote: > >> >> Am 12.10.2020 um 09:04 schrieb Dave Tonge <dave.to...@momentumft.co.uk >> <mailto:dave.to...@momentumft.co.uk>>: >> >> >> Hi Neil >> >> > refresh token rotation is better thought of as providing protection >> against insecure token storage on the client >> >> I agree with your reasoning - and that was more the intent of what I said. >> We've seen refresh token rotation used for confidential clients that have >> secure storage (i.e. are run in a data center not on a mobile device) and it >> has caused problems with zero additional security benefits. > > Those are good examples of why refresh token rotation should not be used if > there are better ways available to protect refresh tokens from replay. Client > authentication or sender constrained refresh tokens are the better choice.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
