Reuse Detection in Refresh Token Rotation

[flavioleggio]

Is your feature request related to a problem? Please describe.

I am currently using Hydra as Authorization Server in my enterprise applications suite and I am facing with security and user experience concerns in Single Page Applications. Our applications use Auth Code Flow and we currently avoid using refresh tokens in such an insecure environment.
I understand that Hydra implements the Refresh Token Rotation best practice, but in case of a stolen refresh token there is no automatic way to recognise that a refresh token is being reused to invalidate the whole refresh token family associated with that consent session.

Describe the solution you'd like

I have seen that there are examples of implementations of a reuse detection feature, like what happens in Auth0. Are there chances that a similar solution is (or will be) implemented in Hydra too?

Thanks in advance for any feedback on this.

[IonFoXx]

Hi @flavioleggio,

are you sure that the refresh tokens are not rotated/invalidated on refresh?

I recently tested and verified that if I exchange a refresh token with a new one the old one gets deleted from the database and can't be used anymore.

There is also this issue #1831 which discusses the need of a refresh token grace period on bad network connections to the database which is in that specific case a nice to have feature in my opinion.

Are you using a specific version where this issue appears?

[flavioleggio]

Hi @IonFoXx,

I am sure that refresh tokens are rotated and invalidated each time. The feature I am requesting here is actually Reuse Detection.

This is the supposed scenario for Automatic Reuse Detection (which as far as I know is not yet implemented in version 1.2.1):

1. Legitimate Client has RT1, and RT1 is leaked to or stolen by Malicious Client.
2. Legitimate Client uses RT1 to get a new RT/AT pair.
3. The Authorization Server returns RT2/AT2.
4. Malicious Client then attempts to use RT1 to get an access token. The Authorization Server recognizes that RT1 is being reused, and immediately invalidates the RT family, including RT2 because the reappearance of RT1 is indicative of token leakage. It is important that RT2 is also invalidated to prevent any subsequent damage, such as the attacker gaining access to that token.
5. The Authorization Server returns an Access Denied response to Malicious Client.
6. AT2 Expires and Legitimate Client attempts to use RT2 to request a new RT/AT pair.
7. The Authorization Server returns an Access Denied response to Legitimate Client. Re-authentication is required.

This solution is implemented in Auth0 Authorization Server, as described in the document referred in my post.

[IonFoXx]

Hi,

sorry, than I misunderstood your question and I should have spent more time reading the linked post. I understood that post in a way it already exists within hydra.

That feature in combination with #1831, which I think is also part of what Auth0 does (Refresh Token Reuse Interval), would be a really nice addition and increase the security of the whole project.

[aeneasr]

Thank you for this idea. Given these issues I think we generally need to have three strategies:

• Refresh Token rotation with grace period - see Refresh tokens need a grace period to deal with network errors and similar issues #1831
• Refresh Token rotation without grace period - current behavior
• Refresh Token rotation without grace period and token revokation on reuse - this issue

This is a bit of work, so I'm tagging this as "NEXT". However, I'd be more than happy to help with pointers and reviews if you want to tackle this!

[pharman]

I actually thought this was an implemented feature. Do you know if this is scheduled in a release yet? It's a critical feature IMO, when performing client-side PKCE flows.

[aeneasr]

No, it is currently not in our capacity to implement this as kt requires quite some refactoring - sorry!

[pharman]

Thanks for the update. Hopefully it will be on the roadmap somewhere

[svrakitin]

Implemented in ory/fosite#567. Work to support this in hydra is tracked in #2383.

[pharman]

👍