Skip to main content

​
Security considerations with SSO

SSO Connections in Stytch are scoped to a specific Organization and SSO authentication is non-transferable between Organizations. This means that an end user who authenticates via one Organization’s SSO Connection will need to perform another authentication flow in order to Session Exchange into another Organization they belong to under the same email. The reason for this restriction is that the workforce IdP can attest to whatever user identity it wants in SSO authentication, without any proof of verification. This is expected and desired when the Organization is also the owner of the workforce IdP instance, as it is the ultimate source of truth on their employees’ identities and access. However, allowing authentication into other Organizations via that SSO Connection introduces a security vulnerability; if that workforce IdP is compromised, SSO could then be used by a malicious attacker to access any other Organization’s instance by having the workforce IdP attest to emails of Members of those Organizations.

​
Supporting multi-Organization access

While the vast majority of SSO Connections are typically only used to log into a single Organization, there are a few scenarios where you may want end users to be able to authenticate into multiple Organizations via a single SSO Connection:
  1. Single company has multiple Organization instances, due to M&A activity or wanting to keep international subsidiaries or distinct departments separate
  2. Managed Service Providers (MSPs) who help maintain multiple companies’ Organization instances
In order to address these use cases in a secure and controlled way, Stytch offers the concept of External SSO Connections, which allows an Organization to explicitly specify another Organization’s SSO Connection as a trusted and valid authentication option for their Members. This eliminates the need to re-configure the SSO Connection for every Organization that wants to allow authentication through a given IdP instance, while still maintaining clear boundaries and control between Organizations. The underlying SAML or OIDC Connection is still “owned” by the Organization that originally configured it, but each Organization that has allowed the SSO Connection as an External Connection has its own controls over Just-in-Time (JIT) Provisioning and role assignments and can choose to sever the Connection at any point.

​
Implementing External SSO Connections

​
Configuration

Organization admins can create External SSO Connections via the Admin Portal SSO UI Component by:
  • Clicking New Connection
  • Selecting Add an external connection
  • Inputting the ConnectionID they wish to allow and the owning OrganizationID
They can then configure JIT Provisioning settings or automatic role assignments for users authenticating through this shared connection. You can also configure this via Direct API by calling CreateExternalConnection or in the Stytch Dashboard within the Organization page that wishes to add the External SSO Connection

​
Initiating SSO

You can initiate SSO with an External SSO Connection in the same way that you would with any other SSO Connection: 
stytch.sso.start({
    connection_id: 'external-connection-test-5c44cc6a-8af7-48d6-8da7-ea821342f5a6'
});

​
SSO Discovery

If you are using SSO Discovery via our pre-built UI components or headless FE SDK, External SSO Connections will be deduped down to a single Connection in order to display to the end user and initiate the SSO Start. Upon successful SSO authentication, we will automatically redirect the user to an Organization in a logged in state. If the user is part of the “owning” Organization, we will redirect them there. Otherwise, we will redirect them to the oldest Organization that they belong to and can access via this External SSO Connection. Once the user is logged in, they can Session Exchange into any other Organization that shares this External SSO Connection.