Identity federation

Your IdP remains the source of truth

When an organization has invested in an identity provider — Okta, Azure AD, Google Workspace, or a custom OIDC provider — that investment should remain the system of record. We integrate; we do not relitigate. SAML 2.0, OIDC, JIT provisioning, and email-domain auto-provisioning so onboarding and offboarding stay in your existing tooling.

Executive summary

Single sign-on for Enterprise organizations via SAML 2.0 or OIDC. Just-in-time user provisioning means the first IdP-authenticated login creates the local membership; subsequent SSO re-auth fails after the IdP deactivates a user, and active sessions end via SCIM deprovision or session expiry. JWKS rotation is automatic and cached. Domain restrictions ensure only your verified email domains can join your organization, with optional auto-provisioning when a verified-domain user signs in for the first time.

Our commitments

Five rules for federated identity

The IdP is the source of truth

We do not store an authoritative copy of your user directory. Membership decisions reflect your IdP's current state at sign-in time.

Standards-only protocols

SAML 2.0 (OASIS) and OIDC (OpenID Foundation). No proprietary single-sign-on bridges. Any compliant IdP works without a special connector.

JIT provisioning by default

The first authenticated login creates the local membership. No bulk import, no out-of-band sync. When a user is removed from the IdP, subsequent SSO re-auth fails; the active session ends via SCIM deprovision or session expiry.

Sensitive IdP material is encrypted at rest

Client secrets carry field-level AES-256-GCM encryption with redact: true on the schema.

Domain restrictions are a hard gate

Email-domain allow-list is enforced before any user record is created. Auto-provisioning is opt-in, never default — domain matches are evaluated, not assumed.

Implementation — SAML 2.0

SAML hardening

Standard SAML 2.0 OASIS

Bindings HTTP-POST + HTTP-Redirect No deprecated bindings

Signature verification Required on every assertion X.509 from IdP metadata

Assertion encryption Not supported Signed assertions required; encrypted assertions are not supported

SP metadata Generated and hosted One-click setup with your IdP

Replay protection NotBefore / NotOnOrAfter Strictly enforced; 5-minute clock skew

Audience restriction SP entity ID checked Cross-tenant assertion rejection

Subject NameID EmailAddress format Bound to verified domain on first sign-in

Implementation — OIDC

OIDC hardening

Flow Authorization Code + PKCE No implicit flow, ever

Discovery Auto from .well-known/openid-configuration Cached with TTL

ID token verification Signature + claims iss, aud, exp, nonce all verified

JWKS Cached + auto-rotating Refreshed on kid mismatch; pinned to issuer

State parameter 32-byte cryptographic random CSRF protection on auth callback

Nonce Per-request, single-use Replay protection on ID token

Userinfo Optional, for attribute enrichment ID token claims preferred when sufficient

Token endpoint auth client_secret_post RFC 6749 §2.3.1

The full picture

What is built, what is being built, and what we chose not to build

Live today

SAML 2.0 IdP integration

Live

Metadata fetch + parse, SP metadata generation, signed assertion verification with replay protection.

OIDC with PKCE

Live

Authorization Code + PKCE flow only. Discovery, JWKS caching, nonce + state validation.

JIT user provisioning

Live

First IdP-authenticated login creates the local membership; mapped to org via verified domain or admin-configured rule.

Field-level encryption for IdP credentials

Live

Client secrets encrypted at rest with redact: true; never reach logs or telemetry.

Email-domain restriction + auto-provisioning

Live

DNS TXT verification of the domain; only verified domains can be enrolled for auto-provisioning.

SCIM 2.0 /Users inbound provisioning

Live

RFC 7644 compliant SCIM /Users endpoint so your IdP can create, update, and deactivate users without our intervention.

Building now

SCIM 2.0 /Groups support

Building now

Extend SCIM coverage to group membership so IdP-side group changes propagate without admin intervention.

Group-based role mapping

Building now

Map IdP group membership to EngineeringID organization roles. Removing a user from the IdP group revokes the role on next sign-in.

Roadmap

IdP-initiated SLO (Single Logout)

