The first enterprise customer who loves your product will eventually ask a harder question than pricing.
Their security team will want single sign-on through their own identity provider, automatic offboarding when someone leaves, and evidence of who had access when.
If your answers are still "we are planning to," the deal often slips a quarter while you scramble.
I have sat on both sides of that review. The list below is the identity checklist growing B2B SaaS teams need before that questionnaire lands, framed around open standards.
Questions enterprise security teams actually ask
Expect more than "Do you support SSO?" A typical questionnaire covers:
- Can employees sign in through our corporate identity provider over SAML 2.0 or OpenID Connect (OIDC)?
- Can we enforce MFA at our IdP, and will your application honor that signal without inventing a second MFA path?
- How do you provision and deprovision users? Do you support SCIM?
- What are your session lifetimes, refresh token policies, and idle timeouts?
- Can we export or stream authentication and admin event logs into our SIEM?
- How do you isolate our tenant's data, configurations, and identity connections from every other customer?
- If an identity incident happens in your stack, how do you notify us, rotate credentials, and prove which accounts were affected?
Answer each one with a concrete mechanism. "We take security seriously" does not survive a follow-up call with their IAM architect.
SAML and OIDC basics
Most enterprise buyers arrive with SAML 2.0 already wired into their workforce IdP. OIDC shows up more often with modern cloud IdPs, API-heavy products, and mobile clients. Many SaaS products support both and let each tenant choose.
Setup is a metadata exchange.
- SAML: You and the customer trade entity IDs, Assertion Consumer Service URLs, single logout endpoints, and signing certificates.
- OIDC: You exchange issuer URLs, client IDs and secrets (or public client settings), redirect URIs, and discovery document locations.
Plan for certificate and signing key rotation before the first connection goes live. Expired IdP certificates are a common production outage.
Know the difference between SP-initiated and IdP-initiated flows.
- SP-initiated: Starts in your app and redirects to the IdP; it is the usual path for deep links and invites.
- IdP-initiated: Starts from the customer's app portal and lands in your app with an unsolicited assertion or login.
Support both if the buyer's portal team expects a tile in their app catalog.
Attribute and claim mapping is where quiet failures hide. Group names, email, and department attributes differ across IdPs. Map them explicitly per tenant.
When a required claim is missing, fail closed. Do not fall back to a default admin or member role because a group attribute was renamed upstream.
Tenant isolation
Enterprise SSO is multi-tenant by nature. Each customer needs their own IdP connection, their own domain list, and their own attribute maps.
Domain verification (or home realm discovery) routes user@customer.com to that customer's IdP instead of a shared login page.
Put a stable tenant identifier into every token and session, and check it together with audience on every request. A token issued for Tenant A must never open Tenant B's data, even if the user email matches.
Pair that with per-API audience values (see RFC 8707 resource indicators where you use them) so a token meant for billing cannot call your admin API.
Avoid shared "catch-all" IdP connections across unrelated customers. Shared connections make attribute mapping ambiguous and turn one misconfiguration into a cross-tenant incident.
Offboarding and SCIM
SSO alone stops a departed employee from signing in again. It does not remove the account that already exists in your product, nor the API keys, personal access tokens, refresh tokens, or long-lived sessions that account still holds.
SCIM 2.0 (RFC 7643 for the schema, RFC 7644 for the protocol) lets the customer's directory create, update, and deactivate users in your app automatically.
When HR marks someone terminated, the IdP sends a deactivation. Your app should disable the user, revoke refresh tokens and sessions, and invalidate API credentials tied to that identity in the same workflow.
Just-in-time (JIT) provisioning creates an account on first SSO login. It is fine for early tenants and demos. It does not solve offboarding, role changes, or seat cleanup on its own.
Prefer SCIM (or an equivalent directory sync) once a customer has a real IT function. If you only offer JIT, document the gap honestly: the buyer will ask.
Follow OAuth security best practices (RFC 9700) for token lifetimes and revocation. Short-lived access tokens plus revocable refresh tokens give you a real kill switch when SCIM says "deactivated."
Audit evidence
Security questionnaires and SOC 2 or ISO 27001 style reviews ask who authenticated, who changed roles, who connected an IdP, and who exported data.
You need login events, admin events, and provisioning events with timestamps, actor, target, tenant, IP or device context where available, and outcome.
Retention should match what buyers expect for their industry, and exports should be something you can produce without a week of engineering work. CSV or JSON downloads help smaller buyers; SIEM streaming via webhook or a log ship helps larger ones.
Be ready to answer "show me who had access to this tenant between these two dates." If that query requires a database archaeologist, fix the logging before the auditor asks.
Where AI agents fit
AI agents and MCP-style tool integrations increasingly act inside your product for a user. Treat them as first-class identities in your access model.
Prefer delegated OAuth tokens that are scoped, short-lived, and audience-bound to the APIs the agent may call. Keep the human user's identity and the agent's identity distinguishable in every log line.
When you revoke a user, also revoke every agent grant, refresh token, and tool credential issued under that user. Otherwise offboarding looks complete in the UI while an agent still holds a live token.
The same audience discipline that protects internal APIs applies here. One broad audience shared by every agent tool becomes a master key the moment any one integration leaks a token.
Closing checklist
Before you answer the next enterprise questionnaire, confirm you can check each box:
- Per-tenant SAML 2.0 and/or OIDC connections with documented metadata exchange and certificate rotation.
- SP-initiated and IdP-initiated login paths tested with at least one real customer IdP.
- Explicit attribute and claim maps, with fail-closed behavior when a mapped claim is missing.
- Domain verification or home realm discovery that routes users to the correct IdP.
- Stable tenant IDs in tokens, checked together with audience on every request.
- SCIM 2.0 (or equivalent) deprovisioning that revokes sessions, refresh tokens, and API credentials.
- Exportable authentication and admin event logs with retention you can defend in a SOC 2 style review.
- Agent and tool access modeled as delegated, scoped, revocable tokens with distinct log identities.
Enterprise SSO touches login, authorization, lifecycle, audit, and now non-human actors. Build those pieces while your buyers are still mid-market, and the first serious security review becomes a conversation about timelines instead of a rebuild under contract pressure.
Read more: Explore the best identity and access management software for managing authentication, access, and identity lifecycles.