What Single Sign-On Is and Why Your Company Wants You to Use It

TL;DR — Single sign-on (SSO) means your apps stop checking passwords themselves and instead trust your company’s identity provider (IdP, the system that proves who you are), such as Microsoft Entra ID, Google Workspace, or Okta. Your company wants you to use it because it centralizes login, lets IT turn access on and off in one place, and reduces password sprawl; the main catch is more setup and a tighter dependency on your identity system. Reading time: ~7 min

What it is and where it sits

Single sign-on is a login arrangement where multiple apps rely on one central identity system instead of each app keeping its own username-and-password database.

In plain terms: when you click Sign in with your company account, the app sends you to your company’s identity provider. You log in there, and the identity provider sends back proof of who you are. The app accepts that proof and creates your session.

What talks to it

In a typical setup, these pieces are involved:

• User browser — where the login starts.
• Application — the SaaS product or internal app you want to use.
• Identity provider (IdP) — the central login system, often your company directory.
• Directory — the user list and group list, often part of the IdP or connected to it.

Common protocols are:

• SAML (Security Assertion Markup Language, an older but still common enterprise login standard)
• OIDC (OpenID Connect, a newer login layer built on OAuth 2.0)

You do not need to memorize those names to make a business decision, but they matter during setup because the app and your identity provider must support the same one.

What it replaces

Without SSO, every app usually has its own:

• login page
• password reset flow
• user database
• MFA (multi-factor authentication, an extra proof like an authenticator app) settings
• employee offboarding process

With SSO, the app often stops storing a password for your users entirely. It may still keep an internal user record for roles, preferences, and audit history, but authentication moves out to the identity provider.

Where it lives in the request flow

SSO sits between the user and the application at the moment identity must be proven.

[User Browser] ---- 1. open app ----> [Application]
[Application] ---- 2. redirect to login ----> [Identity Provider]
[Identity Provider] ---- 3. authenticate user ----> [Directory]
[Identity Provider] ---- 4. send signed proof ----> [User Browser]
[User Browser] ---- 5. return proof ----> [Application]
[Application] ---- 6. create session ----> [App Session Store]

The important architectural point: the application still decides what you can do inside the app, but the identity provider usually decides who you are and often whether you were allowed to get in at all.

How it actually works

Let’s walk one realistic example end to end.

Scenario: an employee at Acme opens a project portal at projects.example.com and clicks Sign in with Microsoft. The portal uses OIDC with the company’s identity provider.

Step-by-step example

1. The employee visits https://projects.example.com.
2. The app sees there is no session cookie, so it shows a login button or immediately redirects to the identity provider.
3. The browser is sent to the identity provider with details like:
   • which app is asking
   • where to send the user back afterward
   • a random value to prevent login tampering
4. The identity provider checks whether the employee already has a company login session in that browser.
   • If yes, the user may not see a login screen at all.
   • If no, they enter their company email and password, then complete MFA.
5. The identity provider checks company rules:
   • Is the account active?
   • Is MFA required?
   • Is the login coming from an allowed country, device, or network?
6. If approved, the identity provider sends the browser back to the app with a short-lived code.
7. The app exchanges that code, server-to-server, for identity data. This usually includes:
   • a stable user ID
   • email address
   • name
   • sometimes group or role claims (claims are pieces of identity data sent during login)
8. The app validates the response signature and checks that it was really meant for this app.
9. The app looks up the user in its own database:
   • If the user exists, it loads their app-specific permissions.
   • If not, it may create the user automatically if auto-provisioning is enabled.
10. The app creates its own session cookie and the user lands on the dashboard.

From the user’s point of view, this feels like “one login for everything.” From the system’s point of view, each app still creates its own session; what is shared is the identity check.

Why this matters to your company

This flow gives IT a central control point. If someone leaves the company, IT can disable their account in the identity provider and cut off access to many connected apps without visiting each app’s admin screen one by one.

That is usually the real business reason behind SSO adoption: not convenience alone, but centralized access control, stronger security policies, and cleaner offboarding.

