Skip to main content

Persistent user sessions with single sign-on (SSO)

Single sign-on (SSO) is an authentication mechanism that allows users to access multiple applications through a single authentication event. By centralizing the authentication process, SSO minimizes the number of separate authentication prompts for end users when accessing interconnected applications.

How persistent user sessions work​

The SecureAuth platform enables organizations to set up persistent user sessions with single sign-on to allow their users to authenticate once and access multiple applications without reauthenticating.

Enable SSO

SSO offers users a streamlined experience across your applications and services. Rather than juggling multiple sets of credentials for each service, a single login grants access to your entire array of applications.

Persistent_User_Sessions_with_SSO.svg

When users approach a domain requiring authentication, they are redirected to the SecureAuth login page. If already authenticated, they are sent back to the initial domain without needing to log in again.

Session configuration options​

As a platform administrator, you can configure how long user sessions stay active before requiring reauthentication (Session Max Age). You can also set a maximum time a session can be idle before it is invalidated (Session Max Idle Time).

These settings help you balance security requirements with user convenience, ensuring sessions expire appropriately while minimizing authentication friction for legitimate users.

Logout security considerations​

When users log out of an SSO session, they need to be redirected somewhere. Applications typically want to send users to a homepage, confirmation page, or another application in your ecosystem. However, without proper controls, this creates a security vulnerability.

The open redirect risk​

If you don't control where users can be redirected after logout, attackers can exploit this through open redirect attacks:

  1. Attacker creates a malicious logout link: https://your-auth-server.com/logout?redirect_to=https://phishing-site.com
  2. User clicks the link and logs out successfully
  3. User gets redirected to the attacker's site that mimics your login page
  4. User assumes they logged out and tries to log back in, unknowingly providing credentials to the attacker

Preventing logout redirect attacks​

To prevent these attacks, you configure allowed logout redirect domains as an allowlist. This ensures users can only be redirected to trusted domains after logout.

Common use cases:

You have multiple applications across different domains:

  • Main application: app.company.com
  • Marketing site: www.company.com
  • Partner portal: partners.company.com

You would configure company.com as an allowed logout redirect domain to permit redirects to any company subdomain. You would also set a default post-logout redirect URL (such as your public homepage) for cases where the application doesn't specify a redirect destination.

This approach protects your users while maintaining flexibility for legitimate multi-application scenarios.