SSO: Not only for logging in

Most organisations are quick to embrace Single Sign-On (SSO) — and rightly so. It’s a powerful enabler of seamless user experiences, reducing friction for customers and employees alike. But there’s a lesser-known sibling in the SSO family that deserves equal attention: Single Sign-Out (often also referred to as Single Log-Out, or SLO).

While Single Sign-On is often seen as a milestone in modern identity management, Single Sign-Out (also abbreviated as SSO — confusing, we know) is frequently overlooked. Yet, it plays a critical role in maintaining the integrity and security of federated systems. Read on to know why.

The Allure of Single Sign-On

The appeal of Single Sign-On is immediate and intuitive. Log in once, and you’re granted access to a suite of connected systems without the need to reauthenticate. For customers, this means a smoother journey. For internal teams, it translates into fewer interruptions and a more cohesive workflow. The result? A measurable boost in productivity, and both your internal users and customers will be happier.

But the benefits go beyond convenience. Single Sign-On reduces password fatigue, lowers helpdesk costs related to login issues, and supports compliance efforts by centralising authentication. It’s no wonder that most digital transformation roadmaps include Single Sign-On as a foundational capability.

Factoring in Identity Federation

In the core of Single Sign-On lies the concept of an identity federation — a trust relationship between systems that allows identities to be shared securely. When you authenticate with one system in the federation, you’re automatically authenticated across the others. It’s elegant, effective, and increasingly common. When you are 'Sarah Davis" in system A, you are also "Sarah Davis" in system B. Even if System B calls you "Mrs. Davis" or "User 123". This is called identity federation.

However, as these federations grow, so too do the implications. Imagine logging into your time-tracking system to submit hours. Do you also want to be automatically logged into the invoicing platform? Or the partner portal? The answer isn’t always yes — and that’s where things get interesting.

“Access without control is convenience without security. True trust comes from closing the door as carefully as you open it.”

The other SSO: Single Sign-Out

Now consider the reverse scenario. You log out of the invoicing system. Should that action also log you out of your email, your chat client, or your HR portal? If your systems are federated, the answer might be yes — whether you intended it or not. This is the crux of Single Sign-Out. It’s the mechanism that ensures logging out of one system terminates your session across all connected systems in the federation. In theory, it’s the natural counterpart to Single Sign-On. In practice, Sadly, it has to be more complex.

Implementing Single Sign-Out requires just as much — if not more — effort than implementing Single Sign-On. It’s akin to learning to write after learning to read. Reading (Single Sign-On) is passive — it’s about access. Writing (Single Sign-Out) is active — it’s about control. One builds upon the other, but they are not the same.

Each system in a Federation handles its user-sessions independently, making a consitent logout expierence difficult. Standards like SAML and OpenID Connect support logout, but implementations vary widely. When JWT is used for authentication, logging out happens only when those tokens time-out. And a 2 hour time-to-live is quite common with JWT. Imagine what it does to user trust when someone logs out an hour ago, only to discover they still have direct access. Implementing logout implies active token invalidation like a global blacklist of JWT's which are logged out but still valid.

The Hidden Risks of Partial Logout

Without Single Sign-Out, users can find themselves in a precarious state. They believe they’ve logged out, but their session persists elsewhere. Perhaps even more unexpectedly, they may be automatically reauthenticated by the Single Sign-On mechanism the moment they return to a system — even if they explicitly intended to end their session. "Wait — why am I still logged into HR?"

This creates a false sense of security and opens the door to unintended access. It’s a subtle but significant risk, particularly in environments where sensitive data is shared across systems.

Moreover, the boundaries of federations are not always intuitive. A poorly defined federation can lead to users being logged out unexpectedly or, conversely, remaining logged in longer than they should. Both scenarios erode trust and usability.

Security Meets Usability

Security is never just a technical concern — it’s a business imperative. And in the case of Single Sign-On, it directly intersects with user experience. The more systems you connect, the greater the potential for hacker using a compromised account to login to your other systems. A single weak link can become a gateway to your entire digital estate.

This is why thoughtful federation design is essential. Not every system needs to be part of the same SSO domain. Segmenting systems into logical groups, based on sensitivity and usage patterns, can help contain risk while preserving the benefits of SSO. Equally important is having a clear policy for session management and rights escalation.

• Who gets access to what, and under what circumstances?
• How long should sessions persist?
• What triggers a logout?

These are not just technical questions — they are governance decisions, which are directly relevant to compliance frameworks such as the GDPR, the Dutch AVG, and ISO 27001.

The Infrastructure Behind the Experience

Implementing Single Sign-On and Single Sign-Out isn’t just a matter of flipping a switch. It requires a robust technical infrastructure and careful integration with each participating system. While many platforms support standard protocols like SAML or OpenID Connect, real-world deployments often involve a degree of customisation.

At Infodation, we’ve helped numerous organisations navigate this journey. From designing federations to implementing secure logout flows, we understand the nuances that make or break an SSO strategy.

A Balanced Approach

The value of Single Sign-On is undeniable. It simplifies access, enhances productivity, and supports compliance. But it must be implemented with care. Without Single Sign-Out, the very convenience that makes Single Sign-On attractive can become a liability.

By investing in both sides of the equation — seamless login and secure logout — organisations can strike the right balance between usability and security. It’s not just about making things easier; it’s about making them safer, too.

So next time you hear someone championing Single Sign-On, ask them about Single Sign-Out. Because true commitment to user experience and security means thinking beyond the login screen.

Note: In this article we use the term Single Sign-Out. In practice, you will also often see Single Log-Out (SLO) used. Both refer to the same principle: ensuring that logging out of one system ends sessions across all connected systems.