01
What single sign-on does
Single sign-on lets a user authenticate once and reach many applications. One identity provider owns the authentication, and each connected application accepts a signed statement from it rather than maintaining its own credentials.
The visible benefit is not the important one. What identity teams are buying is a single place to grant access, a single place to withdraw it, and one record of both. Without that, access management becomes an archaeology exercise across a dozen admin panels.
One authentication, many applications
A single ceremony covers movement between connected applications for the rest of the working session. Fewer prompts also means fewer occasions on which a credential can be typed into the wrong window.
One system to grant from and revoke in
Grants and revocations are made in one system and land everywhere, rather than being applied application by application by whoever happens to remember.
Improvements land everywhere at once
Upgrading the authentication method, to a phishing-resistant factor for instance, takes effect across the estate on the day it is switched on instead of across a two-year rollout.
02
How single sign-on works
The first application redirects to the provider and gets a signed answer back. Most providers additionally hold a session of their own, and it is that session, rather than anything in the protocol, that makes the second application's sign-in invisible.
A complete protocol exchange still runs for the second application. What the user does not see is a login screen, because the provider recognizes them and answers at once. Whether a provider maintains such a session, and for how long, is a design decision with real security consequences, and it deserves an explicit question during evaluation.
- The first application sends the person to the provider, where they authenticate.
- A signed token or assertion travels back to that application.
- A second application is opened and redirects to the same provider.
- The provider answers, prompting again or not according to its session model.
- That application validates the answer and opens a local session of its own.
03
What SSO fixes, and what it concentrates
The return shows up in the invisible parts of identity work: the leaver who kept access to one system, the account nobody knew existed, the access review that ran three weeks and ended in a maybe. It also removes the daily friction that produces password reuse in the first place.
The limit deserves equal clarity. Federating applications does not improve the authentication itself. It applies whatever authentication exists to everything, amplifying that method in whichever direction it already points.
Fewer credentials exist to be stolen
People stop inventing, and then reusing, one password per tool, which retires the credential-stuffing exposure that arrives courtesy of an unrelated company's breach.
Offboarding reaches the end of the list
A single deactivation closes access across every connected application, and where SCIM is in place the local records are deactivated too, instead of lying dormant behind a working local password.
Centralize identity records
Authentication events across all applications land in one system, so an access question is answered from a single source rather than reconciled from several with different clocks.
04
SSO for employees, customers and business tenants
The word covers three programs with different constraints, and treating them as one project is a common way to stall. The protocol may be identical while the operational reality is not.
Workforce access is about lifecycle and coverage. Customer access is about conversion and scale. B2B SaaS federation is about accepting whatever a customer's identity team brings, on their timeline rather than yours.
Workforce access
Employees and contractors, provisioned from a source of truth, with the leaver path as the control that actually matters. SAML and SCIM carry most of this work.
Customer access
External users you cannot train and cannot instruct, at a scale where every added step is measured in abandoned sessions. The secure path has to be the fast path or it will not be used.
B2B SaaS federation
Your product accepts each enterprise customer's identity provider, which means supporting SAML and OIDC properly and isolating tenants so one customer's configuration can never affect another's.
05
How SenseCrypt provides single sign-on
SenseCrypt is a passwordless identity provider serving customer identity, workforce access and B2B SaaS federation from one directory. A user signs in with a live face check on their enrolled phone, with newer applications federating over OIDC and long-established enterprise software taking SAML 2.0.
Since one method is applied across everything, that method is the decision being made. Choose a phishing-resistant one and every connected application inherits the protection; choose a phishable one and every connected application inherits the exposure. On the passkey path it is WebAuthn origin binding that refuses a look-alike domain. Phone sign-in also combines a live face check with a key bound to the enrolled device.
One design choice is worth stating plainly, because it differs from what most providers do. SenseCrypt keeps no identity provider side browser session for end-user authentication. Each application's request runs its own face ceremony on the enrolled phone, which takes seconds and removes the single stolen session cookie that would otherwise unlock everything at once. The administration console does keep a browser session, which is a separate surface with separate controls.
No password field in routine sign-in
Nothing is entered during a sign-in, which leaves a counterfeit login page with no shared password to harvest, and each ceremony binds to the enrolled phone rather than to a cookie in a browser.
OIDC and SAML from one directory
OIDC and OAuth 2.0, hardened with PKCE and PAR, serve the newer applications. Long-established enterprise software consumes a signed SAML 2.0 assertion instead. One enrollment and one set of group memberships stand behind both.
The lifecycle travels with the sign-in
Accounts stay in step through SCIM 2.0, and computed roles and permissions ride in the token for each application to act on. What SenseCrypt itself enforces is the default-closed group gate at sign-in.
Tenants share a deployment, not an issuer
Each IdP tenant has its own issuer and retained, encrypted tenant signing keys. OIDC federation uses classical ES256. Applications validate issuer, audience and signature against the correct tenant’s public keys.
06
Frequently asked questions
What is single sign-on?
A method that lets one authentication at an identity provider open many connected applications. Each application trusts a signed statement from the provider rather than running a login of its own.
Is single sign-on secure?
It is exactly as secure as the authentication behind it, applied everywhere. That is the argument for putting a phishing-resistant method at the center: SSO amplifies whichever method you chose, in whichever direction it already points.
Does SenseCrypt keep a session between applications?
Not for end-user authentication. There is no identity provider side browser session, so each application's request runs its own face ceremony on the enrolled phone. The administration console does keep a browser session, which is a different surface with its own controls.
Does SSO work for customers as well as employees?
Yes, though the constraints differ. Workforce SSO is judged on lifecycle coverage and offboarding; customer SSO is judged on conversion and scale. SenseCrypt serves both, along with B2B SaaS federation, from one directory.
What happens when a user leaves the organization?
Deactivating the account at the identity provider stops further authentication everywhere. With SCIM 2.0 the accounts in connected applications are deactivated too, rather than being left dormant with a working local credential.