Single sign-on (SSO) lets people use several systems and cloud services after logging in only once. An employee signs in with their company account and can then open email, time tracking and expense tools without typing a separate password for each. For IT teams, the benefit is that accounts are created and disabled in one place. This article explains how SSO works, how SAML and OpenID Connect differ, and how to add SSO to a SaaS product you sell to businesses.
How SSO works
SSO involves two roles:
- Identity provider (IdP): the side that confirms who the user is. Microsoft Entra ID, Google Workspace and Okta are typical examples, where a company manages its employees’ accounts
- Service provider (SP): the system the user wants to use. A SaaS product you offer, or an internal system, plays this role
The flow goes like this:
- The user opens the SP, for example an expense management SaaS
- The SP sends the user to the IdP’s login page
- The user signs in at the IdP (skipped if they are already signed in)
- The IdP hands the SP a proof of who the user is: a SAML assertion or an OpenID Connect ID token
- The SP verifies the proof’s signature and issues its own session
The SP holds no password; it trusts the IdP’s proof. That means SSO is only as secure as the IdP login.
SAML vs. OpenID Connect
| Aspect | SAML 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Standardised by | OASIS (2005) | OpenID Foundation (2014) |
| Format of the proof | XML assertion | JSON ID token (JWT) |
| Foundation | Its own specification | An identity layer on top of OAuth 2.0 |
| Strengths | Enterprise web systems, with wide support in long-established business software | Web plus mobile apps and API-centric setups |
| Implementation | Verifying XML signatures is complex | Plenty of libraries, comparatively easy to handle |
The major identity providers support both. Many enterprise buyers make “SAML support” a contract requirement for B2B SaaS, so ask what your customers need before choosing.
Steps to add SSO to your service
- Decide who gets it. Choose whether SSO is available on every plan or only higher tiers, and make it possible to turn on or off per customer (tenant)
- Map tenants to identity providers. Decide which customer’s IdP to send a user to, based on their email domain or a tenant-specific login URL
- Decide how accounts are linked. Match the immutable user identifier sent by the IdP to the user in your service. Email addresses can change, so do not use them as the primary key
- Decide what happens on first login. Either create accounts automatically for anyone the IdP lets in, or admit only users an administrator registered in advance
- Connect deactivation. When the IdP disables an employee, your service should disable their account and sessions too. SCIM (RFC 7644) can sync account creation and deactivation
- Decide on other ways in. For tenants with SSO enabled, decide whether password login remains. Keeping it creates a loophole; removing it locks everyone out when the IdP is down. A common answer is an emergency entry point that only the customer’s administrators can use
Points teams often miss
- An IdP compromise has a wide blast radius. A hijacked IdP account opens every connected system. Protect IdP logins with passkeys or multi-factor authentication
- Session length. If SP sessions last a long time, people can keep working for a while after the IdP disables them
- Certificate renewal. SAML signing certificates expire. When one does, every user at that customer is locked out. Send expiry reminders and accept old and new certificates side by side during the switch
- Support. Keep a record of when each IdP sent what, so you can tell whether a “can’t log in” problem lies with the IdP or with your service
SSO and passkeys together
SSO decides where people log in; how their identity is confirmed is left to the IdP or to each service’s own login. For regular members who do not use SSO, or customers on plans without it, passkeys can replace passwords. The mechanism is explained in “What passkeys are.”
About SealGate
Our SealGate is a passkey authentication platform made in Japan. It adds fingerprint and face login while you keep your current login screen and user data. The only data it stores is the mapping between public keys and your user IDs. Pricing is on the SealGate website.
References
- OASIS: Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0
- OpenID Connect Core 1.0
- OpenID Foundation: How OpenID Connect Works
- RFC 7644: System for Cross-domain Identity Management (SCIM) Protocol
FAQ
Does SSO remove the need for passwords?
The systems behind SSO no longer hold passwords, but users still log in to the IdP first, such as Microsoft Entra ID or Google Workspace. Strengthening the IdP login with passkeys or multi-factor authentication protects everything at once. The flip side is that a compromised IdP account opens every connected system.
Should we support SAML or OpenID Connect?
Most identity providers used by corporate IT teams support both. If you are building from scratch, a common approach is to start with OpenID Connect, which is easier to use across web and mobile apps, and add SAML when customers ask for it.
If we add SSO, are leavers' accounts disabled automatically?
SSO alone leaves existing sessions and accounts created in your SaaS in place. To make access stop as soon as the IdP disables someone, sync account creation and deactivation with SCIM or similar, and keep session lifetimes short.
