Metabase SSO: Setup Guide for Google, SAML, LDAP

Single Sign-On (SSO) lets your team log into Metabase using your corporate directory or identity provider instead of managing separate passwords. This guide walks you through setting up Google Sign-In, SAML, or LDAP for Metabase, configuring group mappings, and troubleshooting common errors.

What is Metabase SSO? Why You Need It

Metabase SSO eliminates the need for users to remember another password. Instead, they authenticate through an external identity provider (IdP) like Google Workspace, Microsoft Entra ID, Okta, or your on-premise Active Directory. When SSO is enabled, users click a single sign-in button, authenticate with their IdP, and are automatically logged into Metabase.

The benefits are real. Admins no longer need to manually create Metabase accounts or reset forgotten passwords. Access control is centralized: when someone leaves your company, deprovisioning them in your directory automatically revokes their Metabase access. Group mappings sync organizational roles from your IdP to Metabase permissions without manual intervention. And for compliance-heavy industries, SSO audit logs track exactly who logged in and when.

SSO is particularly critical if you have more than five users sharing dashboards. At that scale, password sprawl becomes a security and support nightmare. SSO also supports multi-factor authentication (MFA) through your IdP, which is often a requirement for regulated environments. Metabase tracks SSO logins separately, so you can audit exactly which users are active.

Metabase SSO Methods by Edition: Quick Comparison

Metabase supports four SSO methods, but availability depends on your edition. Open Source is free but has limited SSO options. Pro costs $1 per user per month (billed annually) and adds SAML, LDAP, and JWT. Enterprise adds multi-IdP support and advanced group mapping.

SSO Method	Open Source	Pro	Enterprise	When to Use
Google Sign-In	Yes	Yes	Yes	Google Workspace teams, teams wanting MFA without config
LDAP	No	Yes	Yes	On-premise Active Directory, OpenLDAP, custom directory
SAML	No	Yes	Yes	Enterprise IdPs (Okta, Entra ID, Keycloak, Auth0)
JWT	No	Yes	Yes	Custom or embedded authentication, multi-tenant setups

Open Source users can only use Google Sign-In. If you run Metabase on-premise and use Active Directory, you need at least the Pro edition. SAML and JWT are Pro/Enterprise only, though both are powerful enough for any team size.

One important note: Metabase charges per user for Pro and Enterprise editions. Each SSO user who logs in counts as a billable user, so group mapping doesn't reduce your license cost. It just makes provisioning automatic.

Setting Up Google Sign-In (For All Editions)

Google Sign-In is the easiest SSO option to set up and works on Open Source. Use it if your team already uses Google Workspace or personal Google accounts, and if you want enforced MFA.

Step 1: Create an OAuth 2.0 app in Google Cloud Console.

Go to the Google Cloud Console. Create a new project or select an existing one. Navigate to "APIs & Services" > "Credentials." Click "Create Credentials" > "OAuth 2.0 Client IDs." Choose "Web application." Under "Authorized Redirect URIs," add your Metabase URL followed by /auth/sso/callback. For example, if Metabase is at your domain, the redirect URI would be your domain with /auth/sso/callback appended. This must be exact; a trailing slash mismatch causes authentication to fail.

Copy your Client ID and Client Secret. You'll need these in the next step.

Step 2: Enable Google Sign-In in Metabase Admin.

Log into Metabase as an admin. Go to Admin > Settings > Authentication > Google Sign-In. Paste your Client ID and Client Secret. If your team is not on Google Workspace, you must also specify the allowed Google domain (e.g., @mycompany.com). Save.

Test by logging out, then clicking the Google Sign-In button on the login page. You should be redirected to Google, then back to your Metabase dashboard.

Common Error: Redirect URI Mismatch

This is the most frequent Google SSO error. You'll see "redirect_uri_mismatch" if the URL you entered in Google Cloud Console doesn't match the actual Metabase URL. This often happens because:

• You used HTTP in Metabase but HTTPS in Google Cloud (or vice versa)
• You included a trailing slash in one but not the other
• Your Metabase domain is behind a reverse proxy and doesn't match the public URL

If you deploy Metabase with the MB_SITE_URL environment variable, make sure the value matches your redirect URI exactly. Test by copying the redirect URI from Google Cloud and pasting it into your browser; it should load your Metabase login page.

Setting Up SAML (For Pro & Enterprise)

SAML is the standard for enterprise identity providers. Use SAML if you have Okta, Microsoft Entra ID, Keycloak, Auth0, or another corporate IdP.

Step 1: Gather IdP Information

Before configuring Metabase, you need three pieces from your identity provider:

