Single Sign-On: How It Works and What to Consider

What single sign-on does

Most people at work use many applications: email, calendar, file storage, accounting, HR and more. If each one has its own username and password, people end up with a pile of credentials to remember, reset and, too often, reuse. Single sign-on, usually shortened to SSO, lets a person prove who they are once and then reach multiple applications without signing in again to each.

This article explains the general mechanism, the advantages and the risks. It is not security advice, and the details of any real deployment are best settled with qualified specialists.

How it works, in outline

The exact technology varies, but the pattern is usually similar. Two roles are involved:

• An identity provider, the central service that knows the user and checks their credentials.
• Applications, sometimes called service providers, which rely on the identity provider instead of checking passwords themselves.

A typical sequence looks like this:

1. The user tries to open an application.
2. The application does not recognize them, so it redirects them to the identity provider.
3. The identity provider asks the user to authenticate, possibly with a password plus a second factor.
4. Once satisfied, the identity provider sends the application a signed message, often called a token or assertion, confirming who the user is and sometimes a few details such as their group membership.
5. The application trusts that message because it comes from the identity provider it has been set up to rely on, and lets the user in.
6. When the user opens a second application, the identity provider recognizes that they have already signed in recently, and issues a new confirmation without asking again.

Several established standards exist for passing these messages between systems. The details are technical, and what matters for most business readers is the trust relationship: each application has agreed to accept the identity provider’s word about who is signing in.

SSO deals mainly with authentication. What the user may do inside each application is still a matter of authorization, and it is a frequent misunderstanding that SSO takes care of permissions everywhere. Often it does only part of the job, by passing group or role information that the application then uses.

Benefits

• Fewer passwords. Users manage one strong credential, not many weak ones, and are less likely to write them down or reuse them.
• Better sign-in protection in one place. Controls such as multi-factor authentication can be applied at the identity provider and then cover every connected application.
• Faster account changes. When someone leaves, disabling their central identity can cut off sign-in to many systems at once, which supports the leaver process. It does not necessarily remove accounts or data inside each application.
• Fewer password resets. Resets are a large part of help desk work in many organizations, so reducing them can free time, though the effect varies.
• Better visibility. Central sign-in logs make it easier to see who accessed what.

Risks and trade-offs

SSO concentrates things, which helps and hurts.

• A central dependency. If the identity provider is unavailable, people may be unable to sign in to anything that relies on it. This is a textbook example of single points of failure. Planning for resilience, backup procedures and emergency access is important.
• A bigger prize for attackers. One compromised credential or session might open many applications. This is a reason to protect the central login strongly, to use multi-factor authentication and to take extra care with privileged accounts.
• Uneven coverage. Not every application supports SSO. Older or specialized tools may keep their own logins, creating a mixed environment that needs managing.
• Cost and effort. Connecting each application takes work, and some vendors charge more for SSO features. Check this when comparing options, which is a good subject for vendor due diligence.
• Session length. Long-lasting sessions are convenient but increase risk if a device is lost or left unlocked; shorter sessions are safer but more irritating.
• Lock-in. Once many applications depend on one identity provider, switching it later is a substantial project. This ties into vendor lock-in concerns.

Things to consider before starting

1. Which applications matter most. Start with commonly used or sensitive ones rather than trying everything at once.
2. Who owns it. Someone must be responsible for the identity service, its availability and its configuration. Clear system ownership roles help.
3. What happens when it fails. Define fallback access and communication.
4. How accounts get created and removed. SSO handles sign-in, but accounts in each application may need separate provisioning, which is where the joiner, mover and leaver process comes in.
5. User experience. Consider remote staff, personal devices and contractors who may not fit the standard pattern.
6. Support and training. People need to know what will change, and the help desk needs clear procedures.

Central or local?

A single central identity service gives consistency and simpler oversight. But a very large or diverse organization, such as one with several business units or one that has merged with another, may run more than one identity system for a time, linking them through trust relationships rather than forcing one immediately. A hybrid like this can be a practical stepping stone, particularly during post-merger integration. The right level of centralization depends on the size, risk and complexity of the organization, and the choice is best made with input from security professionals.