On 17/11/2018 13:26, Torsten Lodderstedt wrote: > To start with, the AS may use refresh token rotation in combination with > automatic revocation in case of detected replay attempts. > > How does it work? The AS issues a new refresh token with every refresh and > invalidate the old one. This restricts the lifetime of a refresh token. If > someone (might be the legit client or an attacker) submits one of the older, > invalidated refresh token, the AS might interpret this as a signal indicating > token leakage and revoke the valid refresh token as well. We used this > technique at Deutsche Telekom since our first OAuth 2.0 implementation back > in 2012.
This is a clever solution. Did you experience any false positives, e.g. due to HTTP response timeouts on slow / poor connections? We were also thinking of additionally binding the refresh token to the end-user session at the AS / OP: * A valid refresh causing the session to be refreshed too * AS / OP logout or session expiration invalidating the refresh token Vladimir
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
