B2B Identity Integration Requirements Beyond SSO

A B2B identity integration should cover customer single sign-on, organization membership, provisioning and offboarding, resource authorization, session and token lifecycles, and operational ownership. Treat successful login as one acceptance test—not the definition of completion.

For each requirement, specify who owns it, which customer configurations are supported, and what observable result constitutes a pass. The checklist below is an engineering recommendation, with standards and documented product capabilities cited where relevant.

Define identities and organization memberships separately

Design the application model so that a person’s identity is distinct from their membership in a customer organization. Give each membership its own status and permissions rather than treating the account as belonging permanently to one tenant.

Specify the rules for:

• Joining: invitations, administrator approval, and verified organization ownership.
• Administration: who can invite members, change roles, configure SSO, and delegate administrative access.
• Multiple organizations: how users select an organization and how the server validates that selection.
• Leaving: when to remove one membership versus disable an identity across the application.
• Account linking: what evidence is required to associate another external account with an existing identity.

Do not use an email-domain match as the sole authorization to join a tenant or become an administrator.

A useful acceptance test is a user with memberships in organizations A and B. Remove the membership in A, then verify that A’s resources are inaccessible while the intended access to B remains intact. Include existing browser sessions and API requests, not just the next login.

Specify customer SSO as an inbound integration

OpenID Connect Core defines an identity layer over OAuth 2.0 that lets clients verify an end user’s identity based on authentication performed by an authorization server and obtain claims about that user. Make that protocol role explicit in the integration design.

For B2B requirements, distinguish accepting authentication from a customer’s identity provider from issuing credentials to your own applications. Do not accept a generic “OAuth/OIDC supported” checkbox as proof that a particular customer SSO connection works.

Build a connection matrix covering:

Requirement	What to specify and test
Customer protocols	Which customers require SAML or OIDC, and which configurations you support
Tenant routing	How users reach the correct connection and how connection-to-tenant binding is validated
External-account mapping	The stable identifiers used within each connection and the handling of changed email addresses
Configuration changes	Who may change a connection, how changes are tested, and how rollback works
Key and certificate rotation	How old and new configurations are handled during a transition
Recovery and fallback	Which alternate access paths are allowed and who can authorize them

Test actual customer configurations, including failure cases. Also define authentication-assurance requirements: when upstream authentication evidence is sufficient, when additional authentication is required, and how recovery or emergency access avoids bypassing the organization’s intended policy.

Give provisioning its own lifecycle contract

SCIM provides a useful standards boundary: RFC 7643 defines core schemas and an extension model for identity data, including users and groups; RFC 7644 defines the HTTP-based identity-management protocol.

For each customer, determine whether the integration requires SCIM, another provisioning API, account creation at first login, or manual administration. Specify the supported behavior rather than assuming these mechanisms satisfy the same lifecycle requirements.

Document which system owns each field and relationship. In particular, decide how directory groups map to application memberships or roles, which local changes are permitted, and what reconciliation should do when the systems disagree.

Use a lifecycle test matrix:

Event	Required acceptance decision
Create or invite	Which identity and membership records are created, and when access begins
Profile update	Which attributes may change and which identifiers remain stable
Group addition or removal	Which permissions change and when the change becomes effective
Suspension or deletion	Whether the action affects one tenant or the whole identity
Restoration	Which previous memberships and privileges, if any, are restored
Duplicate delivery or retry	How repeated processing avoids duplicate accounts or unintended grants
Missed update	How reconciliation detects and repairs the discrepancy

Do not use successful first-login account creation as the offboarding acceptance test. Exercise removal and suspension through the lifecycle mechanism the customer will actually operate.

Set a measurable access-removal deadline

Define offboarding as an access-enforcement requirement, not merely a successful write to an identity record.

For each removal event, specify the expected effect on tenant membership, local sessions, refresh credentials, access tokens, authorization data, and caches. Document which enforcement mechanisms can stop access immediately and which leave credentials usable until a later check or expiry.

Measure two intervals separately:

