What Is Single Sign-On (SSO) and How Does It Work?

Single sign-on (SSO) lets you authenticate once with a central identity provider and then open other trusted applications without entering your credentials again. Each application still has its own session; what gets reused is your authenticated session with the identity provider.

Closing one tab, or signing out of one app, does not always clear every other session. The rest of this page shows why.

What Is SSO?

Single sign-on is an authentication pattern where you prove your identity once to a trusted identity provider (IdP), then access multiple applications that trust that IdP without re-entering credentials for each app.

SSO is not:

• Sharing your password with every application
• The same thing as a password manager that fills different passwords per site
• A guarantee that logging out of one app ends every other session

Authentication (who you are) is still separate from authorization (what you may do). See Authentication vs authorization.

Components of SSO

Most browser-based SSO flows involve three main participants:

In SAML the application side is often called the service provider (SP). In OpenID Connect it is a relying party (RP) or OIDC client. The idea is the same. For those role names in more detail, see IdP vs service provider.

Why the application trusts the IdP

SSO works because the application and IdP are configured to trust each other beforehand. For example:

• In OIDC, the application trusts a specific issuer and uses that provider’s published public keys to verify signed tokens
• In SAML, the application knows the IdP’s metadata and signing certificate

The application does not trust data simply because it came through the browser. It verifies that the response was issued by the expected IdP and intended for this application. That includes checking the cryptographic signature and protocol-specific values such as issuer, audience, expiry, and return destination. For example, it checks the signature on a SAML assertion or verifies an OIDC token using the IdP’s published signing keys.

             federation configuration
        ┌───────────────────────────────┐
        │                               │
        ▼                               ▼
      App A                       Identity Provider
                                   (Keycloak)

        ▲                               ▲
        └───────── Browser ─────────────┘
              follows login flow

“Trust” here means both systems have compatible federation configuration. It does not necessarily mean both sides exchange certificates or authenticate each other in exactly the same way. After authentication, the browser carries the SAML response or OIDC authorization code back to App A. In the OIDC Authorization Code flow, App A then exchanges the code directly with the IdP’s token endpoint.

How to read this diagram:

• The browser opens App A.
• App A already has federation configuration for the Identity Provider (for example Keycloak).
• During login, the browser follows the login flow between App A and the IdP.
• After authentication, the IdP’s result returns through the browser to App A.
• App A verifies that result and creates its own session.
• App B can use the same pattern with the same IdP. Apps do not share passwords or one common application cookie.

SSO is possible because both App A and App B trust the same identity provider.

How SSO Works Step by Step

The first application you open usually triggers a full login. The second application often reuses the IdP session so you never see the password form again.

First application (full authentication)

  Browser                 App A                    Identity Provider
     |                      |                              |
     |---- Open App A ----->|                              |
     |<--- Redirect to IdP -|                              |
     |---------------------------------------------------->|
     |<------------------- Login page ---------------------|
     |---------------- Credentials / MFA ----------------->|
     |<------ Authentication response / code --------------|
     |--------------------->|                              |
     |                      |                              |
     |                      | SAML: validate assertion     |
     |                      |       locally                |
     |                      |                              |
     |                      |-- OIDC: exchange code ------>|
     |                      |<------ OIDC tokens ----------|
     |                      |                              |
     |<--- App A session ---|                              |

What happens in this flow:

• You open App A. It has no local session for you, so App A redirects the browser to the IdP.
• The IdP shows its login page. You authenticate (password, MFA, passkey, or whatever the IdP requires).
• The IdP creates an IdP session and sets a cookie on the IdP domain.
• The IdP returns the browser to App A with an authentication response or code. With SAML, that is commonly a SAML Response delivered through the browser (often HTTP POST). With the common OIDC Authorization Code flow, the browser returns with an authorization code.
• With the common SAML HTTP POST flow, App A validates the SAML Response/assertion locally using the IdP’s configured public certificate. It normally does not send that assertion back to the IdP for validation.
• For a server-side OIDC application, the code-to-token exchange happens directly between the application and the token endpoint, so the tokens do not pass through the browser redirect. Public clients such as SPAs also exchange the code, normally using PKCE, but the client itself runs in the browser.
• After validation (SAML) or the token exchange (OIDC), App A creates its own application session, often a cookie on the App A domain.

At this point you typically have:

• An IdP cookie: this browser already authenticated at the IdP
• An App A cookie: this browser is signed into App A

Second application (reuse IdP session)

  Browser                 App B                    Identity Provider
     |                      |                              |
     |---- Open App B ----->|                              |
     |<--- Redirect to IdP -|                              |
     |---------------------------------------------------->|
     |                      |   existing IdP session found |
     |<------ New authentication response / code ----------|
     |--------------------->|                              |
     |                      |                              |
     |                      | SAML: validate assertion     |
     |                      |       locally                |
     |                      |                              |
     |                      |-- OIDC: exchange code ------>|
     |                      |<------ OIDC tokens ----------|
     |                      |                              |
     |<--- App B session ---|                              |

What happens in this flow:

• You open App B in the same browser. App B has no local session, so it redirects you to the same IdP.
• The browser automatically sends the existing IdP cookie.
• If the existing IdP session is still valid and App B does not require fresh authentication, the IdP recognizes the user and does not show the login form again.
• The IdP does not reuse App A’s token or session. It issues a new authentication response for App B (a new SAML assertion, or a new OIDC authorization code).
• With SAML, App B validates the new assertion locally. With OIDC, App B exchanges its own code for its own tokens.
• App B creates its own application session on the App B domain.

