GuidesSSO Setup

Enterprise

Set up Single Sign-On

Let your team sign in to Pipeboard with your corporate identity provider over SAML 2.0 — no separate Pipeboard password to manage, revoke, or audit. This guide is written for the IT or identity team that owns your IdP.

SSO is part of the Enterprise plan. Setup is not self-service — you configure your IdP, send us the metadata, and we activate the connection for your domain.

How it works

Pipeboard acts as the SAML service provider (SP). Your identity provider (IdP) stays the source of truth for who your employees are and how they authenticate.

User enters their work email

On the Pipeboard sign-in page they click “Continue with SSO” and type name@yourcompany.com. We match the domain to your connection.

We redirect them to your IdP

Your login page, your policies. MFA, device trust, conditional access and session lifetime are all enforced by you — Pipeboard never sees the password.

Your IdP posts a signed assertion back

The assertion goes to our ACS URL, where we validate the signature and the audience before trusting it.

The session is created

First-time users get a Pipeboard account provisioned automatically from the assertion. Returning users land back in the app.

What you need

Admin access to your IdP, the email domains your staff sign in with, and someone who can test the first login.

Supported protocol

SAML 2.0, with a persistent Name ID mapped to the work email address. Any standards-compliant IdP works.

Time to set up

The IdP side is a 10-minute custom SAML app. Activation on our side happens once you send us the metadata.

Step 1

Service provider details

These are the Pipeboard values your IdP will ask for. They are the same for every customer — copy them exactly, including the scheme and any trailing path.

ACS URL

Single sign-on URL · Reply URL · Assertion Consumer Service

https://daptmmcmcfyxwlghwmhk.supabase.co/auth/v1/sso/saml/acs

Entity ID

Audience URI · Audience Restriction · Identifier

https://daptmmcmcfyxwlghwmhk.supabase.co/auth/v1/sso/saml/metadata

SP metadata XML

For IdPs that prefer an upload or a metadata URL

https://daptmmcmcfyxwlghwmhk.supabase.co/auth/v1/sso/saml/metadata?download=true

Name ID format

Must map to the user’s primary work email address

Persistent

The Name ID format must be Persistent and it must resolve to the user's primary work email. If your IdP sends a different identifier on each login, every sign-in creates a brand-new empty account.

Step 2

Create the app in your IdP

Below are the exact paths for the three most common providers. Any SAML 2.0 IdP works — the fields are always the same four values from step 1.

Google Workspace

1Admin console → Apps → Web and mobile apps → Add app → Add custom SAML app.
2Name it “Pipeboard”, then download the IdP metadata XML on the Google Identity Provider details screen. Keep that file — you will send it to us.
3On Service provider details, paste the ACS URL and Entity ID from step 1.
4Set Name ID format to PERSISTENT and Name ID to Basic Information → Primary email.
5Add the attribute mappings from step 3, then finish and turn the app ON for the org units or groups that should have access.

Okta

1Admin → Applications → Create App Integration → SAML 2.0.
2Single sign-on URL = the ACS URL. Audience URI (SP Entity ID) = the Entity ID.
3Name ID format = Persistent. Application username = Email.
4Add the attribute statements from step 3.
5Assign the app to the groups that should have access, then copy the IdP metadata URL from the Sign On tab.

Microsoft Entra ID

1Entra admin center → Enterprise applications → New application → Create your own application → Integrate any other application.
2Single sign-on → SAML. Identifier (Entity ID) = the Entity ID. Reply URL = the ACS URL.
3Under Attributes & Claims, set the Unique User Identifier (Name ID) to user.mail with a persistent format.
4Add the claims from step 3.
5Assign users and groups, then copy the App Federation Metadata Url from the SAML certificates section.

Step 3

Attribute mapping

Only the email is required. The name attributes are optional but make the app — and your audit trail — much more readable.

Pipeboard attribute	Map from your directory	Required
email	Primary email address	Yes
first_name	Given name	Optional
last_name	Family name	Optional

Use exactly these attribute names on the Pipeboard side. If your IdP forces a URN-style claim name, send us the names you used and we will map them for you.

Step 4

Send us your metadata

SSO activation is handled by our team — there is no self-service screen for it yet. Email the details below and we will register the connection and confirm when it is live.

What to include in the email