1. Issuer (Entity ID): A unique identifier for your IdP, often formatted as a URL. This tells Metabase which IdP to trust.
2. SAML Login URL: The endpoint where Metabase redirects users to authenticate.
3. X.509 Certificate: A public certificate used to verify the IdP's responses. This is usually a PEM-formatted file or a long text block.

Each IdP calls these fields differently, but they're always available. In Okta, they're in the "Sign On" tab of your SAML app. In Entra ID, they're on the "SAML Certificates" tab.

Step 2: Create a SAML App in Your IdP

Add Metabase as a new SAML application. You'll need to provide:

• Assertion Consumer Service (ACS) URL: This is where your IdP sends authentication responses. Use your Metabase domain with /auth/sso/callback appended.
• Entity ID / Audience Restriction: Set this to your Metabase domain with /auth/sso appended.

These field names vary by IdP, but the concept is the same: you're telling your IdP how to talk back to Metabase.

Step 3: Configure SAML in Metabase Admin

Go to Admin > Settings > Authentication > SAML. Fill in:

• SAML Identity Provider URL: Your IdP's issuer URL
• SAML Identity Provider Certificate: Paste the X.509 certificate in PEM format
• SAML Identity Provider Issuer: The issuer identifier from your IdP

Scroll down and configure User Attribute Mappings. These tell Metabase how to extract user information from the SAML response. Common attributes include email, first name, and last name. Your IdP admin or documentation will tell you the exact attribute names or namespace URIs to use.

Test by logging out and attempting to sign in with SAML.

Common SAML Errors and Fixes

• "Issuer mismatch": The issuer in your IdP response doesn't match the issuer URL you entered in Metabase. Double-check spelling and copy-paste; typos are common.
• "Certificate validation failed": Your certificate is expired or malformed. Verify you're using the PEM-formatted certificate, not the base64-encoded version. It should start with -----BEGIN CERTIFICATE-----.
• "SSO URL not found": Your IdP is sending responses to the wrong endpoint. Confirm your ACS URL in the IdP matches your Metabase domain with /auth/sso/callback exactly.

Metabase logs SAML errors in detail. Check the server logs (or your container logs if using Docker) for the exact error message from your IdP.

Setting Up LDAP (For Open Source via Pro, All On-Prem)

LDAP is the protocol for on-premise and hybrid directories like Active Directory or OpenLDAP. Use LDAP if you're not ready to adopt a cloud IdP.

Step 1: Prepare Your LDAP Directory

Metabase needs three fields on each user:

• Email (required)
• First Name (givenName in LDAP)
• Last Name (sn in LDAP)

Before enabling LDAP, verify these attributes exist in your directory. In Active Directory, run a query to confirm these attributes are populated on user objects.

Step 2: Configure LDAP in Metabase Admin

Go to Admin > Settings > Authentication > LDAP. Enter:

• LDAP Host: Your LDAP server address (e.g., ldap.yourcompany.com or an IP address)
• LDAP Port: Usually 389 (unencrypted) or 636 (TLS)
• LDAP Username: The service account DN (distinguished name)
• LDAP Password: The service account password
• User Search Base: The LDAP path where user objects live (e.g., ou=Users,dc=company,dc=com)
• User Filter: A filter to find users. Often (&(objectClass=person)(uid={login})) for OpenLDAP or (sAMAccountName={login}) for Active Directory

Click Save and Test. Metabase will attempt to bind to your LDAP server and fetch a test user.

Common LDAP Error: User Search Base Misconfiguration

If test login fails, the most common cause is an incorrect search base or filter. Try:

• Testing your LDAP connection from your command line to verify connectivity
• Checking that your service account has read permissions on the Users organizational unit
• Confirming the user filter matches your directory schema (Active Directory vs. OpenLDAP use different object classes)

Configuring Group Mapping (SAML, LDAP, JWT)

Group mapping synchronizes user roles from your IdP to Metabase without manual admin work. When a user logs in via SSO, Metabase checks their groups in your IdP and assigns them to the corresponding Metabase groups automatically.

Plan Before You Start

Before enabling group mapping, list your Metabase groups and identify the corresponding IdP groups:

Metabase Group	IdP Group	Permissions
Analysts	analytics-team	View dashboards, edit saved questions
Managers	sales-management	View + edit sales dashboards, create reports
Admins	metabase-admins	Full admin access

Enable Group Mapping

For SAML, go to Admin > Settings > Authentication > SAML and scroll to Synchronize group memberships. Enable it. You'll see a list of your current Metabase groups. For each one, enter the corresponding group name or identifier from your IdP (e.g., "analytics-team" or a group's LDAP DN).

For LDAP, go to Admin > Settings > Authentication > LDAP and scroll to Group mappings. Follow the same process.

