Authentication policy and SSO
Choosing the evidence
At Cedar Inc., Avery may use a password, an authenticator app, or a passkey. Reading a staff announcement might need an ordinary sign-in, while exporting payroll might require a recent passkey sign-in. An authentication policy sets the evidence required for each situation.
Offering a method does not mean accepting it everywhere. Cedar Inc. might accept an authenticator-app code for reading the staff directory while requiring a verified passkey for an administrative action. The policy must also account for how people enroll methods and recover access. If a text message could reset an administrator's passkey, the administrator account would be only as strong as that text message.
Configuring a policy
When Cedar Inc.'s administrators set a policy, they need to decide which methods people can use and when a stronger or more recent check is required. Each choice affects people who already have accounts, not only new employees.
| Choice | Example consequence |
|---|---|
| Allowed methods | Can employees enroll synced passkeys, security keys, authenticator apps, or other supported methods? |
| Required evidence | Does an action require any accepted method, MFA, or phishing-resistant MFA? |
| Scope | Which users, applications, roles, or actions does a rule cover? |
| Freshness and sessions | How recent must authentication be, and when must a session be renewed or ended? |
| Enrollment and recovery | How do people add replacements and recover access without bypassing the intended assurance? |
Suppose Cedar Inc. requires security keys for payroll but has not given payroll staff a way to enroll them. The new rule would block their work. Administrators need to see who a change affects, arrange enrollment or backup methods, and introduce the rule in a controlled order. If rules overlap, the service needs a defined way to decide which one applies.
Fresh and stronger authentication
Avery signed in with a passkey yesterday, but payroll export requires a check performed in the last few minutes. Cedar Inc. asks Avery to sign in again. This is reauthentication. If Avery signed in just now with a password but payroll requires a passkey, the service asks for stronger evidence. This is step-up authentication.
A request can need both: a fresh check with a stronger method. Issuing a new token from an existing session does not establish that Avery just authenticated, so the application needs trustworthy information about when and how the check occurred.
A policy can also respond to signals such as an unfamiliar device, an unusual location, or a sudden change of browser by asking for more evidence. This is often called risk-based or adaptive authentication. Those signals may shape the decision, but none of them proves something Avery knows, has, or is, so they never replace a factor the policy requires.
Carrying trust to an application
Cedar Inc. uses an identity provider to sign employees in to several applications. With single sign-on (SSO), Avery can open a connected application without entering credentials there again. The identity provider may use Avery's existing session, or it may ask for a new check when the application's policy requires one.
OpenID Connect and SAML can carry an authentication result from the identity provider to an application. Before creating its own session, the application validates that the result came from the expected provider, is meant for this application, is still valid, and belongs to the request it made.
In OpenID Connect, auth_time can tell the application when Avery authenticated. acr and amr can describe the authentication context and methods, if Cedar Inc. and the application have agreed on their meaning. Some values have shared definitions: RFC 8176 lists common amr values, such as pwd for a password and hwk for a hardware-protected key, and an acr value may name an assurance level from a published framework such as NIST SP 800-63. A token's issue time is not necessarily the time Avery signed in, and an absent method claim cannot be taken as proof of MFA.
{
"auth_time": 1790553600,
"acr": "urn:cedar:example:phishing-resistant-mfa",
"amr": ["example-provider-method"]
}This fragment is illustrative, not a signed token. The context and method values are placeholders; the application needs a documented agreement with Cedar Inc. about what they mean. The OpenID Connect lessons, starting with From delegated access to sign-in, follow the requests, claims, and validation in detail, and Authentication context and methods returns to acr and amr.
After sign-in, each application can hold its own session. Ending Avery's identity-provider session does not automatically close every application session.
Following a sensitive action
Avery opens payroll through SSO and requests an export. The payroll application checks whether Avery currently has permission to export. It also checks whether the trusted sign-in result meets its requirements for method and recency.
If stronger or fresher evidence is needed, the application sends Avery back to the identity provider for another check. When Avery returns, the application validates the new result and checks its policy again. The payroll API enforces those conditions even if a request bypasses the visible export button.
If Avery cancels, the identity provider cannot perform the required check, or the result omits required evidence, the export remains blocked. A successful passkey check also cannot grant export permission if Avery's role has changed in the meantime.
The SSO in this lesson rests on decades of earlier designs. History of SSO follows how a sign-in at one service came to be trusted by others, from shared computers and Kerberos to SAML, OpenID Connect, and passkeys.