Single Sign-On Basics

One login, many apps

Single sign-on lets a user authenticate once with a central identity provider and then move freely between connected applications without being asked to log in again at each one. Each application trusts the provider to vouch for the user, rather than maintaining its own separate username and password store with all the duplication that entails.

The benefits compound across an organisation. Users face far less password fatigue and have fewer credentials to manage, which in turn means fewer credentials at risk of being reused or phished. Organisations gain a single place to enforce policy, monitor access, and respond to incidents. This centralisation is exactly the foundation that an OIDC-secured platform like Merion builds upon, and it is what makes a smooth, secure sign-in experience across many applications practical rather than a constant source of friction.

The identity provider

At the centre of any SSO arrangement sits the identity provider, the single system responsible for authenticating users and issuing the tokens that the connected applications trust. Those applications, often called relying parties, deliberately delegate the act of signing a user in to this provider and then accept its verdict rather than re-checking credentials themselves.

The great practical advantage of centralising identity this way is that account changes happen in exactly one place and propagate everywhere automatically. Onboarding a new starter, disabling a departing employee's access, or forcing a password reset is done once at the provider rather than being repeated, inconsistently and error-prone, across every individual application. That single point of administration is much of the operational appeal of SSO, and it is what keeps access policy coherent as the number of connected applications grows.

How OIDC enables it

OpenID Connect is one of the most common foundations for modern single sign-on, layered on top of OAuth 2.0. When a user signs in at the identity provider, OIDC returns an ID token that each connected application can verify to establish a local session, all without that application ever seeing or handling the user's actual password.

Because the mechanism is a published, widely implemented standard rather than a bespoke scheme, many different applications can interoperate with a single provider using the same well-tested libraries. That interoperability is precisely what makes SSO practical at scale: you are not writing a custom integration for every pairing, but speaking a common protocol. The underlying building blocks of identity tokens and discovery are covered in What Is OpenID Connect if you want the detail beneath the convenience.

Trade-offs to weigh

SSO inevitably concentrates risk, and that is the trade-off to weigh with open eyes. The identity provider becomes a high-value target, because compromising it could potentially affect every single connected application at once rather than just one. That concentration makes strong protection of the provider itself — and robust multi-factor authentication for the users who sign in through it — especially important rather than optional.

Set against that concentration of risk is a real and substantial upside: centralised control and, crucially, a single point at which access can be revoked across everything in one action. On balance, well-secured SSO genuinely improves an organisation's overall security posture compared with scattered, independently managed logins, but the provider must be guarded with a care that reflects just how much now depends on it.