SSO Architecture: Mermaid Flowchart Diagram

About Source

Single Sign-On (SSO) is an authentication architecture that allows users to authenticate once with a central Identity Provider (IdP) and gain access to multiple applications — called Service Providers (SPs) or Relying Parties — without logging in again for each one.

The core insight of SSO is separation of concerns: applications delegate the responsibility of authenticating users to a dedicated identity service. Each application only needs to trust the IdP and know how to validate the tokens or assertions it issues. User credentials are never shared with individual applications — only the IdP ever sees them.

When a user accesses any SP for the first time, the SP detects they have no local session and redirects them to the IdP. The IdP checks whether the user has an active SSO session (typically tracked via a session cookie on the IdP's domain). If they do, the IdP issues the appropriate token or assertion immediately — transparent SSO — without prompting for credentials again. If they don't, the IdP presents a login screen. After authentication, the SSO session is established and all subsequent SP accesses in that session are seamless.

The protocol between SP and IdP is typically OpenID Connect Flow (for modern web apps and APIs) or SAML Authentication Flow (for enterprise/legacy systems). Many organizations run an IdP like Okta, Azure AD, or Keycloak that supports both protocols simultaneously.

SSO also centralizes logout: a single-logout (SLO) request to the IdP can propagate session termination to all active SPs, though many implementations only support local logout per SP. In multi-tenant systems, SSO is a per-tenant configuration — each customer brings their own IdP. This pattern is detailed in Multi Tenant Auth.

Frequently asked questions

Single Sign-On is an authentication architecture where a user authenticates once with a central Identity Provider and gains access to multiple applications without logging in again for each one. Each application trusts the IdP and validates the tokens or assertions it issues, without ever handling user credentials directly.

When a user accesses a service provider on any domain, the SP detects the absence of a local session and redirects the user to the IdP. If the IdP has an active SSO session cookie (on its own domain), it issues the appropriate token or assertion immediately without prompting for credentials. This transparent SSO works across different domains because the trust is established between each SP and the central IdP — not between the SP domains themselves.

Use SSO whenever users need to access multiple related applications and re-entering credentials for each one would create friction or security problems. SSO is standard for enterprise environments (where employees use dozens of tools), SaaS platforms with multiple products, and any situation where centralising identity management reduces the attack surface.

The most common mistakes are: not implementing Single Logout (SLO) so sessions remain active after a user believes they have logged out; trusting SP-initiated flows without validating the `RelayState` or `state` parameter, opening redirect vulnerabilities; and misconfiguring audience restrictions on tokens, allowing tokens issued for one SP to be accepted by another.

Both achieve the same goal — federated login via a central IdP — but use different protocols. OIDC uses JSON and JWTs over REST-style redirects, making it the modern default for web and mobile apps. SAML uses XML assertions delivered via browser POST, and is prevalent in legacy enterprise environments. Many enterprise IdPs (Okta, Azure AD, Keycloak) support both simultaneously, allowing mixed environments.

mermaid

flowchart TD
    U([User]) --> SP1[Service Provider 1\nCRM App]
    U --> SP2[Service Provider 2\nHR Portal]
    U --> SP3[Service Provider 3\nDev Tools]

    SP1 -- No local session\nRedirect to IdP --> IDP
    SP2 -- No local session\nRedirect to IdP --> IDP
    SP3 -- No local session\nRedirect to IdP --> IDP

    IDP[Identity Provider\nOkta / Azure AD / Keycloak]

    IDP --> SESSION{Active SSO\nsession?}
    SESSION -- Yes --> ISSUE[Issue token / assertion\nfor requested SP]
    SESSION -- No --> LOGIN[Show login screen]
    LOGIN --> AUTHN[Authenticate user]
    AUTHN --> SSO_CREATE[Create SSO session]
    SSO_CREATE --> ISSUE

    ISSUE --> SP1_GRANT[SP1 grants access]
    ISSUE --> SP2_GRANT[SP2 grants access]
    ISSUE --> SP3_GRANT[SP3 grants access]

    IDP --> USERSTORE[(User Directory\nLDAP / AD / DB)]