Inbound vs Outbound SSO: How Federation Actually Works

Key takeaways

• Inbound SSO: your app is the service provider accepting an external IdP. Outbound SSO: your app is the IdP issuing identity to downstream apps.
• Inbound SSO is the B2B enterprise-readiness feature: each customer brings its own IdP, configured per tenant, users provisioned via JIT or SCIM.
• SP-initiated flows (start at your app) are the safe default; IdP-initiated flows (start at the IdP) need extra replay and RelayState care.
• Most SSO vulnerabilities are assertion-validation shortcuts, not protocol flaws: check signature, issuer, audience, timestamps, and replay.
• SSO authenticates but does not deprovision; pair it with SCIM so disabling a user in the customer's IdP revokes access to your app.

The two directions

Federation always has two roles: the identity provider (IdP) that authenticates the user and asserts who they are, and the service provider (SP, also called the relying party) that trusts that assertion and grants access. Which role your application plays defines the direction.

   INBOUND SSO (you are the SP / relying party)

   Customer's IdP  --- asserts identity --->  YOUR APP
   (Okta, Entra,                              (trusts the
    Google, social)                            assertion, grants access)


   OUTBOUND SSO (you are the IdP)

   YOUR APP  --- asserts identity --->  Downstream app / partner SP
   (authenticates                        (trusts your assertion)
    the user)

The same protocols (SAML 2.0, OpenID Connect) power both directions. What changes is which side you implement and secure.

Inbound SSO: accepting an external identity provider

This is the direction most B2B teams mean when they say "we need SSO." A customer organization wants its employees to log into your product using the organization's own IdP, so that access follows their central identity and offboarding. It is the enterprise-readiness feature that unblocks deals.

The per-tenant model

Inbound SSO is inherently multi-tenant. Each customer organization brings its own IdP, so the configuration lives per tenant, not globally. This is why the Organizations and tenants model matters: each Organization holds its own SSO connection, its own IdP metadata, and its own provisioning rules. A customer admin should be able to set this up self-serve, because you do not want to be in the loop for every one of dozens of enterprise connections.

SP-initiated vs IdP-initiated

• SP-initiated (the safe default). The flow starts at your app. Your app generates an authentication request, redirects the user to their IdP, and receives the response bound to that request. Because you issued the request, you can correlate and validate the response against it.
• IdP-initiated. The flow starts at the IdP (the user clicks your app from their IdP dashboard), and the assertion arrives at your app with no preceding request. Some enterprises require this, but it removes a natural defense against replay and cross-site request forgery and complicates RelayState. If you support it, add explicit replay protection and strict validation.

Provisioning: JIT and SCIM

SSO authenticates a user, but the user needs a record in your app.

• Just-in-time (JIT) provisioning creates or updates the user on first successful login from the assertion's attributes. Simple, but it only acts when the user logs in.
• SCIM keeps the directory in sync proactively: when the customer creates, updates, or disables a user in their IdP, that change propagates to your app. The critical case is deprovisioning: without SCIM, a user removed from the customer's IdP may retain a lingering account. See SCIM vs SAML.

Outbound SSO: being the identity provider

Here your application is the IdP. Two common cases:

• Single sign-on across your own product suite. Users log in once and reach every app you operate. Your CIAM is the central IdP issuing tokens the other apps trust.
• Providing SSO to downstream or partner applications. Other services consume the identity your app asserts, the mirror image of inbound SSO from their perspective.

As the IdP you own more: registering and trusting service providers or OAuth clients, issuing correctly-scoped assertions and tokens, managing signing keys and their rotation, and running the session that backs single sign-on. Token lifetimes and revocation become your responsibility; see token lifetime best practices.

The security checklist (both directions)

Most real-world SSO vulnerabilities are not protocol breaks. They are validation shortcuts on the receiving side. Whether you consume assertions (inbound) or issue them (outbound), get these right:

• Signature validation. Verify the assertion is signed by the expected key, and validate the signature over the right element. Reject unsigned assertions.
• Issuer and audience. Confirm the assertion came from the expected IdP (issuer) and is intended for your app (audience restriction). Skipping audience checks lets an assertion minted for one SP be replayed at another.
• Timestamps and clock skew. Enforce NotBefore and NotOnOrAfter windows with a small, bounded clock-skew allowance. Do not accept stale assertions.
• Replay protection. Track assertion IDs so the same assertion cannot be used twice, especially for IdP-initiated flows.
• RelayState and redirect validation. Validate RelayState and any return URL against an allowlist so SSO cannot be used as an open redirect.
• Certificate rotation. IdP signing certificates expire and rotate. Support metadata refresh and multiple valid certificates so rotation does not cause an outage.
• Deprovisioning. Ensure disabling a user upstream revokes access, authentication alone does not, which is the SCIM point above.

Build or buy

Inbound SSO in particular is a classic underestimate: the protocol is straightforward, the long tail of IdP quirks, IdP-initiated flows, certificate rotation, per-tenant self-serve configuration, and exact validation is not. Enterprise-readiness layers exist for this reason.

• WorkOS and SSOJet productize the inbound enterprise-readiness layer (SSO, SCIM, per-tenant config).
• Auth0, Frontegg, and Ping Identity cover both directions with broader platforms.
• Keycloak is the open-source option for running your own IdP and consuming external ones.

For the protocol-level decision behind these flows, see enterprise SSO: SAML vs OIDC and SSO vs federation. To weigh vendors on the B2B axis, the B2B SaaS vertical and the vendor index score each on Organizations, SSO, and SCIM.