Roadmap

When the IdP signals logout, we revoke every EngineeringID session that user holds in one transaction.

Multi-IdP per organization

Roadmap

Some Enterprise orgs run multiple IdPs (one for employees, one for contractors). Support routing rules so each user authenticates against the right one.

Step-up authentication via IdP

Roadmap

Re-prompt the IdP for high-assurance auth before sealing operations, even when a session already exists.

Customer-rooted SAML signing

Roadmap

Use a customer-controlled CA chain for SP metadata signatures, so customers can run mTLS against our SP endpoint.

Considered & rejected

LDAP-direct authentication

Considered & rejected

LDAP exposes credential material directly; OIDC and SAML do not.

Why we rejected it: LDAP authentication requires the user's password to flow to us. Federated SSO via OIDC or SAML keeps the credential at the IdP. The IdP returning a signed assertion is strictly stronger than us verifying a password against a directory.

Password sync / directory sync

Considered & rejected

Replicating password material to a second system multiplies the attack surface and adds nothing.

Why we rejected it: every "we sync your AD passwords so users can sign in directly" is a permanent commitment to having a copy of those passwords. The right answer is: do not have the passwords. Federate, do not replicate.

OAuth implicit flow

Considered & rejected

The implicit flow leaks tokens via URL fragments and lacks PKCE; it has been removed from OAuth 2.1 for cause.

Why we rejected it: implicit flow exists for a use case (browser-only SPAs) that we do not have. Authorization Code + PKCE is the modern correct answer; we use it exclusively.

Default-on "trust this IdP" without metadata pinning

Considered & rejected

An IdP rotation we did not approve should not silently re-anchor trust.

Why we rejected it: each IdP integration pins to a specific certificate set in the metadata. A rotation requires a deliberate config update, not a silent acceptance of whatever shows up at the metadata URL.

Compliance mappings

Controls this surface satisfies

SOC 2 CC6.1

Logical Access — Authentication

Federated SAML / OIDC; field-level credential encryption

SOC 2 CC6.2

User access management

JIT provisioning + IdP-driven deactivation

ISO 27001 A.9.2.1

User registration and de-registration

JIT registration; IdP signals deactivation

ISO 27001 A.9.4.2

Secure log-on procedures

Federated SSO with replay + nonce protection

NIST SP 800-63C FAL2

Federation Assurance Level 2

Bearer assertions with strong binding via SAML/OIDC

HIPAA §164.312(d)

Person or Entity Authentication

Federated identity from a verified IdP

For compliance teams

Questions you do not need to call to ask

Which IdPs are supported?

Any IdP that speaks SAML 2.0 or OIDC standard protocols. We have shipped customer integrations with Okta, Azure AD / Entra ID, Google Workspace, OneLogin, Auth0, JumpCloud, and Ping. Custom OIDC providers work via discovery URL.

What happens when a user is removed from the IdP?

Subsequent SSO re-auth fails after the IdP deactivates the user. The active local EngineeringID session ends via SCIM deprovision or session expiry — with SCIM /Users live today, the deactivation propagates without waiting for the user's next request.

Can we restrict which email domains can authenticate?

Yes. Domain ownership is verified via DNS TXT record; only verified domains can enroll for SSO and auto-provisioning. Mixed-domain orgs are supported with a domain allow-list.

How is the SAML signing certificate rotated?

When the IdP publishes new metadata, the customer admin reviews and approves the certificate change. We do not silently accept new metadata; rotation is an explicit operation logged in the audit chain.

Do you support contractor or guest access via separate IdPs?

Multi-IdP per organization is on the roadmap. Today, mixed populations are typically handled by routing contractors through the same IdP with a different group membership, which we map to a different EngineeringID role.

What logs are kept on SSO sign-ins?

Every authentication produces an audit-chain event: actor, IP, user agent, IdP issuer, assertion ID, timestamp. SCIM operations (when live) produce their own provisioning events.

Federate identity. Do not replicate it.

See the SSO setup flow, or talk to our security team about your IdP topology.

Start Free Trial Talk to security team