Course Preview

Single Sign-On

Single sign-on lets one authenticated identity-provider session open multiple connected applications without asking for credentials each time. Each application still validates the sign-in response, creates its own session, and enforces its own permissions.

itIdentity, access, and cryptography | OpenSkills.info

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Single Sign-On

Single sign-on (SSO) is an authentication arrangement in which one successful sign-in can establish access to multiple connected applications. The user authenticates to an identity provider (IdP). Each application, called a relying party (RP) or service provider (SP), trusts a defined response from that IdP and then creates its own local session.

SSO is therefore more than a shared login page. It is a chain of trust and sessions. The IdP session records that the user authenticated centrally. A protocol response carries evidence of that authentication to an application. The application validates the response, maps the external identity to a local account, and starts an application session. Authorization remains local unless another system explicitly supplies policy inputs.

The sign-in path

An SP-initiated flow begins when you open an application without a valid local session. The application redirects your browser to its trusted IdP. The request identifies the application and includes protocol-specific transaction data.

If the IdP has no acceptable session, it authenticates you. Authentication can include a password, passkey, certificate, or multiple factors. If an acceptable IdP session already exists, the IdP can reuse it according to policy. That reuse creates the visible single-sign-on experience.

The IdP returns a signed response through the browser or through a browser-and-back-channel exchange. The application verifies the issuer, signature, audience or client identifier, destination or redirect URI, transaction binding, lifetime, and required claims. A valid response allows the application to create its own session cookie. The browser now holds at least two independent sessions: one at the IdP and one at the application.

An IdP-initiated flow begins from an IdP portal. The IdP sends a response to a selected application without a fresh application request. Some SAML deployments support this path. It has less request context, so the application must apply the profile's unsolicited-response rules and its own policy.

Continue the course

This section is part of the paid course.

See pricing to subscribe, or log in if you already have access.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Security Engineersupporting

Sources