What is Single Sign-On?

SSO works by centralizing authentication with an identity provider (IdP) such as Okta, Azure AD, or Google Workspace. When a user attempts to access an application (the service provider), the application redirects them to the IdP. If the user has already authenticated with the IdP, a token or assertion is sent back to the application confirming their identity, and they are granted access without entering a password. Protocols like SAML 2.0, OpenID Connect, and OAuth 2.0 standardize this exchange.

From a security perspective, SSO is a double-edged sword. On the positive side, it reduces password fatigue and the number of credentials users must manage, lowering the likelihood of password reuse across services. It centralizes authentication policy enforcement — MFA, password complexity, and session management are configured once at the IdP. And it simplifies deprovisioning: disabling a user at the IdP immediately revokes access to all connected applications.

The risk of SSO is concentration: if the IdP is compromised, the attacker gains access to everything. This makes the IdP a critical asset that requires the strongest protections — hardware MFA for administrators, robust monitoring, and rigorous incident response. Session token theft is another concern, as a stolen SSO session cookie can grant access to multiple services simultaneously.

How Vaulted uses Single Sign-On

Vaulted intentionally operates without user accounts or SSO integration. This is a deliberate design choice for a zero-knowledge secret sharing tool: no accounts means no credential database to breach, no session tokens to steal, and no identity provider dependency. Anyone with the link can access the encrypted secret, and access is controlled through the link itself, optional passphrase protection, view limits, and expiration — not through identity-based authentication.