Social login support
Supabase Auth provides social logins from multiple providers including Apple, GitHub, Slack, and others.
oauth & provider configuration
17 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
SSO availability and pricing
Supabase SSO using SAML 2.0 is available only for Team and Enterprise Plan customers.
Supported SSO identity providers
Supabase supports practically all identity providers that support the SAML 2.0 SSO protocol. Specifically documented providers include Google Workspaces (formerly G Suite), Azure Active Directory, and Okta. For other providers, contact support.
IdP-initiated login flow
IdP-initiated login is the recommended SSO flow. Users start their login from their identity provider (Okta, Azure AD, Google Workspace) by clicking an app tile or bookmark. This is the simplest and most common configuration, requires no domain configuration, and works automatically once SSO is enabled. Best for organizations with established IdP workflows, multiple SAML apps per domain (Dev, Staging, Prod), and simplest user experience.
SP-initiated login flow
SP-initiated login requires users to start their login at supabase.com by entering their email address, then being redirected to their identity provider. This flow requires configuring email domains to route users to the correct IdP. Best for users who bookmark supabase.com directly, organizations migrating from password authentication, and supporting domain-based automatic IdP routing.
SSO configuration key options
SSO configuration includes: (1) Login flows - choose between IdP-initiated, SP-initiated, or both; IdP-initiated is recommended and requires no domain configuration; (2) Email domains - required only if enabling SP-initiated login, associate one or more email domains with SSO provider, not required for IdP-initiated flow; (3) Auto-join - optionally allow users with matching domain to join organization automatically on SSO login, applies on every login not just first signup; (4) Default role for auto-joined users - choose role (Read-only, Developer, Administrator, Owner) for auto-joined users, Developer is recommended as default per principle of least privilege; (5) Invitation types - explicitly choose whether invitations require SSO authentication or allow non-SSO login, enables mixed authentication organizations.
SSO behavior for organization invites
When SSO is enabled for an organization, organization invites are restricted to company members belonging to the same identity provider.
SSO user cannot update or reset password
An SSO user will not be able to update or reset their password since the company administrator manages their access via the identity provider.
SSO and non-SSO accounts with same email are separate
If an SSO user with email alice@foocorp.com attempts to sign in with a GitHub account that uses the same email, a separate Supabase account is created and will not be linked to the SSO user's account. SSO and non-SSO accounts with the same email are treated as separate accounts. Identity linking is not supported for SSO-verified accounts.
SSO users see only invited or auto-joined organizations
SSO users will only see organizations and projects they have been invited to or auto-joined into.
Recommended SSO enablement workflow
The recommended workflow for enabling SSO is: (1) Create or verify at least one non-SSO owner account exists (required for safety); (2) Configure your SSO provider following provider-specific guides; (3) Start with auto-join disabled to test the configuration; (4) Test SSO login with your own account; (5) Once confirmed working, enable auto-join if desired; (6) Thoroughly test using SSO Testing and Best Practices guide; (7) Invite users to the organization or let them auto-join on login.
Converting non-SSO users to SSO
If a user is already a member of the organization under a non-SSO account, they must be removed and invited again with an SSO-required invitation to join under their SSO account.
Disabling SSO prevents all SSO users from signing in
If you disable or delete the SSO provider for an organization, all SSO users will immediately be unable to sign in.
Safety requirement for deleting SSO provider
The system requires at least one non-SSO owner account to exist before allowing SSO provider deletion. This prevents complete organization lockout. When you delete an SSO provider, all SSO members are automatically removed from the organization. Before disabling or deleting SSO, verify a non-SSO owner account exists and can log in, communicate to affected users in advance, and consider whether disabling is better than deleting if the change is temporary.
Revoking individual SSO user access
To revoke access for a specific SSO user without disabling the provider entirely, you may: (1) Remove or disable the user's account in your identity provider; (2) Downgrade or remove their permissions for any organizations in Supabase.
Multiple SSO providers in organization
Supabase supports multiple SSO providers within an organization for advanced use cases such as separate providers for development, staging, and production environments, different providers for different teams or business units, or gradual migration from one identity provider to another.
SSO and MCP enterprise-managed authentication
Once SSO is configured, you can let your identity provider automatically authorize MCP clients for your organization without individual members having to approve each one.