Custom Identity Providers

Supabase Auth ships with 20+ built-in providers. For providers not on that list, Custom Identity Providers lets you add them in two ways:

• OIDC providers — supply an issuer URL and Supabase auto-fetches the discovery document, JWKS, and endpoints automatically.
• OAuth2-only providers — supply the authorization, token, and userinfo endpoint URLs directly for providers that don't expose an OIDC discovery document.

Once configured, your users sign in with signInWithOAuth({ provider: 'custom:my-provider' }), the same call used for any built-in provider. Same client libraries (JS, Flutter, Swift, Kotlin), same RLS enforcement, no special client-side handling required.

Key benefits

1. Auto-discovery (OIDC): Supply an issuer URL and Supabase resolves the discovery document, JWKS, and endpoints automatically. No manual endpoint wiring.
2. Manual endpoint control (OAuth2): Supply the authorization URL, token URL, and userinfo URL directly for providers without OIDC discovery.
3. Any provider: GitHub Enterprise Server, regional compliance IdPs, internal OAuth2 servers, and proprietary identity systems. If it speaks OAuth2 or OIDC, it works.
4. PKCE by default: All custom providers use PKCE (Proof Key for Code Exchange) automatically. No client-side changes needed.
5. Same sign-in flow: One code path for all OAuth flows. Same client libraries and RLS enforcement as built-in providers.
6. Multi-platform support: List additional client IDs via acceptable_client_ids for web, iOS, and Android apps.
7. Full management via Dashboard and Admin API: Create, update, rotate secrets, toggle enabled state, or delete providers without touching your code.
8. Email-optional: Providers that don't return an email address are supported via the email_optional setting.
9. Custom authorization params: Append extra query parameters to the authorization URL for consent screens, offline access, login hints, and more.

Custom Identity Providers are valuable for:

• Teams using a SAML-to-OIDC bridge, GitHub Enterprise Server, or GitLab self-managed for SSO
• Applications in regulated industries with mandated regional identity providers
• Internal tools authenticating against a company's custom OAuth2 server
• Platforms with proprietary OAuth2 implementations that don't expose a discovery document
• Platforms integrating with niche identity networks (gaming, healthcare, device-based auth)
• Multi-platform apps (web, iOS, Android) needing unified auth across client IDs
• Enterprise buyers evaluating Supabase Auth for compliance-sensitive deployments
• Developers who need precise control over endpoint configuration