How SAML WorksSAML operates through a series of steps to authenticate users and share identity information.

The most common scenario is the Web Browser SSO Profile, but I’ll also explain the Single Logout (SLO) process relevant to your Okta query.

Step 1. Web Browser SSO Flow

Here’s how SAML enables SSO:User Attempts to Access an SP:The user navigates to an SP (e.g., Salesforce) via their browser.

If the user isn’t authenticated, the SP redirects them to the IdP (e.g., Okta.

IdP Authenticates the User:

The IdP prompts the user to log in (if not already authenticated). Authentication can involve username/password, multi-factor authentication (MFA), or other methods. Once authenticated, the IdP generates a SAML assertion.

SAML Assertion is Sent to the SP:

The IdP sends the SAML assertion to the user’s browser, typically via an HTTP POST or Redirect binding. The assertion is digitally signed to ensure it hasn’t been tampered with.

SP Grants Access:

The SP verifies the assertion’s signature and extracts user information (e.g., identity, roles). If valid, the SP grants the user access to the application.

This process allows the user to access multiple SPs without re-authenticating, as long as their IdP session remains active.

Step 2. Single Logout (SLO) Flow

SLO extends SAML to enable a single logout action that terminates sessions across both the IdP and all connected SPs. This addresses the security risks you mentioned, such as session hijacking, XSS, and man-in-the-middle attacks.

Here’s how it works:User Initiates Logout:

The user logs out from either the IdP (e.g., Okta) or an SP (e.g., a web app). The logout request is sent as a SAML LogoutRequest message.

IdP Processes the Logout:

If the logout is initiated at the SP, the SP sends a LogoutRequest to the IdP. The IdP terminates the user’s session and identifies all SPs where the user has active sessions (based on session tracking).

IdP Notifies SPs:

The IdP sends LogoutRequest messages to each SP, typically via the user’s browser (using HTTP Redirect or POST bindings). Each SP terminates its local session and may send a LogoutResponse to confirm.

Completion:

Once all sessions are terminated, the IdP sends a final LogoutResponse to the initiating system (SP or browser), confirming the logout. The user is fully logged out across all systems.

Okta SLO Context

As your query highlighted, without SLO, logging out of an SP only clears the local session, not the Okta IdP session. If Okta redirects unauthenticated users back to the SP (a common configuration), a new session is created, negating the logout. Okta’s SAML-based SLO ensures that both the Okta session and SP sessions are terminated, reducing vulnerabilities like session hijacking or XSS by ensuring no active sessions remain.

Ask us about Solving your Single Logout via SAML for your Okta instance and custom applications.

If you have further questions, just call and lets chat your situation.

  Call today

Cloud Licensing Providers we support

Provider	Description
Dropbox	Cloud File
Google WorkSpace	Cloud Tools
Microsoft Office 365	Suite of Tools
Okta	Cloud Identity and Security
Orchestration Engine	Provisioning Engine
ProofPoint	Email Filtering
Global Relay	Email and Document Archiving