Third-Party Auth with WorkOS fails with JWSInvalidSignature

[Zhreyu]

Bug report

Describe the bug

WorkOS Third-Party Auth is configured and enabled, but all authenticated requests to PostgREST fail with:
{"code":"PGRST301","details":null,"hint":null,"message":"JWSError JWSInvalidSignature"}

To Reproduce

1. Configure WorkOS as Third-Party Auth provider in Supabase Dashboard
2. Set issuer URL: https://api.workos.com/user_management/<client_id>
3. Configure JWT Template in WorkOS with role: "authenticated"
4. Use @supabase/supabase-js with accessToken option to pass WorkOS JWT
5. Make any authenticated query → fails with JWSInvalidSignature

Expected behavior

Supabase should verify the JWT signature using the public key from WorkOS JWKS.

System information

• Supabase: Hosted (not self-hosted)
• OS: N/A (hosted)
• Browser: N/A (server-side)
• supabase-js version: latest

Additional context

Root Cause Analysis

I verified the JWT is valid:

• iss matches configured issuer
• kid matches key in JWKS
• role: "authenticated" present
• alg: RS256 matches JWKS

The issue: WorkOS serves JWKS at a non-standard path that differs from the issuer URL:

# OIDC Discovery works and returns jwks_uri:
curl https://api.workos.com/user_management/client_XXX/.well-known/openid-configuration
# Returns: { "jwks_uri": "https://api.workos.com/sso/jwks/client_XXX" }

# Correct JWKS path (from jwks_uri):
curl https://api.workos.com/sso/jwks/client_XXX  # 200 

# Standard .well-known paths (what Supabase appears to try):
curl https://api.workos.com/user_management/client_XXX/.well-known/jwks      # 404 
curl https://api.workos.com/user_management/client_XXX/.well-known/jwks.json # 404 

Supabase is not using the jwks_uri from OIDC discovery. It appears to hardcode a .well-known/jwks path under the issuer, which doesn't exist for WorkOS.

Proposed Fix

When verifying Third-Party Auth JWTs:

1. Fetch {issuer}/.well-known/openid-configuration
2. Use the jwks_uri from that response
3. Fetch JWKS from the discovered URL

Related Issues

• Same issue with Clerk (JWKS path mismatch) link
• .well-known/jwks.json to use in REST API #1724 - Similar fix was applied to Auth but not other services

Workaround

Currently using service role key, which bypasses RLS entirely. This is not acceptable for production with row-level security requirements.

Request: If there's a workaround or configuration I'm missing, please let me know. I've followed the WorkOS Third-Party Auth docs exactly but still getting this error.

I'd appreciate any guidance on:

1. Is there a way to manually specify the JWKS URL in the dashboard?
2. Is there a timeline for fixing the JWKS discovery to use jwks_uri from OIDC?
3. Any other workaround besides using service role key (which bypasses RLS)?

Happy to provide more debug info if needed.

[victoriahughes497-max]

Thanks for the detailed write-up! This JWKS mismatch makes sense—Supabase seems to assume a fixed .well-known/jwks path. Any chance the team can add support for using jwks_uri from OIDC discovery, or is there a temporary way to override the JWKS URL in the dashboard?

…

On Wed, Apr 8, 2026, 2:53 AM Shreyas S ***@***.***> wrote: *Zhreyu* created an issue (supabase/auth#2476) <#2476> Bug report Describe the bug WorkOS Third-Party Auth is configured and enabled, but all authenticated requests to PostgREST fail with: {"code":"PGRST301","details":null,"hint":null,"message":"JWSError JWSInvalidSignature"} To Reproduce 1. Configure WorkOS as Third-Party Auth provider in Supabase Dashboard 2. Set issuer URL: https://api.workos.com/user_management/<client_id> 3. Configure JWT Template in WorkOS with role: "authenticated" 4. Use @supabase/supabase-js with accessToken option to pass WorkOS JWT 5. Make any authenticated query → fails with JWSInvalidSignature Expected behavior Supabase should verify the JWT signature using the public key from WorkOS JWKS. System information - Supabase: Hosted (not self-hosted) - OS: N/A (hosted) - Browser: N/A (server-side) - supabase-js version: latest Additional context Root Cause Analysis I verified the JWT is valid: - iss matches configured issuer - kid matches key in JWKS - role: "authenticated" present - alg: RS256 matches JWKS *The issue:* WorkOS serves JWKS at a non-standard path that differs from the issuer URL: # OIDC Discovery works and returns jwks_uri: curl https://api.workos.com/user_management/client_XXX/.well-known/openid-configuration# Returns: { "jwks_uri": "https://api.workos.com/sso/jwks/client_XXX" } # Correct JWKS path (from jwks_uri): curl https://api.workos.com/sso/jwks/client_XXX # 200 # Standard .well-known paths (what Supabase appears to try): curl https://api.workos.com/user_management/client_XXX/.well-known/jwks # 404 curl https://api.workos.com/user_management/client_XXX/.well-known/jwks.json # 404 Supabase is not using the jwks_uri from OIDC discovery. It appears to hardcode a .well-known/jwks path under the issuer, which doesn't exist for WorkOS. Proposed Fix When verifying Third-Party Auth JWTs: 1. Fetch {issuer}/.well-known/openid-configuration 2. Use the jwks_uri from that response 3. Fetch JWKS from the discovered URL Related Issues - Same issue with Clerk (JWKS path mismatch) link <supabase/realtime#1791> - supabase/auth#1724 <#1724> - Similar fix was applied to Auth but not other services Workaround Currently using service role key, which bypasses RLS entirely. This is not acceptable for production with row-level security requirements. *Request:* If there's a workaround or configuration I'm missing, please let me know. I've followed the WorkOS Third-Party Auth docs <https://supabase.com/docs/guides/auth/third-party/workos> exactly but still getting this error. I'd appreciate any guidance on: 1. Is there a way to manually specify the JWKS URL in the dashboard? 2. Is there a timeline for fixing the JWKS discovery to use jwks_uri from OIDC? 3. Any other workaround besides using service role key (which bypasses RLS)? Happy to provide more debug info if needed. — Reply to this email directly, view it on GitHub <#2476>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B72GTP6B5HXC5RWPW7GUAET4UXZM3AVCNFSM6AAAAACXQPEHD2VHI2DSMVQWIX3LMV43ASLTON2WKOZUGIZDENRWG42TSNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>