What is Single Sign-On (SSO)?

Definition: Single Sign-On (SSO)

Single sign-on (SSO) is an identity strategy and technology that allows a user to authenticate once and gain access to multiple applications without re-entering credentials. Instead of each app keeping its own username/password, SSO centralizes authentication with an Identity Provider (IdP), which issues cryptographically signed tokens to participating apps. If you’re asking what is Single sign-on, think of SSO as “one secure front door” for all your apps—simple for users, governable for IT, and measurable for the business.

‍

How SSO works (plain-English walkthrough)

1. User tries to open an app (the Service Provider, or SP).
2. The app says, “I don’t do passwords—ask the IdP,” and redirects the user.
3. The IdP authenticates the user (passwordless/passkey, MFA, or whatever policy requires) and issues a signed token asserting the user’s identity and attributes.
4. The app validates the signature, checks claims (e.g., email, role, group), and starts a session—no second login prompt.
5. As the user visits other SSO-enabled apps, those apps accept the existing session at the IdP and grant access seamlessly.

Behind the scenes this runs over federation standards like SAML 2.0 (widely used for enterprise web apps) and OpenID Connect (OIDC) (JSON/REST-friendly, common for modern SaaS and mobile). For on-prem Windows environments, Kerberos provides SSO on the LAN; many organizations bridge Kerberos/AD with SAML or OIDC for cloud apps.

‍

Why SSO matters

For users: fewer prompts, fewer passwords, less context-switching.
For security: central policies (MFA, device posture, risk scoring), less password reuse, and fewer stale accounts scattered across apps.
For IT/Finance: lower Help Desk ticket volume, faster app onboarding, clearer license usage, and auditable access trails.

If you’re prioritizing where to start, use your risk lens. The Cyber Security Risk Assessment Checklist for Business can help you pick the first set of apps where SSO and MFA cut real risk quickly.

‍

Protocols, tokens, and what to choose

• SAML 2.0: XML-based assertions, battle-tested for enterprise SaaS (e.g., HRIS, CRM). Ideal for browser apps.
• OpenID Connect (OIDC): A thin identity layer atop OAuth 2.0, returning ID tokens (JWTs) and enabling API-friendly sessions on web and mobile.
• OAuth 2.0 (authorization): Grants access tokens to call APIs on a user’s behalf; pair with OIDC when you also need authentication.
• Kerberos/NTLM: Legacy SSO inside Windows AD networks; typically fronted by federation to reach SaaS.
• FIDO2/WebAuthn (passkeys): Phishing-resistant, passwordless authentication at the IdP—pairs perfectly with SSO to kill passwords.

Rule of thumb: OIDC for modern apps and APIs, SAML for older SaaS that supports it, and use passkeys (or at least MFA) at the IdP to raise assurance.

‍

Access decisions: more than “are you logged in?”

SSO centralizes who you are; combine it with context to decide how you get in:

• MFA & step-up: Trigger MFA only for risky sign-ins (new device, unusual geo, admin role).
• Conditional access: Require compliant devices, trusted networks, or low-risk signals to grant full access; otherwise, degrade or block.
• Just-in-time (JIT) provisioning: Create an account on first login based on claims (email, group).
• SCIM provisioning: Sync identities, groups, and deprovisioning continuously so access matches employment changes.

‍

Benefits (and proof you can take to leadership)

• Reduced friction: One login → higher adoption of secure workflows, fewer sticky notes of passwords.
• Fewer tickets: Password resets are a top Help Desk cost; SSO plus passwordless cuts this materially.
• Stronger control: One place to enforce MFA, risk-based policies, and session lifetime.
• Faster audits: Central sign-in logs and app-level assertions streamline evidence for GRC and customer questionnaires.
• Safer third parties: Contractors and partners sign in via their IdP (B2B federation) so you don’t manage their passwords.

‍

Common pitfalls (and how to avoid them)

“Single point of failure.” If the IdP is down, people can’t work. Fix: run the IdP in high availability across regions; enable grace periods/offline tokens for critical apps; publish an outage plan.

MFA that’s easy to phish. SMS/OTP can be socially engineered. Fix: enable phishing-resistant methods (FIDO2 passkeys, platform authenticators) for admins and high-risk roles first.

Overbroad access. SSO centralizes logins but can also centralize mistakes. Fix: use least privilege with role-based claims, regular access reviews, and SCIM deprovisioning.

Shadow IT bypass. Users buy SaaS that isn’t tied to SSO. Fix: discover with CASB/SaaS management and standardize procurement on SSO-capable vendors.