1. Delivery delay: from the authoritative customer-side change to receipt by your integration.
2. Enforcement delay: from receipt to the point when protected operations are denied.

A deadline measured only after receipt excludes delivery delays. Agree on whether the customer-facing commitment covers enforcement alone or the full interval from the authoritative change to access denial. Define how delivery failures are detected.

Test offboarding while the user is active. Repeat resource reads, writes, exports, and token-refresh attempts until the expected denial occurs. Include any background work whose authority derives from that membership, and define whether queued work should be canceled or reauthorized.

Enforce authorization within a validated tenant context

Require an authorization decision for resource access independently of successful authentication. Define organization roles, resource-level relationships, group-to-role mappings, and who is allowed to grant privileges.

For every protected operation, specify how the application establishes the caller, validates the tenant context, and evaluates the requested action against the resource. Scope authorization records and cache entries to the relevant identity, tenant, resource, and permission inputs.

Include cross-tenant negative tests for:

• Direct requests using another tenant’s resource identifier.
• List, search, and export endpoints.
• Administrative and support APIs.
• Background jobs and scheduled tasks.
• Requests made after membership or role changes.

Specify what happens when authorization data is stale, missing, or unavailable. For tenant-protected operations, use denial as the default unless a narrowly defined exception has been explicitly approved and tested.

Define API credential and token policies explicitly

Give human-operated applications and service accounts separate credential requirements. For each credential type, record its owner, intended audience, permissions, tenant binding, expiration policy, rotation procedure, and revocation mechanism.

Test that each credential cannot authorize access outside its intended tenant, audience, and permission scope. Also specify what happens to service credentials when their creating administrator leaves: transfer ownership, suspend them, or revoke them according to an explicit policy.

Use RFC 9700 as an OAuth security-review baseline. It documents best current practice, updates and extends earlier OAuth security guidance, and deprecates some less-secure modes of operation. It complements rather than replaces the earlier specifications’ security advice. Build protocol-specific validation tests against the applicable standards rather than treating token issuance alone as evidence that an integration is secure.

Map identity products to requirements, not feature labels

Ory’s documentation describes the following Ory Network services. Use these documented roles to map responsibilities, not as a complete enterprise feature inventory.

Ory Network service	Role described by Ory	Integration responsibility to verify separately
Ory Identities (Kratos)	API-first identity and user management, self-service account flows, administrative account operations, customizable identity schemas, and session management	Tenant membership, provisioning contracts, and end-to-end offboarding behavior
Ory OAuth2 and OpenID Connect (Hydra)	OAuth 2.0 and OpenID Connect provider functionality; connected to Ory Identities by default	The specific inbound customer SSO connection and application token policy
Ory Permissions (Keto)	Fine-grained permissions based on relationships, including inheritance through groups, roles, and hierarchies	The application’s tenant model, enforcement points, and permission-update behavior

These documented roles do not by themselves verify a complete customer integration. Treat inbound SAML connections, SCIM provisioning, organization onboarding, and coordinated access removal as separate acceptance items. Evaluate the exact managed offering or self-hosted version and configuration rather than assuming identical capabilities or operational responsibilities.

Make operations and auditability part of acceptance

Assign an accountable owner to customer connections, provisioning synchronization, authentication services, token services, and authorization enforcement. Define escalation paths across those boundaries before an incident.

Exercise operational scenarios: an identity-provider outage, a bad connection update, administrator lockout, provisioning backlog, rate limiting, and backup restoration. For each, document detection, containment, recovery, and the expected access policy during the failure.

Define audit records for login outcomes, membership changes, permission grants, connection changes, and recovery actions. Include the actor, tenant, target, operation, result, timestamp, and correlation identifier where appropriate. Keep passwords, credentials, and tokens out of those records, and explicitly scope personal-data collection, retention, export, and access.

Finish acceptance with an end-to-end scenario: connect a customer, provision a user, grant a role, change that role, remove the membership, and demonstrate access denial within the agreed deadline. A defensible completion criterion is not “SSO works,” but “the intended access can be granted, changed, removed, and explained under both normal and failure conditions.”