Out of curiosity: Have you seen this in practice? I’m asking since most/all refresh token implementations I have seen are handles. Just rotating for consistency makes especially the live of server based clients harder as they need to propagate such a change through the cluster.
> Am 12.10.2020 um 11:54 schrieb David Waite > <david=40alkaline-solutions....@dmarc.ietf.org>: > > 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>: >>>> >>> >>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
