The simplest way to

Add SAML SSO to Your B2B App

Enterprise buyers expect Single Sign-On (SSO): logging in through their own identity provider. The Bridge connects Okta, Entra ID, and any SAML (Security Assertion Markup Language) 2.0 IdP with signed requests, so you close the deal without hand-rolling XML parsing or per-customer connection code. No SSO tax, no per-connection fee.

Quickstart in minutes

Enterprise-grade & compliant by default

Add SAML SSO with The Bridge

SAML SSO, wired in

SSO enabledTurned on in the Control Center, no redeploy.
IdP connectedPaste metadata once, signed requests handled for you.
Per-tenant connectionsEach customer brings their own IdP, isolated cleanly.
One clean user objectSame user, every method, ready in every SDK.

Go live in a day

Turn it on. That's the setup.

SSO is a toggle plus a connection, not a quarter of work. Flip the switch and the "Sign in with SSO" option appears in your sign-in screen instantly, with no redeploy.

Flip it, watch your login screen update live.

The fastest way to add it

Don't parse the assertions. Describe it.

The Bridge is agent-native. Add our MCP (Model Context Protocol) server to your AI editor and ship SAML SSO by asking.

✦ MCP-nativeClaude CodeCursorAny MCP client

Your agent does the wiring, you ship enterprise SSOwiring

Connect your AI agent to The Bridge over MCP, then just ask. It enables SSO in the Control Center, creates the SAML connection from the customer's metadata, turns on signed requests, and assigns it to the right tenant, correctly the first time.

Add the MCP server

Prefer to wire it yourself? The Bridge ships first-class software development kits (SDKs) for every stack.

Why SAML SSO

The biggest wins, out of the box

SAML SSO is the feature that makes your app safe to adopt at enterprise scale, and the one buyers ask for first.

Unblocks enterprise deals

SSO is a line item in procurement. Shipping it removes the most common blocker to a large contract.
Revenue
Central deprovisioning

Disable someone in the corporate IdP and their access to your app ends too, which is what security teams require.
Governance
Signed requests

Authentication requests are signed and assertions are validated, so the trust between app and IdP holds.
Security
Per-tenant connections

Each customer brings their own IdP, isolated per tenant, so one connection never leaks into another.
Multi-tenant
Same user, every method

SAML, social, magic link, and email all normalize to one consistent user schema.
Consistency
No SSO tax

No per-connection fee and no enterprise-only paywall on the feature that keeps customers safe.
Pricing

And of course

First-class SDKs for every stack

Type-safe, batteries-included SDKs with drop-in components, and the same clean user object everywhere.

Next.js

Svelte

Astro

Node

FastAPI

Laravel

Flutter

React

Angular

Nuxt

Deno

Python

Rust

Ruby

Kotlin

Vue

SolidJS

Remix

Bun

Django

PHP

.NET

NestJS

…and 24+ frameworks & languages supported. Hover to pause, drag or swipe to explore.

Rolling your own vs. The Bridge

What a hand-built SAML integration actually costs you, versus a toggle and a connection.

Building it yourself

Parse and validate signed SAML XML assertions
Manage IdP metadata and certificate rotation
Build a separate connection for every customer
Map attributes and isolate connections per tenant

With The Bridge

Flip one toggle and paste IdP metadata
Signed requests and assertion validation handled
Per-tenant connections out of the box
Same clean user object, every login method

Under the hood

What Adding SAML SSO Actually Involves

SAML connects your app to a customer's identity provider so their team signs in centrally. Here is how it works, what a manual build involves, and where The Bridge makes each connection configuration, not code.

What adding SAML SSO involves

Adding Security Assertion Markup Language (SAML) Single Sign-On (SSO) means connecting each customer's identity provider (IdP) to your app, the service provider (SP), usually by exchanging metadata. The IdP authenticates the user and sends your app a signed assertion. The Bridge stores these as per-tenant connections you add from the dashboard.

