Enterprise SSO with SAML

When a customer says "our staff use Entra ID, can your product support that?", this is the answer. Your application does not change.

How it fits together

EAuth is the service provider. It receives the assertion from the customer's identity provider and continues to issue you ordinary OIDC tokens.

employee → your app → EAuth → customer's IdP → EAuth → your app
                                (Entra ID, Okta, Google)

Your integration is the same authorization code flow you already have. Adding an enterprise customer is a configuration change on one organisation, not a second integration in your product.

Setting one up

1. Create an organisation for the customer and verify their email domain. The verification matters: it is what lets somebody typing anna@acme.com be sent to Acme's provider without choosing anything.
2. Give the customer your entity id and reply URL from the console.
3. Paste their SSO URL, entity id and signing certificate.
4. Turn the connection on.

From then on, an address in that domain goes to their provider. Everyone else signs in normally.

What we check that the specification leaves to us

The XML signature handling is a maintained library's job. Signature wrapping has broken implementations at large vendors because XML canonicalisation is subtle in ways that look fine in testing, so it is not written by hand here.

Three checks are ours, and skipping any of them is a real attack:

Replay. Every assertion id is remembered until it expires. A captured response posted a second time is refused.

Unsolicited assertions. The InResponseTo must match a request we actually made and have not yet consumed. An assertion arriving out of nowhere is rejected rather than trusted.

Domain. The asserted address must sit inside the organisation's verified domain. Without this, a compromised or misconfigured provider could assert an address belonging to a different customer entirely.

Each connection gets its own key pair, so one customer's compromise does not reach another's.

Options worth knowing

Automatic provisioning creates the account on the first successful assertion, which is what makes rolling out to two hundred employees one step rather than two hundred.

Enforce SSO stops members of that organisation using a password. An enterprise buying SSO usually expects it to be the only door, and leaving a password alive defeats the control they bought.

Attributes

Defaults cover Entra ID and Okta. Where a provider differs, set the attribute names on the connection. Both the full claim URI and the friendly name are matched, because providers disagree about which they send.

Entra ID often carries the address only as the NameID rather than as an attribute, which is handled as a fallback so the common case needs no configuration.