Custom OIDC Providers for Supabase Auth

Supabase Auth ships with over 20 built-in social providers: Google, GitHub, Apple, and more. But what about your company's SAML-to-OIDC bridge? A regional identity provider required for compliance? Your self-hosted GitHub Enterprise? Until now, if your identity provider wasn't on the built-in list, you were stuck.

Today we're launching Custom OIDC Providers, letting you connect any standards-compliant OpenID Connect identity provider to your Supabase project. Once configured, custom providers work just like built-in ones: same sign-in flow, same client libraries, same RLS enforcement.

Why We Built This

Built-in providers cover the most common cases, but not every identity provider fits neatly into that list:

Regional compliance: Government or industry-specific providers mandated in certain regions.
Self-hosted providers: GitHub Enterprise Server, GitLab self-managed, or any on-premise OAuth2 service.
Niche providers: Gaming platforms, healthcare identity networks, or industry-specific SSO systems.

Last year, we shipped OAuth 2.1 server capabilities so your Supabase project can be an identity provider. Custom providers complete the picture from the other direction, now your project can also consume any external identity provider.

Adding a Custom Provider

Supply your provider's issuer URL, client credentials, and scopes. Supabase handles the rest. The discovery document, endpoints, and JWKS are resolved automatically from {issuer}/.well-known/openid-configuration.

const { data, error } = await supabase.auth.admin.customProviders.createProvider({
  provider_type: 'oidc',
  identifier: 'custom:my-provider',
  name: 'My Provider',
  client_id: 'your-client-id',
  client_secret: 'your-client-secret',
  issuer: 'https://auth.example.com',
  scopes: ['openid', 'profile', 'email'],
})

The openid scope is always included automatically, and ID tokens are verified against the provider's JWKS.

You can also create providers from the Supabase Dashboard: go to Authentication > Sign In / Providers, scroll to the Custom Providers section at the bottom, and click New Provider.

Once a custom provider is created and enabled, your users sign in through the same flow they'd use with any built-in provider. No special handling needed on the client side.

// JavaScript
const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'custom:my-provider',
})

dart

// Flutter
await supabase.auth.signInWithOAuth(
  OAuthProvider('custom:my-provider'),
);

swift

// Swift
try await supabase.auth.signInWithOAuth(
  provider: "custom:my-provider",
  redirectTo: URL(string: "my-custom-scheme://my-app-host")
)

Behind the scenes, the auth server handles the full OAuth flow: redirecting to the external provider, exchanging the authorization code for tokens, fetching user profile data, and creating or linking the user in your Supabase project.

Key Features

PKCE by Default

Every custom provider has PKCE (Proof Key for Code Exchange) enabled by default. The auth server generates the code challenge and verifier automatically during the authorization flow, no client-side PKCE logic required. This protects against authorization code interception attacks out of the box if supported by the provider.

Authorization Params

Append extra query parameters to the provider's authorization URL. Useful for requesting consent screens, offline access, or login hints:

json

{
  "prompt": "consent",
  "access_type": "offline",
  "login_hint": "[email protected]"
}

Multi-Platform Apps

If your app uses different client IDs per platform (web, iOS, Android), use acceptable_client_ids to list additional client IDs accepted for audience validation in OIDC ID tokens:

const { data, error } = await supabase.auth.admin.customProviders.createProvider({
  provider_type: 'oidc',
  identifier: 'custom:multi-platform-app',
  name: 'Multi-Platform App',
  client_id: 'web-client-id',
  client_secret: 'your-client-secret',
  issuer: 'https://app.example.com',
  scopes: ['openid', 'profile', 'email'],
  acceptable_client_ids: ['ios-client-id', 'android-client-id'],
})

Email-Optional Providers

Not every identity provider returns an email address. Set email_optional: true to allow sign-in without one: useful for gaming platforms, device-based identity, or providers that use phone numbers as the primary identifier.

Managing Providers

Custom providers are fully manageable through both the Dashboard and the auth Admin API.

List all custom providers
Update any field except provider_type and identifier: rotate secrets, change scopes, toggle enabled state
Delete providers you no longer need

// List all custom providers
const { data, error } = await supabase.auth.admin.customProviders.listProviders()

// Update a provider
const { data, error } = await supabase.auth.admin.customProviders.updateProvider(
  'custom:my-provider',
  {
    name: 'Updated Provider Name',
    scopes: ['profile', 'email', 'groups'],
  }
)

// Delete a provider
const { data, error } =
  await supabase.auth.admin.customProviders.deleteProvider('custom:my-provider')

You can add up to 3 custom providers per project. If you need more, contact support.

Getting Started

Go to Authentication > Sign In / Providers in the Dashboard and scroll to the Custom Providers section
Click New Provider and choose your configuration method
Enter your identity provider's credentials and endpoints
Copy the Callback URL and configure it in your external IdP
Call signInWithOAuth with your custom: provider identifier

For the full API reference and detailed configuration options, check out the Custom OAuth/OIDC Providers documentation.