I want to +1 this as well. This really got my attention as an impressive and straightforward defense technique.
Jim > On Nov 19, 2018, at 3:48 PM, Hans Zandbelt <hans.zandb...@zmartzone.eu> wrote: > > +1 to the suggestions that Vladimir raises; I've seen a fair number of > requests in the field for exactly that > > Hans. > >> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov >> <vladi...@connect2id.com> wrote: >>> 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 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > -- > hans.zandb...@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > 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
