Supabase

Protect routes with Supabase-issued tokens when your app already uses Supabase Auth as the identity provider.

Protect routes with Supabase-issued tokens when your app already uses Supabase Auth as the identity provider.

Last reviewed: 2026-03-06

When to use this

Use this approach when you want a config-first Cloudflare Worker gateway behavior that is already implemented in the repository and covered by tests or canonical examples.

What this does not do

• It does not add unsupported product features such as rate limiting, caching, API keys, analytics, or OpenAPI generation.

• It does not replace upstream application logic that still belongs in your services.

• It does not remove the need to validate environment variables, bindings, and route intent before deploy.

Repo-grounded example

{
  "authorizer": {
    "type": "supabase",
    "jwt_secret": "$env.SUPABASE_JWT_SECRET",
    "issuer": "https://project.supabase.co/auth/v1",
    "audience": "authenticated"
  },
  "paths": [
    {
      "method": "POST",
      "path": "/api/v1/supabase/auth",
      "integration": { "type": "supabase_passwordless_auth" }
    },
    {
      "method": "POST",
      "path": "/api/v1/supabase/verify",
      "integration": { "type": "supabase_passwordless_verify" }
    }
  ]
}

This example is grounded in the current implementation shape: JSON config, path-based routing, optional auth, request mapping, and Worker-native integrations.

Troubleshooting

• Confirm the route path and HTTP method match what the worker receives.

• Confirm the config source is the one you expect: local file, KV, or SAG_API_CONFIG_JSON.

• Confirm required bindings and environment variables are present before debugging downstream logic.

• Run the existing tests in the main gateway repo when a config change appears correct but runtime behavior disagrees.

Related docs

• supabase otp

• authorizer

• gateway troubleshooting matrix