Single Sign-On (SSO) and Federation

Single Sign-On is one of the rare security controls that simultaneously improves security and user experience. Instead of forcing employees to maintain dozens of separate usernames and passwords — each one a potential breach vector — SSO lets them authenticate once and gain access to all their authorised applications. Federation extends this concept across organisational boundaries, enabling trusted access between separate organisations without sharing credentials.

For business leaders, SSO and federation are not just technical conveniences. They are strategic capabilities that reduce helpdesk costs, accelerate employee onboarding, improve security posture, and enable the kind of seamless partner collaboration that modern business demands.

How Single Sign-On Works

At its core, SSO separates the act of proving your identity from the act of accessing an application. Instead of each application maintaining its own user database and login page, all applications delegate authentication to a central Identity Provider (IdP). When a user attempts to access an application, the application redirects them to the IdP. The IdP verifies their identity (via password, MFA, biometrics, or whatever policy requires), and then sends a cryptographically signed assertion back to the application confirming “this person is who they claim to be.”

The “single sign-on” part comes from session management. Once the IdP has authenticated you, it creates a session. When you access a second application, that application also redirects to the IdP — but the IdP recognises your existing session and immediately issues an assertion without prompting you to log in again. From the user’s perspective, they logged in once and everything just works.

The Protocols: SAML, OIDC, and OAuth 2.0

Three protocols dominate the SSO landscape. Understanding the differences matters for vendor evaluation and integration planning.

SAML 2.0 (Security Assertion Markup Language) is the enterprise workhorse. Developed in the early 2000s, it uses XML-based assertions exchanged between the IdP and the Service Provider (SP). SAML is mature, widely supported by enterprise applications (Salesforce, ServiceNow, Workday, AWS), and well-understood by security teams. Its primary drawback is complexity — SAML XML messages are verbose, and troubleshooting failed assertions can be painful.

OpenID Connect (OIDC) is the modern alternative. Built on top of OAuth 2.0, it uses lightweight JSON Web Tokens (JWTs) instead of XML. OIDC is simpler to implement, better suited to mobile and single-page web applications, and increasingly preferred by newer SaaS vendors. Google, Microsoft, and Okta all support OIDC natively.

OAuth 2.0 is technically an authorisation framework, not an authentication protocol — but it’s so commonly mentioned alongside SSO that executives need to understand the distinction. OAuth allows an application to access resources on behalf of a user (for example, a project management tool reading your calendar) without the user sharing their password with that application. OIDC adds an identity layer on top of OAuth to handle authentication.

A useful mental model: SAML is for enterprise SSO into web applications. OIDC is for modern and mobile applications. OAuth 2.0 is for authorised API access between applications. In practice, most organisations need all three.

Federation: SSO Across Organisations

Federation extends the trust boundary beyond your own organisation. It allows users from one organisation to access applications or resources in another organisation without creating duplicate accounts. This is essential for partner portals, supply chain collaboration, academic research networks, and government inter-agency access.

Federation works through trust relationships between Identity Providers. Organisation A’s IdP and Organisation B’s IdP agree to trust each other’s assertions. When a user from Organisation A needs to access Organisation B’s system, their home IdP issues an assertion that Organisation B’s system accepts — without Organisation B ever seeing or storing the user’s credentials.

Hub-and-Spoke vs Mesh Federation

Hub-and-spoke uses a central federation broker or gateway. All partner organisations connect to the hub, and the hub handles trust translation between them. This model scales well — adding a new partner means one new connection to the hub, not connections to every existing partner. Microsoft Entra ID B2B, Okta Org2Org, and dedicated federation brokers like Shibboleth (common in higher education) use this pattern.

Mesh federation involves direct bilateral trust relationships between every pair of organisations. This gives each organisation maximum control and visibility but becomes exponentially complex as partners increase. With five partners you have ten trust relationships; with twenty partners you have one hundred and ninety. Mesh federation is typically only viable for small, stable consortia.

