3 ms·

Thank you!! We use rotating refresh tokens to detect session theft reliably.

• md_ 6y ago
  I'm not entirely sure I'm understanding the terminology you're using. Are you talking about OAuth2 tokens (i.e. https://tools.ietf.org/html/rfc6819#section-5.2.2.3 https://tools.ietf.org/html/rfc6819#section-5.2.2.3), or are you talking about browser cookies? In both cases, rotation strikes me as being of limited (though nonzero) value. While rotation (and invalidation of the previous token) can be used to prevent long-lived concurrent use of cloned tokens, there's a good chance an attacker can ensure that they are the ones who get the "new" token. As a result, the user--the legitimate OAuth client or browser--would be left with the now-invalidated token, and will be logged out. The most likely result of which--depending on application design choices--is that the user simply logs in again! You now have two sessions, one of which is solely owned by an attacker, and one of which is solely owned by a user! (There are cases where this is still valuable: if you enforce "only one session globally" per user, for example, or if you use the presentation of an "invalidated" token as indicative of theft. But both are application design choices that will commonly be inappropriate.) At the extreme, of course, if your threat model is local malware, UXSS, etc, an attacker can just do a "person in the browser" attack, in which no token copying happens. I'm not sure why I'm bothering to write all of this. Call it free consulting? ;) My point is really that the threat model needs to be clearly stated and, for some threat models (including some which are featured in case studies on your website), this approach may be largely ineffective.