This is the key SSO step: App B gets its own session without asking the user to authenticate again.

                       Identity Provider
                         (Keycloak)
                    ┌─────────────────────┐
                    │ IdP login session   │
                    │ IdP-domain cookie   │
                    └──────────┬──────────┘
                               │
                   existing login reused
                      ┌────────┴────────┐
                      │                 │
                      ▼                 ▼
                ┌──────────┐       ┌──────────┐
                │  App A   │       │  App B   │
                │ session  │       │ session  │
                │ cookie   │       │ cookie   │
                └──────────┘       └──────────┘

How to read this diagram:

• The shared part is the IdP login session.
• App A and App B still create and manage their own sessions independently.

In a typical browser-based setup, you now have one login session at the IdP and separate application sessions for App A and App B. These are normally represented by cookies scoped to their respective domains; the applications do not share one common application cookie.

IdP Session vs Application Session

The easiest way to understand SSO is to separate the IdP session from each application’s own session.

Keep these rules in mind:

• An active IdP session does not mean every app is open. Each app still needs its own session or valid tokens.
• An active App A session does not require the IdP cookie to stay forever. App A may keep working until its own cookie or tokens expire.
• Closing a browser tab does not clear cookies by itself.
• Different apps can expire at different times even though SSO felt shared.

When App A’s session expires while the IdP session is still valid, many apps silently redirect to the IdP, get a fresh authentication result, and renew the app session without showing a login form. To the user, this looks like the login never expired, but the application actually renewed its session by reusing the still-valid IdP session.

How SAML and OIDC Provide SSO

SSO is the pattern. SAML and OpenID Connect (OIDC) are common protocols that implement it.

What both share for browser SSO:

• Redirect the user to the IdP when the app has no session
• Create or reuse an IdP session cookie
• Return an audience-specific authentication result the app can verify
• Let the app create a local session after validation

SSO does not require SAML. Many modern apps use OIDC. An organization may use SAML for some applications and OIDC for others. Protocol comparison details live in OAuth vs OIDC vs SAML.

OAuth 2.0 alone is primarily an authorization framework for API access. OIDC adds the identity layer (who logged in) that most “Sign in with …” SSO experiences need.

SP-Initiated vs IdP-Initiated SSO

SP-initiated SSO begins when the user opens an application and is redirected to the IdP. This is the most common flow and applies naturally to both SAML and OIDC.

IdP-initiated SSO usually refers to SAML, where a user starts from an IdP portal and launches an application directly.

The IdP and application roles stay the same. Only the starting point changes.

SSO vs a Password Manager or Reusing the Same Password

These three approaches are often confused:

A password manager improves convenience and unique passwords. It does not create a shared IdP session. Typing the same password into five apps is also not SSO. Each app still runs its own login, and a breach at one site can reuse that password elsewhere.

True SSO moves authentication to one IdP. Applications receive proof of authentication. They should not receive your IdP password.

Benefits and Limitations of SSO

Benefits:

• Fewer repeated logins across trusted apps
• Fewer passwords for users to manage
• Central place to enforce login policies such as MFA

Limitations:

• IdP availability becomes important — if the IdP is unavailable, users may be unable to start new SSO sessions
• One compromised central identity can affect multiple applications
• Logout and session behavior must be understood (they are not one shared session)

SSO improves the login experience. It does not replace authorization design inside each application.

Does Logging Out of One App Log You Out of Everything?

Often no. The reason is that logging out of one application does not automatically end the IdP session or the sessions of other applications.

Single Logout (SLO) is the idea that ending a session in one place should end related sessions elsewhere. Protocols define options for that, but real deployments vary.

What usually happens when you click Logout in one app:

1. The app clears or invalidates its application session
2. The app may also redirect to the IdP logout endpoint
3. If the logout flow also reaches the IdP’s logout endpoint, the IdP can end its own SSO session
4. Other applications may still retain their own local sessions unless coordinated logout is configured

Do not assume universal logout until you have tested the protocol, client settings, and logout endpoints for every app in the portfolio.

How SSO Works in Keycloak

Keycloak is an open-source identity provider. In Keycloak, applications registered in the same realm can use Keycloak as their common identity provider. After you authenticate to Keycloak, the browser has a Keycloak SSO session. When another client redirects you to the same realm, Keycloak can recognize that existing session and skip the login form — assuming that client’s authentication requirements do not force reauthentication.

In practice:

• Users authenticate against Keycloak (local users, LDAP, or brokers)
• Keycloak sets an SSO session for the browser on the Keycloak host
• Each client receives OIDC tokens or a SAML assertion and builds its own application session

This page does not configure realm SSO idle or max lifetimes, client session timeouts, or front-channel or back-channel logout wiring. Those controls matter once you understand the two-session model above. For local users, see Create and manage Keycloak users. For a first lab container, start from Install Keycloak with Podman.

Summary

Single sign-on means authenticating once at an identity provider, then letting multiple applications trust that result. Apps and the IdP are configured to trust each other beforehand. The browser carries an IdP session. Each application still creates its own session after it validates a SAML assertion or OIDC tokens.

The reason the second application does not show another login form is the existing IdP session. A common misunderstanding is that all applications share one session. They do not. Application sessions and IdP sessions have different owners, domains, and lifetimes.

With Keycloak, that IdP role lives in a realm with registered clients. The same two-session model still applies. When you are ready to go deeper, continue with the IdP versus SP roles article and the OAuth versus OIDC versus SAML comparison linked earlier.

References

• Auth0 — What is Single Sign-On (SSO)?
• Curity — Sessions and Single Sign-On
• Okta — What is Single Sign-On and How SSO Works
• OpenID Connect Core 1.0
• OASIS SAML 2.0
• Keycloak Server Administration Guide