What is single sign-on? SSO, identity providers and MFA
Learn how single sign-on uses a shared identity, how it differs from authorization, and where multifactor authentication fits.
Single sign-on (SSO) is an authentication approach in which one account and its authenticators can be used to access multiple applications without a separate sign-in to each one. A shared sign-in experience is not a guarantee that all applications grant the same permissions or that a session remains valid indefinitely. See the [NIST single sign-on definition](https://csrc.nist.gov/glossary/term/single_sign_on).
## Identity providers and applications
An identity provider (IdP) is the service that authenticates the user and supplies identity information to an application under an agreed trust arrangement. The application, sometimes called a relying party or service provider, uses the information it receives to handle the sign-in. Implementations differ; using SSO does not require publishing a password to every application. [NIST's digital identity guidance](https://pages.nist.gov/800-63-4/sp800-63c.html) describes federation and relying parties.
For example, an employee signs in to an organization-managed identity provider, then opens two approved work applications. The applications trust the provider's sign-in result, while each application still applies its own permissions. The example is illustrative; an actual deployment's configuration determines its behavior.
## Authentication and authorization are different
Authentication is the process of verifying a claimed identity. Authorization is the decision about what an authenticated person or system is permitted to access or do. A successful SSO sign-in alone does not establish permission to every file or administrative function. Apply access controls based on the application's own policies, and review permissions when a role changes or a person leaves.
## How MFA relates to SSO
Multifactor authentication (MFA) requires two or more distinct types of authentication factor, such as something a person knows and something they possess. Two-factor authentication (2FA) uses two factors and is one form of MFA; using two passwords does not provide two different factor types. MFA may be applied at the identity provider or elsewhere in the sign-in flow, depending on configuration. See [NIST's MFA definition](https://csrc.nist.gov/glossary/term/multi_factor_authentication).
SSO can be configured with MFA, but neither term implies the other. Some authentication codes or approval prompts can be stolen or abused by phishing. Where supported, choose a phishing-resistant method and verify sign-in requests through trusted channels. [CISA's phishing-resistant MFA guidance](https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) explains relevant choices.
## Operational checks
Because a shared identity can reach several applications, protect the identity provider and administrative accounts, review application access and sign-in activity, and plan how to recover access if the provider is unavailable. Remove access promptly when it is no longer needed, and test that changes reach each application. An SSO session, application session, or token may have a separate lifetime; follow the relevant provider's documentation rather than assuming one logout clears everything.
This guide describes general concepts, not a claim that Mithril offers every SSO configuration. For suspicious sign-in requests, see [Mithril's phishing guide](https://blog.mithril.fund/what-is-phishing-spear-phishing?lang=en). Sources reviewed on 2026-10-29.