Test by logging in as a user who belongs to a mapped group in your IdP. They should automatically join the corresponding group in Metabase.

Security Best Practices and Troubleshooting

Do NOT Disable Password Login Immediately

This is the biggest mistake. Before disabling password authentication, confirm SSO is working and at least one admin can log in via SSO. If you disable password login and SSO breaks, you'll be locked out of your entire Metabase instance.

The safe sequence:

1. Enable SSO and test with a non-admin user
2. Confirm at least one admin can log in via SSO
3. Inform your team that SSO is available
4. After one week of stable SSO, disable password login in Admin > Settings > Authentication
5. Keep one backup admin account with password enabled (don't delete it)

Redirect URI and Site URL Must Match

If you move Metabase to a new domain or switch protocols, update both your site configuration and the redirect URI in your IdP. This is the single most common SSO failure after initial setup.

Monitor SSO Audit Logs

Enable audit logging in Admin > Settings > Admin > Audit. Check logs regularly to confirm SSO users are the expected people. If unexpected users appear, investigate whether your IdP security has been compromised.

Use a Service Account for LDAP

Never use a personal account as the LDAP service account. Create a dedicated low-privilege account in your directory with read-only access to user attributes. This limits damage if credentials are exposed.

Common Errors After Initial Setup

• "User not found": The user exists in your IdP but their email doesn't match a Metabase email. Check your attribute mappings.
• "SSO login loops": You're redirected to SSO, authenticated, but then redirected back to the login page. This usually means the certificate is expired or the issuer URL is wrong.
• "Group mapping not working": The group names in your mapping don't match your IdP group names exactly. Check case sensitivity and spelling.

Next Steps: Managed vs Self-Hosted Metabase

Once SSO is working, your team can focus on building dashboards instead of managing authentication infrastructure. If you're self-hosting Metabase, you also handle backups, upgrades, and monitoring. Many teams eventually move to managed Metabase Cloud or a managed hosting provider to reduce operational overhead.

Opsily manages Metabase hosting end-to-end, including SSO setup, configuration, and ongoing maintenance. This lets you offload infrastructure concerns and focus on analytics. If your team uses Metabase alerts and Slack integrations, managed hosting also ensures these critical workflows stay online.

For teams running Metabase on Kubernetes, check out our guide on Metabase Helm chart deployment to ensure your SSO configuration persists across upgrades.

Frequently Asked Questions

What is SSO authentication?

SSO (Single Sign-On) is a system that lets users log into multiple applications using a single set of credentials managed by a central identity provider. Instead of Metabase storing passwords, it delegates authentication to your corporate directory or a trusted third party like Okta or Google.

Why would I use SSO instead of Metabase passwords?

SSO centralizes access control. When someone leaves your company, you revoke their access in one place (your directory), and they're automatically locked out of all tools, including Metabase. It also reduces password fatigue and often includes multi-factor authentication through your IdP.

Can I use SSO on Metabase Open Source?

Yes, but only Google Sign-In is available on Open Source. SAML, LDAP, and JWT require Metabase Pro or Enterprise.

What happens to my Metabase password if I enable SSO?

Your Metabase password still exists, but you won't use it. You log in through your identity provider instead. If SSO is disabled later, you can still use your password. If you forget it, ask your Metabase admin to reset it.

Do SSO users cost extra?

Yes, if you're on Pro or Enterprise. Each SSO user who logs in is billed as an active user. Metabase tracks monthly active users (MAU), so the cost is based on who actually logs in, not who has an account.

What if I want to switch identity providers, like from Okta to Entra ID?

You can run both at the same time (Pro/Enterprise) or disable the old provider and enable the new one. If you disable the old provider, users lose access, so give your team a migration window and test with a pilot group first.

Can I map multiple IdP groups to a single Metabase group?

Not directly in the basic group mapping UI. For complex scenarios, use JWT with custom group logic or contact Metabase support for Enterprise options.

Why am I locked out after enabling SSO?

This usually means you disabled password login before testing SSO thoroughly, or SSO is broken and no one can authenticate. To recover, temporarily disable SSO in Metabase's configuration file (or environment variables) and log in with your password. Then debug the SSO setup before re-enabling it.

The Bottom Line

Metabase SSO reduces authentication overhead and improves security by centralizing access control. Google Sign-In is the fastest path for teams already using Google. SAML is the enterprise standard for Okta, Entra ID, and other corporate IdPs. LDAP works well if you're invested in on-premise directories.

Always test SSO with a non-admin user before disabling password login. Keep at least one backup admin account. Once SSO is stable, your team can spend time on dashboards instead of password resets. To remove the infrastructure burden entirely, host Metabase with Opsily and let us manage SSO, upgrades, and backups for you.