Token misuse. Long-lived tokens and skipped audience checks are risky. Fix: shorten lifetimes, require PKCE for public clients, validate audience/issuer, and use DPoP/mTLS for high-value APIs.

‍

Architecture patterns you’ll use

• IdP-initiated vs. SP-initiated: IdP-initiated is convenient (“app launcher”) but can be spoofed in poor implementations; prefer SP-initiated for security-sensitive apps or ensure RelayState handling is robust.
• Directory integration: Sync Active Directory or other HR-driven sources into your IdP; designate HR as the source of truth for employment status.
• Claims mapping: Map groups/attributes (department, cost center, role) into tokens so apps know who gets what.
• B2B federation: Trust partner IdPs so suppliers log in with their identity; layer conditional access so risky partners have constrained scopes.

‍

Security best practices (make it safe by default)

• Make MFA the norm at the IdP; require passkeys or hardware keys for admins.
• Short sessions for sensitive apps; re-auth for high-risk actions (payroll changes, data exports).
• Conditional access tied to device posture from UEM; block unknown devices, require encryption and minimum OS.
• Rotate signing keys/certs on a schedule; monitor for old certs lingering.
• Centralize logs (IdP and app assertions) to SIEM; create detections for impossible travel, unusual client types, or spikes in MFA failures.
• Educate users that legitimate SSO prompts should match your known domain and branding; teach them to spot consent phishing (malicious OAuth apps).

‍

Rolling out SSO: a pragmatic, low-drama plan

1. Define success. Pick outcomes you can measure: reduce password resets by 40%, reach 95% MFA coverage, integrate top 20 apps.
2. Inventory apps and classify risk. Start with crown jewels (email, CRM, HR/payroll) and apps that hold customer data.
3. Choose your standard. Default to OIDC for new apps, SAML where required, and set a passkey-first policy at the IdP.
4. Pilot with a friendly department. Integrate 5–7 apps, enable MFA, and validate login flows, roles, and break-glass accounts.
5. Turn on SCIM. Automate provisioning/deprovisioning and map roles to groups; remove manual account creation.
6. Harden the edge. Enforce conditional access and device posture; turn off password logins where passkeys are supported.
7. Expand in waves. Tackle 15–25 apps per month; publish a simple “SSO or no go” vendor standard.
8. Measure & iterate. Track sign-in success rate, MFA adoption, help tickets, and risky sign-in detections; tighten policies quarterly.

‍

SSO for hybrid and remote work

Remote users live in browsers and SaaS. Pair SSO with Zero Trust Network Access (ZTNA) for private apps so users connect per-app, not via broad VPNs. Add Secure Service Edge (SSE) controls—SWG for safe browsing and CASB for SaaS governance—so identity-driven policy follows users everywhere. On managed devices, UEM assures posture; on unmanaged, restrict to low-risk scopes or virtual desktops.

‍

Governance, audits, and evidence

Auditors will ask: Who can access what, why, and how do you know? Answer with:

• IdP policies (MFA, session, conditional access) and change history.
• Provisioning logs (SCIM) that show timely deprovisioning and role changes.
• Sign-in analytics with anomaly detections and incident handling notes.
• Access reviews for sensitive apps, approved by business owners.

Bundle these into your GRC workflow so reviews and exceptions don’t get lost in email threads.

‍

Measuring success (KPIs that matter)

• MFA coverage (overall and by role).
• Help Desk tickets related to credentials (aim for steep decline).
• Sign-in success rate and time-to-first-access for new hires.
• Timely deprovisioning (median minutes from HR termination to app lockout).
• Adoption: % of apps behind SSO; % of SaaS discovered that support SSO.
• Risk signals: declines in impossible travel, consent phishing, and brute-force events.

‍

Edge cases and legacy apps

• No SAML/OIDC? Use header-based SSO via a gateway or publish behind ZTNA with a captive portal.
• Thick clients/older protocols? Leverage modern auth plugins or app proxies; when impossible, segment and monitor closely.
• B2E mobile apps? Prefer OIDC + PKCE; avoid embedding client secrets in mobile binaries.

‍

Related Solutions

SSO becomes dramatically more effective when paired with a broader identity-first stack. Secure Service Edge (SSE) enforces safe browsing and SaaS controls using the same identities and groups. Device health comes from Unified Endpoint Management (UEM), and proof lives in Security Information and Event Management (SIEM) with a Security Operations Center (SOC) watching sign-ins and anomalies. To keep privileges right-sized, align SSO with Governance, Risk and Compliance (GRC) reviews, and for smoother adoption and fewer tickets, lean on Security Awareness Training (SAT) to coach users through new, passwordless flows.