Benefits and Risks of Single Sign-On

The identity service becomes a critical dependency

SSO centralises access to many applications around the same identity provider or identity broker. An outage can block new logins across the organisation even while the applications themselves are healthy.

The risk is not always one server or one literal failure point. The dependency chain can include DNS, databases, key services, networks, a cloud region, an external Identity Provider, an MFA service and administrator access. Two application instances do not provide resilience if they share the same failed dependency.

Reducing the risk requires:

• availability and recovery objectives based on business impact
• a highly available architecture without unnecessary shared failure points
• capacity and load testing
• dependency monitoring and alerting
• backups and recovery that are tested in practice
• controlled administrator access during an incident
• restricted emergency accounts for named critical services only.

An emergency account needs strong protection, monitoring and regular testing. Its use must be reviewed afterwards. A broad parallel local login method weakens the benefits of centralisation and can quietly become an unmonitored back door.

What’s more important, organizations should investigate different user groups and possibly have more than one authentication orchestration environment depending on the risk analysis. The required level of security depends on the level of risk we assess.

One compromised account can have a wider impact

When one account works across several applications, compromising it can expand the attacker’s potential reach. SSO does not automatically authorise the user for everything, but an attacker can use the services available to the account and its current permissions.

Important protections include:

• phishing-resistant authentication such as a properly implemented WebAuthn flow
• least privilege and regular access reviews
• separate administrator identities instead of using the ordinary work account
• fresh or stronger authentication for critical actions
• strong protection for authenticator enrolment and account recovery
• rapid revocation of a compromised account, device and session
• monitoring suspicious activity after authentication

User education helps people recognise unusual authentication requests, but it should not be the primary protection. The technical design should limit how easily a user can be deceived into surrendering credentials.

A bad trust configuration can bypass strong authentication

Strong user authentication does not help if an application accepts a token from the wrong issuer, skips signature validation or permits an uncontrolled redirect URI. Federation security depends on both the identity provider and validation by every application.

Common risks include:

• accepting an incorrect issuer or audience
• incomplete validation of signatures, nonce values or state parameters
• overly broad or dynamic redirect URIs
• expired, exposed or unrotated keys and secrets
• an unprotected metadata or discovery source
  unsafe account linking based on email address
• inconsistent interpretation of attributes or assurance information.

Approved protocol profiles, maintained libraries, key rotation, configuration review and negative testing reduce these risks. The application must fail safely when a response is invalid or unexpected.

SSO does not fix excessive access

Authentication answers who the user is or what can be verified about them. Authorisation determines what the user may do. SSO centralises the first function, but it does not automatically maintain the second.

If roles, groups and local permissions are stale, SSO can make them easier to use without making them correct. This is a particular concern after a job change, the end of a partner relationship or when a local application account remains active.

Access governance requires:

• a named owner for every role and entitlement
  least privilege
• risk-based approval
• joiner, mover and leaver processes
• automatic expiry for temporary access
• periodic access reviews
• separate controls for administrator and service accounts.

Centralisation increases privacy and insider risk

An identity provider or broker processes user identifiers, attributes, device and location information and a broad authentication history. This makes it an attractive target for external attackers and insiders who misuse legitimate access.

Privacy controls include:

• minimising attributes and log data
• service-specific pseudonymous identifiers where suitable
  restricted administrative and read access
• a tamper-evident audit trail for administrative actions
• defined retention and deletion
• documented data flows, legal bases and party responsibilities
• periodic privacy and risk assessment.

Supplier dependence and concentrated expertise

An SSO solution can tie the organisation to product-specific features, proprietary interfaces or a supplier’s licensing model. Expertise may also become concentrated in a few people. Product, pricing or personnel changes can then threaten continuity.

Standards-based integrations, documented architecture and configuration, automated repeatable tasks, a maintained application inventory and an exit plan can reduce the risk. Standards do not remove supplier dependence, but they make integrations easier to understand and migrate