Single sign-on (SSO) enables users to authenticate once and access multiple independent systems or applications. It reduces password fatigue, simplifies user administration, and enables centralized access control. SSO relies on protocols like SAML, OAuth and OpenID Connect and requires an identity provider and governance.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Single sign-on lets a person authenticate once with a central identity provider and then use multiple relying applications.
SSO arose from the need to manage identities and logins centrally across many applications. OpenID Connect adds standardized identity information to OAuth 2.0 authorization flows.
An application trusts an identity provider that performs sign-in and issues a signed result. The application validates issuer, audience, signature, validity, and required claims, then maps them to local permissions. SSO reduces repeated passwords but concentrates outage and compromise impact in the identity provider. Authentication answers who someone is; authorization decides what they may do.
A central service authenticates the person and issues verifiable identity data to the application.
The application accepts only correctly signed results intended for it and carrying valid claims.
SSO establishes identity; the application or an authorization service must derive access rights.
SSO helps make access across multiple applications consistent and secure. Provider outages, session termination, account lifecycle, and fine-grained authorization require explicit design.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.