supabase / auth / 18910658377

push

github

feat: introduce v2 refresh token algorithm (#2216)

Introduces v2 of a refresh token algorithm.

**Goals**

1. **Smaller disk size.** A common complaint with the `refresh_tokens`
table is that it's huge and difficult to clean up without impacting IO
performance.
2. **Lighter on replication.** A lot of active users cause a lot of
on-wire traffic for replication.
3. **Easier to debug and analyze.** Refresh tokens are not transparent,
and a recursive self-relationship is not easy to debug with difficult
edge cases that are not local in time.

**Configuration Options**

| Config | Meaning |
| --- | --- |
| `GOTRUE_SECURITY_REFRESH_TOKEN_ALGORITHM_VERSION` | 0 or 1 for regular
tokens, 2 for new tokens. This currently only applies on new sessions.
Old sessions use old implementation. |
| `GOTRUE_SECURITY_REFRESH_TOKEN_ALLOW_REUSE` | not secure, but allows
any v2 refresh token to always be reused. |

**Implementation**

Refresh tokens now encode the session ID + counter value, which is then
signed by a per-session HMAC key. By comparing the state in the session
and the counter in the refresh token, we can identify whether a refresh
token is being used properly or it's being reused. We can also identify
what type of reuse is going on.

If the refresh token counter is the previous refresh token, it means the
client failed to save the last response. This is always allowed.

If the refresh token counter is older than the previous refresh token,
then it's being reused. Reuse is allowed only if the client is
refreshing the same session within the
`GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL`.

To ensure a non-synchronized client synchronizes to the correct refresh
token state, the session's refresh token counter is incremented only on
valid refresh token use.

Please check the massive suite of tests (>700 LOC) which exercise every
possible combination to ensure correctness of the algorithm. The
coverage here is above 95% (of the lines that can be covered).

**Obs... (continued)

374 of 442 new or added lines in 8 files covered. (84.62%)

13786 of 20270 relevant lines covered (68.01%)

79.51 hits per line