Single sign-on: simplifying access without compromising security

The password problem

The average business user accesses between 10 and 30 applications daily. Each one typically requires its own credentials. The result is predictable: weak passwords, reused passwords, passwords on sticky notes, and a constant stream of “forgot password” requests to the helpdesk.

This isn’t just an inconvenience - it’s a security liability. Credential reuse means that a breach of one low-value application can expose access to critical business systems. Password fatigue leads to shortcuts that undermine even the best security policies.

Single sign-on (SSO) addresses this by allowing users to authenticate once and access multiple applications without re-entering credentials.

How SSO works

At its core, SSO relies on a trust relationship between an identity provider (IdP) and one or more service providers (SPs). The IdP is the authoritative source of user identity - typically your directory service (Microsoft Entra ID, Okta, Google Workspace). The SPs are the applications your staff use (CRM, accounting, project management, communication tools).

When a user attempts to access an application:

The application redirects the user to the IdP.
The IdP authenticates the user (or confirms an existing session).
The IdP issues a security token to the application.
The application validates the token and grants access.

The user sees a single login screen. Behind the scenes, cryptographic tokens handle the rest.

The protocols

Three protocols dominate the SSO landscape:

SAML 2.0 (Security Assertion Markup Language) - the established standard for enterprise SSO. SAML uses XML-based assertions to exchange authentication and authorisation data between the IdP and SP. It’s widely supported by enterprise applications and well-understood by IT teams.

OpenID Connect (OIDC) - a modern, lightweight protocol built on top of OAuth 2.0. OIDC uses JSON Web Tokens (JWTs) and is the standard for web and mobile applications. If SAML is the enterprise workhorse, OIDC is the modern equivalent - simpler to implement and better suited to cloud-native architectures.

OAuth 2.0 - strictly an authorisation framework, not an authentication protocol. OAuth handles delegated access (e.g., allowing an application to read your calendar) but doesn’t verify identity on its own. OIDC adds the identity layer on top of OAuth.

In practice, most SSO implementations use SAML for legacy enterprise apps and OIDC for modern cloud applications.

Benefits of SSO

Improved productivity

Users log in once at the start of their day and move between applications without friction. This eliminates password entry delays, reduces login failures, and lowers helpdesk ticket volume. For a business with 100 users, even a few minutes saved per person per day adds up significantly over a year.

Stronger security posture

SSO reduces the number of credentials in play. Fewer passwords means fewer opportunities for credential theft, phishing, and reuse. Combined with multi-factor authentication at the IdP, SSO creates a single, well-defended entry point rather than dozens of individually vulnerable ones.

Centralised access control

When access is managed through a single identity provider, onboarding, offboarding, and access changes become straightforward. Disable a user in the directory and they lose access to every connected application instantly - no need to chase down credentials across 15 different systems.

Better user experience

Staff spend less time managing passwords and more time doing their work. This is especially valuable for businesses with high staff turnover or large contractor workforces, where provisioning speed directly impacts productivity.

Simplified compliance

A single authentication point produces a single audit trail. You can demonstrate to auditors exactly who accessed which applications, when, and from where - all from one console.

Risks to manage

SSO is not without trade-offs. Understanding these risks is essential to implementing it safely.

Single point of failure

If the IdP goes down, users lose access to everything. This makes IdP availability critical. Choose a provider with strong uptime SLAs, redundancy, and a clear incident response process. Many organisations maintain break-glass emergency access procedures for critical systems in case SSO becomes unavailable.

Over-provisioning

SSO makes it easy to grant access - perhaps too easy. Without proper role-based access control, users may inherit access to applications they don’t need simply because they’re in a broad group. Combine SSO with identity and access management practices that enforce least-privilege access.

Session hijacking

An SSO session token that is intercepted gives an attacker access to every connected application. Mitigate this with short session lifetimes, token encryption, and device-bound sessions where possible.

Vendor lock-in

Migrating from one IdP to another can be complex if your SSO implementation is tightly coupled to a specific vendor’s ecosystem. Use standards-based protocols (SAML, OIDC) and avoid proprietary extensions where possible.

Implementation considerations

Choose your IdP carefully

Your identity provider is foundational infrastructure. Evaluate based on:

Protocol support - does it support both SAML and OIDC?
Application catalogue - does it have pre-built integrations for the applications you use?
MFA capabilities - can it enforce multi-factor authentication with flexible policies?
Conditional access - can it apply different policies based on user role, device, location, or risk level?
Directory integration - does it sync with your existing on-premise Active Directory or cloud directory?

Audit your application landscape

Before implementing SSO, catalogue every application your business uses. Classify them:

SSO-compatible - supports SAML or OIDC and can be connected to your IdP.
SSO-capable with configuration - requires custom integration work but is technically possible.
SSO-incompatible - legacy applications with no federation support. These may need a password vault or wrapper.

Prioritise connecting high-value, frequently used applications first.

Plan for exceptions

Not every application will support SSO. For those that don’t, implement a secure password manager integrated with your IdP. This provides a consistent user experience while maintaining credential security for non-federated applications.

Test thoroughly

Roll out SSO in phases. Start with a pilot group, validate that all applications work correctly, and confirm that the login experience meets expectations before a company-wide deployment. Pay particular attention to:

Mobile access (apps may behave differently from web browsers)
VPN and remote access scenarios
Service accounts and shared mailboxes
Automated processes that authenticate via API

Combining SSO with MFA

SSO and MFA are complementary, not alternatives. SSO simplifies the user experience; MFA strengthens the authentication process. Together, they deliver convenience and security.

Best practice is to enforce MFA at the IdP level so that every SSO session begins with strong authentication. Modern IdPs support adaptive MFA, which adjusts requirements based on context - a login from a known device on the office network might require only a password and push notification, while a login from a new device in an unfamiliar location triggers additional verification.

This approach balances security with usability. Users on trusted devices experience minimal friction, while suspicious access patterns trigger appropriate scrutiny.

Getting started

Implementing SSO is one of the highest-impact improvements an organisation can make to both security and user experience. The key is to approach it methodically: audit your applications, choose the right IdP, enforce MFA, and roll out in phases.

ITHQ helps South African businesses implement SSO as part of a broader identity and access management strategy. We integrate SSO with cybersecurity operations and cloud architecture to ensure that your identity infrastructure is secure, resilient, and scalable.