Conversation
tvi
force-pushed
the
t/jwt
branch
10 times, most recently
from
3745f0b to
0b7029c
Compare
Dashboard and API auth were tied to Supabase-specific HMAC JWT configuration
(`SUPABASE_JWT_SECRETS`) and Supabase-specific headers. That made it hard to
support other auth providers and forced provider-specific settings to spread
across several environment variables.
This change introduces one generic auth-provider JWT verification path that
supports both OIDC-compliant issuers (asymmetric keys, JWKS auto-discovered)
and non-OIDC HMAC-signed JWTs. It keeps the old Supabase headers as
compatibility aliases, while adding provider-neutral bearer token and team
header schemes.
- Add shared auth-provider JWT verification with OIDC and bearer (HMAC)
verifier strategies under `packages/auth/pkg/auth/`.
- Replace API/dashboard service-level `SUPABASE_JWT_SECRETS` with one
structured `AUTH_PROVIDER_CONFIG` JSON value, defaulted (in Terraform) to
the existing Supabase JWT secret wrapped in a `bearer` entry.
- Support multiple OIDC issuers and multiple bearer-token sources at once,
useful during migrations and multi-tenant deployments.
- For OIDC entries, fetch the discovery document at startup, cross-check
`issuer`, and resolve `jwks_uri` from it. JWKS HTTPS is required.
Lookups/caching/refresh use `github.com/MicahParks/keyfunc/v3`/`jwkset`.
Fail-fast on discovery errors.
- Per-entry audience matching with `MatchAny` (default) or `MatchAll`.
- Per-entry `claimMappings.username.claim` (default `sub`) resolves directly
to an internal UUID; no email fallback.
- Wire auth-provider bearer token and `X-Team-Id` team header in both API
and dashboard API, while keeping Supabase headers as compatibility aliases.
Example with one OIDC issuer and one bearer source (e.g. during migration or
key rotation):
```json
{
"jwt": [
{
"issuer": {
"url": "https://issuer.example.com",
"discoveryURL": "https://issuer.example.com/.well-known/openid-configuration",
"audiences": ["dashboard-api"],
"audienceMatchPolicy": "MatchAny"
},
"claimMappings": { "username": { "claim": "sub" } },
"jwksCacheDuration": "5m"
}
],
"bearer": [
{
"hmac": { "secrets": ["legacy-secret"] },
"claimMappings": { "username": { "claim": "sub" } }
}
]
}
```
Co-authored-by: Jakub Dobry <dobrac@users.noreply.github.com>
❌ 80 Tests Failed:
View the full list of 80 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Dashboard and API auth were tied to Supabase-specific HMAC JWT configuration
(
SUPABASE_JWT_SECRETS) and Supabase-specific headers. That made it hard tosupport other auth providers and forced provider-specific settings to spread
across several environment variables.
This change introduces one generic auth-provider JWT verification path that
supports both OIDC-compliant issuers (asymmetric keys, JWKS auto-discovered)
and non-OIDC HMAC-signed JWTs. It keeps the old Supabase headers as
compatibility aliases, while adding provider-neutral bearer token and team
header schemes.
verifier strategies under
packages/auth/pkg/auth/.SUPABASE_JWT_SECRETSwith onestructured
AUTH_PROVIDER_CONFIGJSON value, defaulted (in Terraform) tothe existing Supabase JWT secret wrapped in a
bearerentry.useful during migrations and multi-tenant deployments.
issuer, and resolvejwks_urifrom it. JWKS HTTPS is required.Lookups/caching/refresh use
github.com/MicahParks/keyfunc/v3/jwkset.Fail-fast on discovery errors.
MatchAny(default) orMatchAll.claimMappings.username.claim(defaultsub) resolves directlyto an internal UUID; no email fallback.
X-Team-Idteam header in both APIand dashboard API, while keeping Supabase headers as compatibility aliases.
Example with one OIDC issuer and one bearer source (e.g. during migration or
key rotation):
{ "jwt": [ { "issuer": { "url": "https://issuer.example.com", "discoveryURL": "https://issuer.example.com/.well-known/openid-configuration", "audiences": ["dashboard-api"], "audienceMatchPolicy": "MatchAny" }, "claimMappings": { "username": { "claim": "sub" } }, "jwksCacheDuration": "5m" } ], "bearer": [ { "hmac": { "secrets": ["legacy-secret"] }, "claimMappings": { "username": { "claim": "sub" } } } ] }