Freshness step-up and remembered browsers as context

Setup

The tenant's own clock and the time of the last sign-in are real context in the token policy. The network, country, device management state and risk scores are not available to it (G48, G22).

1. Complete Permit and forbid rules in a token policy for lab-printer-app and the authorize and redeem helpers. Mia has a password and an authenticator app from the authentication labs.

2. Create lab-tmp-policy again (JWT, default key), assign it to lab-printer-app only, and paste this policy:

// prints.create needs a sign-in within the last 15 minutes; viewing does not.
const now = context.claims.iat;
let scopes = [...context.scopes];
const fresh = typeof context.auth_time === 'number' && now - context.auth_time <= 900;
if (!fresh) scopes = scopes.filter(item => item !== 'prints.create');
return { allow: true, claims: { prints_requires: fresh ? 'met' : 'fresh_sign_in' }, scopes };

3. In Authentication, set remember-device to 7 days.

Walkthrough

1. Sign Mia out, then sign in at $ISSUER/login with her password and the authenticator app, and tick Remember this browser. Run authorize "openid photos.read prints.create" in Mia's window and redeem. Both scopes are granted, and btl-lab decode "$TOKEN" shows "prints_requires": "met".

Why it matters: fresh evidence satisfies the rule. The time comes from the tenant's own clock, never from a value the request carries.

2. Wait 16 minutes, then run the same request. Single sign-on issues a token with photos.read only and "prints_requires": "fresh_sign_in".

Why it matters: the decision says what evidence is missing rather than only no. Viewing is unaffected, as in the lesson's café.

3. Act as the application and ask for more: run authorize "openid photos.read prints.create" "&max_age=0". The tenant asks Mia to sign in again; complete what it asks. prints.create is granted and prints_requires is met.

Why it matters: this is the lesson's step-up. The same request is evaluated again with new evidence, instead of the person meeting an error and finding a workaround.

4. Now the remembered browser. Sign Mia out at $ISSUER/account and sign in again at $ISSUER/login with only her password: the second step is skipped. Run the request from step 1, then btl-lab decode "$ID_TOKEN". amr is ["pwd"], without otp or mfa, and yet prints.create is granted.

Why it matters: the remembered browser is device evidence standing in for the second step, not a fresh factor. The policy saw a fresh auth_time and could not see amr (G48), so an application that needs MFA for prints must check amr itself.

5. In $ISSUER/account/security, choose Forget trusted browsers. Sign out and in again at $ISSUER/login: the second step is asked again, and the next ID token's amr includes mfa.

Why it matters: device trust is revocable context, not a permanent property, and the lesson's laptop reported lost should stop counting at once.

6. Network, country and risk, as a written exercise.

Simulation. the tenant does not expose the request's network, an IP-derived country, device management state or a risk score to policy, so these signals cannot be tried for real here.

Fill in the lesson's three-context table for Mia: at her desk, at a café, and abroad. For each signal, write what it would add and how it could be wrong.

Why it matters: each environment attribute is an observation by something the service has to trust, with its own way of being wrong.

Break it

1. Device trust that lasts too long. Set remember-device to 30 days, sign Mia in from a fresh private window with Remember this browser ticked, and note that whoever holds that browser now skips her second step for a month, while the policy above still sees a fresh auth_time after a password alone.

Restore: set remember-device back to 0 days, and choose Forget trusted browsers for Mia again.

2. A policy cannot invent an assurance level. Add the claim acr: 'mfa' to the object the policy returns and request a token as Mia. The request fails with server_error and a reference_id, and Logs show oauth.token failed with reason policy_unavailable.

Restore: remove the acr claim from the policy and confirm a token is issued again.

Why it matters: acr is reserved, so a script cannot announce an authentication context the tenant never measured. A real context value has to come from the sign-in itself (G20).

Check your work

Press Check my progress. The checks follow the remembered second step, the step-up sign-in, the sign-in without a second step, forgetting the browsers and the refused acr claim.

Also confirm by hand:

• Tokens showed prints_requires as met, then fresh_sign_in, then met again.

Cleanup

• Remember-device is 0 days from the restore step.

• Assign lab-printer-app back to the default access token manager and delete lab-tmp-policy.

Missing infrastructure

• G48, authentication context in the token policy. Adding amr, the second-step method and a trusted classification of the network and country to the policy context would let the rule say "a passkey sign-in within 15 minutes" exactly as the lesson writes it, and step 4 would no longer slip through.

• **G20, acr_values.** The application could ask for a specific stronger method instead of only a fresher one.

• G22, device and risk attributes. A decision point with an information point for device management and risk would evaluate the lesson's three contexts per request.