How it works
The organization's identity provider holds user accounts, passwords, multi-factor authentication and access policies. Each application, called the service provider, is set up to trust that identity provider instead of keeping its own passwords.
When someone opens the app, it sends them to the identity provider. Once they are signed in there, the identity provider returns a signed assertion or token saying who they are, using a standard protocol such as SAML or OpenID Connect. The app checks the signature and lets them in.
Because access runs through one place, disabling a person in the identity provider stops them signing in to every connected app. SSO handles sign-in only; creating, updating and removing the accounts themselves is provisioning, usually done with SCIM or directory sync.
How to measure it
- List which applications still accept a local password alongside SSO.
- Confirm that multi-factor and conditional access policies apply to each connected app.
- Test offboarding: disable a test user in the identity provider and confirm access ends everywhere, including mobile apps.
Examples
- An employee opens the desk booking app on a phone, chooses to sign in with the company account, completes a multi-factor prompt and is in without a separate password.
- IT disables a leaver in the identity provider, and the person can no longer sign in to any connected workplace tool.
Common mistakes
- Turning on SSO but leaving local passwords active, so a second way in remains.
- Assuming SSO removes accounts when people leave; without provisioning, the account still exists.
- Not testing sign-in on every surface people use: web, mobile, Teams, Slack and kiosks.
How Kadence helps
Kadence supports SSO on all plans with Okta, Microsoft Entra ID, Google, OneLogin, JumpCloud and other SAML or OpenID Connect providers. Admins can make SSO mandatory or let people sign in with passkeys, and SCIM directory sync provisions users automatically. The Kadence Agent can also sign in automatically with Entra or Okta.
Security and trust · Integrations
Frequently asked questions
What is the difference between SSO and SAML?
SSO is the outcome: one sign-in that works across many apps. SAML is one of the standard protocols used to achieve it, passing a signed assertion from the identity provider to the app. OpenID Connect is the other common protocol, often preferred for mobile and modern web apps.
Is SSO secure?
Yes, when set up well. It cuts the number of passwords people reuse, puts multi-factor authentication and access rules in one place, and lets IT remove access everywhere at once. The trade-off is that the identity provider becomes critical, so protect it with strong authentication and monitoring.
What is the difference between SSO and SCIM?
SSO controls how people sign in. SCIM controls which accounts exist in each app and what they contain, creating, updating and deactivating them from the directory. Most organizations use both, so joiners get access automatically and leavers lose both sign-in and account.
Does SSO replace multi-factor authentication?
No. SSO decides where people sign in; multi-factor authentication strengthens that sign-in. The usual setup applies multi-factor checks once at the identity provider, which then covers every connected app.
Related terms
- SCIM provisioning An open standard that creates, updates and deactivates user accounts in apps automatically from the company directory.
- HRIS integration A connection that syncs joiners, leavers, teams and leave dates from the HR system into workplace software automatically.
- SOC 2 An independent auditor's report on a service provider's security controls; Type II tests that they worked over a period.
Sources
- Glossary: single sign-on, NIST Computer Security Resource Center
- Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS
- OpenID Connect Core 1.0, OpenID Foundation
Kadence editorial team · Last reviewed