Skip to content
ReviveDB
Blog

"Sign in with Supabase" doesn't work yet: GET /v1/profile rejects OAuth tokens

By AK

We built a "Continue with Supabase" sign-in button for ReviveDB and removed it the same day. The blocker is a Management API restriction that the current OpenAPI reference does not make clear. We tested it again with a real OAuth app token on 5 August 2026.

The blocker

A sign-in flow needs to know who authorized it. The Supabase Management API has an endpoint for that. GET /v1/profile returns gotrue_id, primary_email and username, and it sits in the OpenAPI spec like any other endpoint. Call it with an OAuth access token and it returns:

HTTP 401: "GET /v1/profile does not support oauth access yet"

It only accepts personal access tokens, the kind the Supabase CLI uses. So an OAuth integration can list the user's projects, deploy their Edge Functions and read their database config, but it can't find out who they are.

What the live OAuth probe returns

  • GET /v1/profile → HTTP 401: "does not support oauth access yet"
  • GET /v1/projects/{ref}/database/jit/list → HTTP 401 with the same OAuth restriction
  • POST /v1/projects/{ref}/database/jit → HTTP 406: "Failed to get user's JIT access for project"

That last response matters for Supabase backups without a shared database password: the API reference advertises a database:read OAuth scope for JIT, but the live endpoint returns HTTP 406 for the OAuth app token. Supabase does not document the cause. ReviveDB now uses a separate OAuth-managed database route for backup jobs.

The workaround we didn't ship

GET /v1/organizations/{slug}/members does work with OAuth tokens and includes emails. But it tells you who is in the organization, not which member clicked "Authorize". On a single-member org you can guess right. On a two-member org, guessing wrong signs someone in as their colleague. That is an account takeover with extra steps, so no.

What we do instead

ReviveDB signs you in with Google or a magic link, and Supabase gets connected after that, as a credential on your account. In hindsight the split is fine. Your ReviveDB login and your Supabase account don't have to share an email, so a work Supabase account can hang off a personal login without ceremony.

We kept the Supabase account-connection flow, but not the unsafe sign-in shortcut. The error says "yet", so Supabase may open /profile to OAuth apps later. When it does, we can add the sign-in button back without guessing a user's identity.

ReviveDB uses the working API routes to create recovery points covering the database and Auth, Storage files, Edge Functions and supported configuration. The database restore-tested and other artifacts checked separately.