SSO Benefits and Risks

The business case for SSO is compelling, but it must be balanced against real risks.

Benefits:

• Reduced password fatigue: Users manage one set of credentials instead of dozens, dramatically reducing the temptation to reuse passwords or write them down.
• Lower helpdesk costs: Password resets typically account for 20-50% of helpdesk tickets. SSO eliminates this for integrated applications.
• Faster onboarding and offboarding: Grant or revoke access to all integrated applications through a single identity, instead of configuring each application individually.
• Stronger security posture: Centralised authentication means you can enforce MFA, conditional access, and session policies once, and they apply everywhere.
• Better audit trails: All authentication events flow through a single IdP, giving you comprehensive visibility into who accessed what and when.

Risks:

• Single point of failure: If your IdP goes down, users cannot access any integrated application. This makes IdP availability critical — review your provider’s SLA and build redundancy planning into your architecture.
• Blast radius of compromise: If an attacker compromises a user’s SSO credentials, they gain access to every application that user can reach. This is why SSO must always be paired with strong MFA — SSO without MFA is more dangerous than no SSO at all.
• Incomplete coverage: Applications that don’t support SAML or OIDC remain outside the SSO perimeter, creating shadow authentication silos. Track these gaps actively.

SCIM: Automated User Provisioning

SCIM (System for Cross-domain Identity Management) complements SSO by automating the creation, updating, and deletion of user accounts in downstream applications. Where SSO handles authentication (“let this person in”), SCIM handles provisioning (“create an account for this person with these attributes and these group memberships”).

Without SCIM, your IT team must manually create accounts in each application when someone joins, update them when roles change, and delete them when someone leaves. With SCIM, these lifecycle events propagate automatically from your IdP to all connected applications. This is particularly important for offboarding — SCIM-connected applications will automatically disable the leaver’s account when their identity is deactivated in the IdP.

Why This Matters

Organisations without SSO are statistically more likely to suffer credential-based breaches. Every additional password a user manages increases the probability of password reuse across personal and work accounts. SSO eliminates this class of risk for every application it covers. Federation, meanwhile, eliminates the dangerous practice of creating “guest accounts” with locally managed credentials for external partners — a practice that leads to orphaned accounts and audit gaps.

What to Do Now

• Inventory your SaaS applications and categorise them: currently integrated with SSO, capable of SSO but not yet integrated, and not SSO-capable.
• Check whether your IdP supports SCIM provisioning and identify which applications support SCIM on their end.
• Review your IdP’s availability SLA and determine whether your SSO architecture has adequate redundancy.
• Verify that MFA is enforced for all SSO-authenticated sessions — SSO without MFA increases rather than decreases risk.
• If you have external partners accessing your systems, assess whether you’re using federation or managing guest accounts manually.

Evidence to Collect

• A list of all applications integrated with SSO, showing which protocol each uses (SAML, OIDC).
• Documentation of any applications not yet integrated with SSO and the plan to address them.
• Evidence of SCIM provisioning configuration for key applications.
• Your IdP’s uptime SLA and your disaster recovery plan for IdP outages.
• MFA enforcement policy for all SSO-authenticated sessions.

Common Mistakes

• Deploying SSO without MFA. This is the single most common and most dangerous mistake. SSO without MFA means one compromised password gives an attacker access to everything. Always enforce MFA at the IdP level.
• Leaving applications outside SSO. Every application not integrated with your IdP is a shadow authentication silo with its own password policies, no centralised monitoring, and no automated deprovisioning. Treat SSO coverage as a metric and drive it toward 100%.
• Ignoring session timeout policies. SSO sessions that never expire are a security risk. Balance user convenience with security by setting appropriate session lifetimes and requiring re-authentication for sensitive operations.
• Treating federation as purely an IT decision. Federation establishes trust relationships with external organisations. Legal, compliance, and business stakeholders must be involved in defining what access federated partners receive and under what conditions.

---

Knowledge Check

---