• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

supabase / auth / 18910658377
69%

Build:
DEFAULT BRANCH: master
Ran 29 Oct 2025 02:14PM UTC
Jobs 1
Files 167
Run time 3min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

29 Oct 2025 02:06PM UTC coverage: 68.012% (+0.5%) from 67.547%
18910658377

push

github

web-flow
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%)

1 existing line in 1 file now uncovered.

13786 of 20270 relevant lines covered (68.01%)

79.51 hits per line

New Missed Lines in Diff

Lines Coverage ∆ File
2
29.5
0.0% internal/api/oauthserver/handlers.go
2
93.33
-6.67% internal/api/token_refresh.go
6
70.43
4.12% internal/models/refresh_token.go
10
78.99
0.67% internal/models/sessions.go
16
75.77
-0.87% internal/models/user.go
32
81.42
7.44% internal/tokens/service.go

Uncovered Existing Lines

Lines Coverage ∆ File
1
81.42
7.44% internal/tokens/service.go
Jobs
ID Job ID Ran Files Coverage
1 18910658377.1 29 Oct 2025 02:14PM UTC 167
68.01
GitHub Action Run
Source Files on build 18910658377
  • Tree
  • List 167
  • Changed 7
  • Source Changed 0
  • Coverage Changed 7
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • dea5b8e5 on github
  • Prev Build on master (#18906175758)
  • Next Build on master (#18932050571)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2025 Coveralls, Inc