Custom Domain: JWT iss claim still points to .supabase.co after activation

[9M6]

Context

I have a Custom Domain addon (not vanity subdomain) that is fully active and serving traffic. After activating the custom domain and re-authenticating (signing out and back in), the JWT iss claim still references the original <project-ref>.supabase.co/auth/v1 URL rather than the custom domain.

Expected behavior

The Custom Domains documentation states:

Supabase Auth will use the custom domain immediately once activated.

I expected the iss claim in newly issued JWTs to reflect the custom domain (e.g. https://my-custom-domain.example.com/auth/v1), consistent with how OAuth callbacks and
SAML EntityID are updated.

Actual behavior

Newly issued JWTs (after re-auth) still contain:

{                                                                                                                                                                           
  "iss": "https://<project-ref>.supabase.co/auth/v1"   
}    

Questions

1. Is this by design? Does the iss claim intentionally remain tied to the original project ref URL even after a custom domain is activated?
2. If so, is this documented anywhere? The JWT Claims Reference shows project-ref.supabase.co as the example value but doesn't mention custom domain behavior.

This matters for anyone validating JWTs externally (e.g. in an Envoy proxy or a backend service) — if the iss doesn't match the custom domain, the issuer validation config needs to reference the original .supabase.co URL instead.

Thanks for any clarification!

[Nickalus12]

[9M6]

Is not that.

[9M6]

Both server, and client point to the custom domain.

[9M6]

At least verify the information before posting ai slop.

[HexNinja555]

Hello, yeah, this one trips people up 👍

This is actually expected behavior (even though the docs make it sound like everything switches over to the custom domain).

The iss claim is tied to Supabase’s Auth issuer identity, which is still the original:

https://<project-ref>.supabase.co/auth/v1

even when you enable a custom domain.

Why it works this way

The custom domain is mainly for:

• OAuth callbacks
• SAML configuration
• public-facing auth endpoints

But the JWT issuer (iss) stays consistent so that:

• existing tokens don’t break
• external services (proxies, backends) have a stable issuer
• Supabase’s internal signing/verification flow remains predictable

If they changed the issuer dynamically, it would cause issues for any system already validating tokens against the original issuer.

---

What you should do

For JWT validation (Envoy, backend, etc.), you should still use:

https://<project-ref>.supabase.co/auth/v1

as the issuer, even if your app uses a custom domain everywhere else.

---

Quick sanity check

If you hit:

https://<project-ref>.supabase.co/auth/v1/.well-known/jwks.json

you’ll see the keys used to validate those tokens — that’s what your verifier should trust.

---

Docs gap (you’re right)

You’re not wrong — this isn’t clearly documented right now.
The docs imply full domain replacement, but JWT issuer behavior isn’t called out.

---

TL;DR

• Custom domain ≠ JWT issuer
• iss stays on <project-ref>.supabase.co by design
• Use original domain for token validation

---

If you’re building anything strict (Envoy, API gateway, etc.), just lock issuer to the project-ref URL and you’ll be good.

Hope that saves you some time — I ran into the same confusion before 😄

[jebibot]

The documentation states:

Custom domains help you keep your APIs portable for the long term. By using a custom domain you can migrate from one Supabase project to another, or make it easier to version APIs in the future.

This issue would make this impossible as the JWTs are tied to the project's default domain.

[ldsenow]

consider to support custom domain? Otherwise, I would agree with that the Custom Domain feature is half-baked