Quick answer: Single sign-on (SSO) lets a user log in once with an identity provider and reach multiple applications without separate passwords for each. Common patterns use SAML 2.0 or OAuth 2.0 / OpenID Connect. For business apps, SSO reduces password fatigue, centralises access revocation and improves security when paired with strong identity policies. Integration work maps your app as a service provider (or relying party), trusts the identity provider, and handles attributes, sessions and failures cleanly.
Why companies ask for SSO
Typical drivers:
- Employees already use Google Workspace, Microsoft Azure AD, Okta or similar
- Customers on enterprise plans demand login through their IdP
- Security teams want one place to disable access when staff leave
- Support wants fewer “reset password” tickets across product suites
SSO is an integration project with UX and security consequences, not a checkbox plugin you flip without design.
Core ideas in plain language
- Identity provider (IdP): the system that authenticates the user (and often stores the directory)
- Service provider (SP) / relying party: your application that trusts the IdP
- Assertion / token: the signed proof that the user authenticated
- Attributes / claims: data about the user (email, name, groups, roles)
- Session: how your app remembers the user after the handshake
Your app still needs authorisation logic. SSO answers “who is this?” more than “what may they do?” Group claims help, but you map them to permissions inside the product.
SAML 2.0 (still very common in enterprise)
SAML is widely used for workforce SSO into SaaS tools.
Rough SP-initiated flow:
- User hits a protected URL in your app
- App redirects to the IdP with a SAML authentication request
- User signs in at the IdP (password, MFA, etc.)
- IdP POSTs a SAML response with an assertion to your ACS URL
- App validates the signature and conditions, then creates a local session
IdP-initiated flows also exist (user starts from an IdP portal). You should decide which you support and test both if customers need them.
Metadata exchange (Entity IDs, certificates, endpoints) is how both sides configure trust. Certificate rotation needs a calendar reminder or you will see sudden login outages.
OAuth 2.0 and OpenID Connect
Many modern product integrations use OpenID Connect (OIDC) on top of OAuth 2.0 for login, especially customer-facing and mobile-friendly apps.
Rough authorisation code flow:
- App redirects to the IdP authorise endpoint
- User authenticates and consents if required
- App receives an authorisation code
- App exchanges the code at the token endpoint for tokens
- ID token identifies the user; access tokens call APIs as scoped
This family of protocols also powers “Sign in with” social buttons, which are related but not identical to enterprise SSO procurement. Choose protocols based on what the customer’s IdP supports and what your stack has mature libraries for.
What integration work actually includes
Discovery:
- Which IdPs must you support in year one?
- Workforce only, customers only, or both?
- Just-in-time user provisioning or pre-provisioned accounts?
- Which claims map to roles?
Build:
- ACS / callback URLs for each environment
- Certificate and client secret storage
- Attribute mapping and fallbacks when claims are missing
- Logout behaviour (local only vs IdP single logout if supported)
- Clock skew tolerance and detailed error logs
Operate:
- Staging IdP apps for testing
- Runbooks for cert expiry
- Support playbooks when “SSO broke for one customer”
Treat SSO endpoints like any other sensitive API integration: validate inputs, log failures without leaking tokens, and rate-limit abuse. Broader API security habits apply.
Security caveats
SSO improves security when the IdP is strong. It concentrates risk if the IdP is weak. Require MFA at the IdP for staff. Use least-privilege roles inside your app even when the IdP asserts groups.
Watch for:
- Accepting unsigned or weakly validated assertions
- Account linking bugs (attacker attaches their IdP identity to a victim email)
- Open redirects on relay state / return URLs
- Verbose errors that help attackers enumerate users
Pair SSO with good session controls and, where useful, two-factor authentication patterns on apps that still offer local login during migration.
UX details people forget
- Clear “Sign in with company SSO” versus local login paths
- Help text for first-time users who are not yet provisioned
- Error pages that tell admins which claim was missing
- Mobile browser behaviour for redirects
- What happens when a user hits a bookmarked deep link while logged out (redirect back after SSO)
For customer-facing portals, test the path on the same phones your users carry. Redirect chains that work on a developer laptop can fail in embedded webviews.
SSO versus password managers versus shared logins
Password managers help individuals. Shared generic logins are a different problem and a bad idea. SSO is the organisational answer when many staff need application access under audit. For smaller tools without SSO, prefer individual accounts and a joiner/mover/leaver process over a shared password in a chat channel.
Planning checklist for a first SSO project
- Confirm protocol (SAML, OIDC) with two design-partner customers
- Document mandatory claims (email, stable user id, groups)
- Implement on staging with a developer IdP tenant
- Add admin UI to upload metadata or enter client settings per tenant if you are multi-tenant
- Pilot with one friendly customer
- Monitor failure rates and time-to-login
- Only then announce general availability
If your wider systems mix includes accounting or CRM automation, keep identity separate from those integrations unless there is a clear reason to couple them.
Local login during transition
Most products keep a local login path while SSO rolls out. Policies to decide:
- Who may still use passwords?
- Are local accounts blocked once SSO is linked?
- How do break-glass admin accounts work if the IdP is down?
Document break-glass carefully. Store those credentials in a company vault with dual control, not in a personal password manager alone. Test restoration after IdP outages so you are not inventing a process during an incident.
Vendor questionnaires
Enterprise buyers will ask about SSO in security reviews. Be ready to state protocols supported, MFA reliance on the IdP, session lifetime, logging and how access is revoked. Honest answers close deals faster than promising protocols you have not built.
FAQ
Is SSO only for large enterprises?
No. Many mid-sized firms use Google or Microsoft identity today. Product companies add SSO when B2B buyers ask for it.
Does SSO replace my user table?
Usually you still store user records for roles, preferences and audit. SSO changes how authentication happens.
Can I support several IdPs?
Yes. Multi-tenant SaaS often does. Budget for configuration UX and testing matrix time.
What is SCIM?
SCIM is a provisioning standard for creating and deactivating users from the IdP into apps. It complements SSO and is a separate project.
Login once, revoke once
Single sign-on integration connects your app to an identity provider through SAML or OIDC, maps claims to permissions and hardens the redirect handshake. Plan protocol, attributes, UX and operations before you promise a go-live date. If you need SSO or other custom integrations built carefully, see our custom development services.