When to use it (and when not to)

Use SSO when the cost of scattered logins is higher than the cost of centralizing them.

You probably do not need this if...

• You are a very small business with only a handful of tools and no compliance or audit requirements.
• Your users are mostly external customers, not employees.
• You cannot tolerate the app depending on an external identity provider during login and you do not have a fallback plan.
• The app is temporary, low-risk, and used by a tiny group.

A useful rule of thumb: if employee joiners, movers, and leavers are handled in spreadsheets and email threads today, SSO is probably worth serious consideration.

Trade-offs

SSO is usually a good idea for business software, but it is not free magic.

The big trade-offs in plain language

• Complexity: SSO reduces user-facing mess but increases admin-facing integration work.
• Money: many vendors charge extra for SSO features, and your identity platform may also have licensing costs.
• Latency: login can be slightly slower because the browser is redirected through another system, though usually only by a second or two.
• Operational burden: certificate expiry, redirect URI mistakes, and group mapping issues can break login.
• Lock-in: once many apps depend on one identity provider, changing providers becomes a project.

The practical takeaway: SSO is often worth it for organizations, but you should treat it as infrastructure, not a checkbox.

In practice

Below are two concrete examples you can adapt. The exact screens vary by provider, so start in your provider’s admin dashboard. In many systems the path is roughly Applications or Enterprise Apps → Add application → Single sign-on.

Example 1: OIDC client settings for a web app

{
  "client_name": "Project Portal",
  "redirect_uris": [
    "https://projects.example.com/oidc/callback"
  ],
  "post_logout_redirect_uris": [
    "https://projects.example.com/"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "client_secret_post"
}

This is the kind of app registration data you enter in an identity provider when creating an OIDC app. The gotcha: the redirect_uris value must match exactly what your app uses, including https, path, and trailing slash behavior, or login will fail with a redirect mismatch.

Example 2: Environment variables an app might use for OIDC

OIDC_ISSUER=https://login.example-idp.com
OIDC_CLIENT_ID=project-portal
OIDC_CLIENT_SECRET=replace-with-real-secret
OIDC_REDIRECT_URI=https://projects.example.com/oidc/callback
OIDC_SCOPES=openid profile email

These values tell the app which identity provider to trust and where the provider should send users back after login. The gotcha: never email the client secret around or paste it into chat; store it in your hosting platform’s secret manager or environment-variable settings page.

Example 3: SAML attribute mapping used by many apps

{
  "email": "user.mail",
  "first_name": "user.givenname",
  "last_name": "user.surname",
  "groups": "user.groups"
}

This shows how an app may map incoming SAML attributes to its local user fields. The gotcha: group names and attribute names vary by provider, so test with a real user account before rolling out to everyone.

Where you usually click to set this up

For most identity providers, the flow is broadly:

1. Open your provider’s admin dashboard.
2. Go to Applications, Enterprise Applications, or App Integrations.
3. Click Add application or Create app integration.
4. Choose OIDC/OpenID Connect or SAML.
5. Paste the app’s redirect URI or ACS URL (Assertion Consumer Service URL, the SAML endpoint that receives the login response).
6. Copy the provider values back into the app:
   • issuer URL
   • client ID
   • client secret, or
   • SAML metadata / certificate
7. Assign a test user or test group.
8. Log in with that test account before assigning everyone.

⚠️ If you turn off local login before testing SSO with a second admin account, you can lock yourself out of the app. Keep one break-glass admin account (an emergency account) until SSO is proven in production.

A safe rollout pattern is:

• enable SSO for admins first
• test login, logout, and role mapping
• assign a small pilot group
• only then enforce SSO for all users

Further reading

• OpenID Connect Core 1.0
• SAML 2.0 Technical Overview
• OAuth 2.0 Authorization Framework
• The "Authentication" and "Authorization" sections of the MDN Web Docs
• NIST Digital Identity Guidelines

This article was written by an AI system and published pending human review. Verify anything you intend to act on.