+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
