Authentication policy and SSO
Choosing the evidence
At Cedar Inc., Alex 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 allow text messages for a limited recovery route while requiring a verified passkey for an administrative action. The policy must account for how people enroll methods, sign in, and recover access.
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
Alex signed in with a passkey yesterday, but payroll export requires a check performed in the last few minutes. Cedar Inc. asks Alex to sign in again. This is reauthentication. If Alex 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 Alex just authenticated, so the application needs trustworthy information about when and how the check occurred.
Conditional access can also respond to signals such as an unfamiliar device or location by asking for more evidence. Those signals may shape the decision, but they do not 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), Alex can open a connected application without entering credentials there again. The identity provider may use Alex'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 Alex authenticated. acr and amr can describe the authentication context and methods, if Cedar Inc. and the application have agreed on their meaning. A token's issue time is not necessarily the time Alex 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 will follow the requests, claims, and validation in detail.
After sign-in, each application can hold its own session. Ending Alex's identity-provider session does not automatically close every application session.
Following a sensitive action
Alex opens payroll through SSO and requests an export. The payroll application checks whether Alex 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 Alex back to the identity provider for another check. When Alex 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 Alex 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 Alex's role has changed in the meantime.