In SAML, your app is the service provider (SP) and the customer runs the identity provider (IdP), such as Okta or Microsoft Entra ID. You connect the two by exchanging metadata, often just a metadata URL, which carries the endpoints and signing certificate each side needs.

Once connected, the IdP authenticates the user and sends your app a signed assertion describing who they are. Your app validates the signature and opens a session. Crucially this is per customer: each enterprise brings its own IdP, so you manage a connection per tenant.

For how this fits with sessions and roles, see the SaaS authentication guide. With The Bridge, each SAML connection is added in the Control Center per tenant, with signed requests on by default, so it is configuration rather than per-customer code.

How SAML sign-in works under the hood

Sign-in is either SP-initiated, where the user starts at your app, or IdP-initiated, where they start at the identity provider's portal. Either way, the identity provider returns a signed SAML assertion. Your app validates the signature and conditions, then provisions or matches the user, often just-in-time from the assertion.

There are two entry points. SP-initiated sign-in starts at your app, which redirects the user to their IdP. IdP-initiated sign-in starts from the customer's portal, where they click your app's tile. Supporting both is normal for enterprise buyers.

The security work is in validation. When the assertion comes back, you verify the signature against the IdP's certificate, check the conditions (audience, timestamps, and a tolerance for clock skew), and only then trust the identity it asserts. From there you provision the user just-in-time (JIT) or match them to an existing record.

The Bridge validates signed assertions, supports per-tenant connections, and provisions users from the assertion, so a new enterprise customer is an onboarding step, not an engineering project.

What a manual SAML build involves

A manual SAML build means parsing and validating signed XML, handling both sign-in directions, storing a connection and certificate per customer, and dealing with metadata updates and clock skew. The cost is not one integration, it is the per-tenant multiplication of all of it.

SAML is XML-based, and the details are unforgiving:

Parsing and validating signed XML assertions correctly, which is historically a source of authentication-bypass bugs when done by hand.
Supporting both SP-initiated and IdP-initiated flows.
Storing a connection, certificate, and configuration per customer, and rotating certificates as they expire.
Tolerating clock skew and handling metadata changes without breaking a live customer.

Then it multiplies: every enterprise has its own IdP, so the work repeats per tenant. Larger buyers increasingly also ask for SCIM (System for Cross-domain Identity Management) to provision and deprovision users automatically, which is a separate track to plan for.

The Bridge handles assertion validation and per-tenant connections, so adding a customer's IdP does not mean another hand-rolled integration.

Production considerations

Plan for many connections, not one, differentiate the common Microsoft path from the generic SAML path, and price SSO fairly. Enterprise Single Sign-On is table stakes for large deals, so the goal is to make each new connection cheap to add and safe to run.

Design for scale from the start. You are not adding SAML once, you are adding a connection per enterprise customer, so per-tenant management and clean onboarding matter more than the first integration.

Many of your customers will be on Microsoft. If most are, the dedicated Microsoft Entra ID walkthrough is the faster path for them, while generic SAML covers Okta, OneLogin, Ping, and the rest. Offering both, on one user model, keeps the experience consistent.

Finally, do not gate basic security behind a punitive tier. The Bridge does not charge an SSO tax or a per-connection fee; what is gated is gated transparently by plan, with /pricing as the single source of truth.

Common questions

Which identity providers are supported?

Any SAML 2.0 identity provider, including Okta, Microsoft Entra ID, Google Workspace, OneLogin, and Ping. You connect each one by pasting its metadata URL or XML.

Are authentication requests signed?

Yes. The Bridge sends signed SAML authentication requests and validates the IdP's signed assertions, so the trust between your app and the provider is enforced on every sign-in.

Can each customer use their own IdP?

Yes. SAML connections are assigned per tenant, so every enterprise customer signs in through their own provider without connections ever crossing between organizations.

Is there a per-connection fee?

No. The Bridge does not charge an SSO tax or a per-connection fee. What is gated is gated transparently by plan, with pricing as the single source of truth.

What about customers who use OIDC instead of SAML?

The Bridge also supports OpenID Connect federation, so you can connect modern OIDC providers alongside SAML connections from the same Control Center.