Identity and Access

Single Sign-On for Everyday Users

Single sign-on lets one sign-in unlock many applications. See how it works in everyday terms, what it improves, and the trade-offs organizations should weigh.

On this page
  1. One sign-in, many applications
  2. How it works, without the jargon
  3. What it improves
  4. The trade-offs
  5. Using it well as an everyday user
  6. Questions for an organization considering it

One sign-in, many applications

Most people at work use a long list of tools: email, calendar, chat, a document store, a ticket system, perhaps a payroll portal. Without single sign-on, each one has its own username and password, and each one asks you to prove yourself separately. Single sign-on, often shortened to SSO, replaces that with one central sign-in. Once you have signed in there, the other applications accept that you are verified and let you through without asking again.

From the user’s side, the experience is simple: sign in once in the morning, then click on applications as needed.

How it works, without the jargon

Behind the scenes, there are two kinds of parties. The identity provider is the central service that holds your account and checks your credentials. The applications (sometimes called service providers) are the tools you want to use.

When you open an application that is connected to SSO, it does not ask for a password. Instead, it redirects you to the identity provider. If you are already signed in, the provider quietly confirms that fact. If not, it asks you to sign in. Either way, it then sends the application a signed message saying, in effect, “this is Alex, and I have verified them.” The application trusts that message because it has a pre-arranged relationship with the provider, and it lets you in.

Your password is only ever typed into the identity provider, not into each application. Several standard technical protocols describe how that message is exchanged, and applications that support them can usually be connected without custom work. Details of those protocols are beyond what most users need.

What it improves

Fewer passwords. People with fewer passwords to remember are less likely to reuse them or write them down. It can also reduce the number of “I forgot my password” calls to the IT help desk.

A stronger single sign-in. Because everything depends on one login, it is worth protecting well. Adding multi-factor authentication at that one point protects every connected application at once, rather than requiring each to be configured separately.

Faster onboarding and offboarding. When someone joins, giving their central account access to the right applications can be done in one place. When they leave, disabling the central account cuts off all connected applications quickly. This is one of the clearest benefits for account offboarding.

Central visibility. Sign-in activity is recorded in one place, which makes it easier to spot unusual patterns and to answer who accessed what.

Consistent rules. Password requirements, session lengths and sign-in restrictions can be applied once rather than inconsistently in a dozen tools.

Less friction. Productivity improves when people are not repeatedly interrupted by login screens.

The trade-offs

Honest assessment includes the downsides.

A bigger prize for attackers. If someone steals a person’s central credentials and no second factor is required, they may reach everything connected. The convenience that helps users also concentrates risk, so strong protection of the central account is not optional.

A single point of failure. If the identity provider is unavailable, people may be unable to sign in to anything. Organizations should understand how dependable their provider is and whether there is a fallback for critical systems. This ties into planning for business continuity.

Not everything connects. Older or specialized applications may not support SSO, leaving a mix of old and new logins. Some applications keep their own local accounts, such as an administrator account, in addition to SSO, and these can be forgotten.

Access is still a separate decision. SSO confirms who you are. It does not by itself decide what you can do inside each application. Permissions still need to be managed, a distinction explained in discussions of authentication and authorization. Sensible roles and least privilege still apply.

Setup takes effort. Connecting each application requires configuration and testing, and mistakes in the setup can create gaps.

Long sessions raise risk. Staying signed in for convenience means a borrowed or unattended device could open many applications. Balancing session length against convenience is a judgment call.

Using it well as an everyday user

  • Protect your main password carefully; it is worth making it long and unique, and a password manager can help you do so.
  • Use the second factor whenever it is offered.
  • Lock your screen when you step away, since a signed-in session opens many doors.
  • Be wary of unexpected sign-in prompts or pages that ask for your central login after clicking a link in a message. Fake sign-in pages are a typical phishing method, and security awareness training helps in recognizing them.
  • Report a lost device or any unexplained approval request promptly.

Questions for an organization considering it

Which applications matter most and do they support it? How will the central account be protected? What happens if the provider is unavailable? Who manages the connections and reviews them? How will leavers be removed from the provider and from any applications that keep local accounts?

SSO is not a cure-all, and it works best as part of a broader approach. For many organizations, though, it is a practical way to reduce password fatigue and bring access under a single, better-protected control point, provided the trade-offs are understood in advance.

The complete guide to identity and access

Identity and Access Management Explained
Read the guide

Keep exploring

Guides from other topics

All topics →