Your IdP metadata — either the metadata URL or the downloaded XML file as an attachment.
Every email domain your staff sign in with, including aliases and subsidiaries (yourcompany.com, yourcompany.co.uk, …). A connection can cover several domains.
The name and email of one person who will run the first test login.
Any non-standard attribute names you used in step 3.
Whether you want SSO to be the only way in for your domain, so we can plan that with you.

Already talking to someone at Pipeboard? Reply on that thread instead — it keeps the context together.

Do not send us private keys or IdP admin credentials. The metadata XML contains only the public signing certificate, which is all we need.

Step 5

Test the login

1Open the Pipeboard sign-in page in a private window.
2Click “Continue with SSO” and enter a work email on one of the domains you registered.
3Confirm you are sent to your own IdP login screen, not a Pipeboard password prompt.
4Authenticate. You should land back inside Pipeboard with a session.
5Sign out and repeat. The second login must reuse the same account — if a fresh empty account appears, your Name ID is not persistent.

Signing in is not the same as joining your team

SSO controls who can authenticate. It does not automatically add people to your Pipeboard team or grant them access to your ad accounts. Invite them from Settings → Team as usual, and use Team Access Controls to decide who can write.

What happens to existing accounts

Most teams turn on SSO after they have already been using Pipeboard for a while. That case is handled.

Someone who already had a password

The first time they sign in through SSO we detect the earlier account and offer to move it across — connections, teams, saved work and history included. It is an explicit opt-in screen; nothing is merged silently and the old account is disabled rather than deleted.

Someone brand new

An account is provisioned from the assertion on first login. Because of that, anyone your IdP lets into the Pipeboard app can create an account — scope the app to the right groups or org units on the IdP side rather than relying on us to filter.

Troubleshooting

“No SSO is configured for yourcompany.com”

The domain on that email address is not attached to your connection. Check the user is typing their work address and not an alias domain you forgot to register — send us any missing domains and we will add them.

The IdP shows an error before it ever reaches Pipeboard

Almost always app assignment: the user is not in the group or org unit the SAML app is scoped to. Fix it in the IdP, then retry — new assignments can take a few minutes to propagate.

Authentication succeeds but the return trip fails

Usually a mismatch in the ACS URL or the Entity ID. Both are exact-match values — a trailing slash, http instead of https, or a copied-over value from another vendor will all fail signature or audience validation.

Every login creates a new, empty account

Your Name ID is not stable. Set the format to Persistent and map it to the primary email address, then tell us so we can clean up the duplicates.

Logins broke suddenly and nothing changed on our side

Check your IdP signing certificate expiry. Certificates rotate, and the connection needs the updated metadata. Send us the new metadata before the old certificate expires and there is no downtime.

Names show up blank in the app

The first_name / last_name attributes are not being sent, or are sent under different claim names. Both are optional — add the mappings from step 3 if you want them populated.

Common questions

Can we configure SSO ourselves?

Not yet. You do the IdP side; we register the connection for your domains. Self-service configuration is on the roadmap — until then, activation and any later change go through support.

Which plan includes SSO?

Enterprise. If you are not on Enterprise yet, mention SSO when you talk to us and we will scope it with the rest of the plan.

Do you support OIDC instead of SAML?

Enterprise connections are SAML 2.0 today. If SAML is not an option for your IdP, tell us what you have and we will look at it. Note that regular Google and GitHub sign-in are already supported for everyone — those are separate from an enterprise SSO connection.

Can one connection cover multiple domains?

Yes. Send every domain and alias in one go and we will attach them all to the same connection.

Does turning on SSO disable password login for our domain?

Not automatically. If you need SSO to be the only route in for your users, say so when you contact us so we can plan it — do not assume it is enforced by default.

Do you support SCIM provisioning or automatic deprovisioning?

Not today. Removing someone in your IdP stops them signing in through SSO, which is the main control. Removing their access to your Pipeboard team and ad accounts is a separate step in Settings → Team.

Where does MFA fit in?

Entirely on your side. Because authentication happens at your IdP, your MFA, conditional access and device policies apply unchanged.

Does SSO change how MCP tokens work?

No. API tokens and MCP connections are unaffected — they are authorized per user and keep their own permissions. See the API token permissions guide for how to scope them.

Ready to connect your identity provider?

Configure the SAML app with the values above, then send us the metadata and your domains. We will activate the connection and confirm once it is live.