fix: add reuse interval for token refresh

[kangmingtay]

What kind of change does this PR introduce?

• Addresses fix: refresh token race condition auth-js#274 and Token refresh fails silently when offline and never recovers auth-js#226
• The reuse interval can be configured in the .env under GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL
• During the reuse interval, exchanging the same refresh token multiple times will always return the next refresh token. The refresh token must be the previous token and the requests must fall within the reuse interval. If the refresh token isn't the immediate parent of the currently valid refresh token, then the reuse detection will kick in.
• Example

token | revoked | parent
foo        t      null
bar        t      foo
baz        f      bar

Assuming the refresh token requests are being made within the reuse interval:

1. Using bar in the request will return baz since it's the previous revoked token.
2. Using foo in the request will not return baz since it's the second-last previous revoked token. This will trigger the reuse detection and cause bar and baz to be revoked.
3. Using baz in the request will create a new refresh token.

Other considerations

• Reuse interval should preferably be set to a value greater than the refresh token interval in gotrue-js

[thorwebdev]

LGTM 🎉

Reuse interval should preferably be set to a value greater than the refresh token interval in gotrue-js

I'm currently defaulting to retrying failed requests after 5s: https://github.com/supabase/gotrue-js/pull/278/files#diff-8c943ccfb5928fff63708e99eaafa93f8845c9405ed8e4b32afed23e5003025aR6 So maybe the default interval should be larger than that? Or we shorten the retries to every second and make the default server interval 5s? Wdyt

[kangmingtay]

So maybe the default interval should be larger than that? Or we shorten the retries to every second and make the default server interval 5s?

@thorwebdev Hmm i think there are 2 cases we need to consider:

1. To prevent the case where there are concurrent tabs and the JWT expires, the reuse interval has to be larger than the expiresIn - refreshDurationBeforeExpires
2. Offline retries. Reuse interval > Offline retry interval

I was thinking somewhere between 10-30s to also account for potential delay in network or clock skew.

[github-actions]

🎉 This PR is included in version 2.6.28 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[thorwebdev]

@kangmingtay can you post here when this version is deployed to hosted Supabase instances?

[kangmingtay]

hey everyone, we've deployed this update to all hosted Supabase instance already!

[Benjamin-Dobell]

It looks like this solution is mostly just kicking the can down the road. We've handled one specific case i.e. when several clients have the same refresh token and there's a race to refresh them. However, we're not handling the situation where a client refreshes their token twice before another client refreshes theirs once.

Client 1 has Token A
Client 2 has Token A

Client 2: Refresh (Token A)

• Token A is valid
• Issue Token B
• Revoke Token A
• Return Token B

Client 2: Refresh (Token B)

• Token B is valid
• Issue Token C
• Revoke Token B
• Return Token C

Client 1: Refresh (Token A)

• Token A is revoked
• GetValidChildToken (parent = Token A and revoked = false) = NULL
• Return "Invalid Refresh Token"

I'm seeing this in practice.

Rather than GetValidChildToken querying for parent = ? and revoked = false, it should query for parent = ? and loop until it finds an descendant token that isn't revoked or no more results.