Identity through the whole lifecycle
Connect login, token verification, phishing-resistant credentials, recovery and authorization to testable boundaries.
- Bind login, token and credential events to the intended user, client and purpose.
- Design recovery and revocation as lifecycle transitions rather than alternate login shortcuts.
- Keep human/workload authority and retained identity data within explicit scope.
- Understand HTTP redirects, cookies and the difference between authentication and authorization.
- Read token claim examples and state transitions; no identity-provider tenant or hardware credential is needed.
Estimated time: about 7.5–9.5 hours across 14 steps, including 5 browser labs and 2 local projects.
By the end: An identity lifecycle map, token/recovery decision tables and three tested lab repairs with explicit revocation and retention limits.
0 of 14 steps complete
Trace the guide’s authorization request, callback, transaction state and token exchange.
Keep: A login-transaction record naming each binding and its source.
Complete when: An authenticated provider response is not accepted for the wrong initiating session, client or return destination.
Open guide : OAuth 2.0 and OpenID Connect login: authorization code with PKCEEvaluate the supplied issuer, audience, purpose, algorithm/key and time cases through rollover.
Keep: A token-validation decision matrix with key-cache/revocation assumptions.
Complete when: A mathematically valid signature does not permit an ID token or adjacent-service token to become an API credential.
Open guide : JWT validation: algorithms, keys, claims and key rolloverRun the token lab’s valid and near-miss credentials, preserving the intended caller’s access.
Keep: A repaired validator and actual case results.
Complete when: Correctly scoped API credentials pass; wrong issuer, recipient, purpose or required lifecycle condition fails under the supplied contract.
Open lab : JWT validation lab: Validate the purpose and audience of a tokenRun the JWT verification lab: accept only the pinned algorithm, verify the signature with the configured key, then check issuer, audience, expiry and not-before.
Keep: A repaired verifier with the lab's passing cases.
Complete when: alg none, a token signed with a key the API never issued and a tampered payload are rejected before any claim is read, and a valid token still passes.
Open lab : JWT verification lab: Verify a JWT before trusting itFollow the guide’s registration, authentication and replacement scenarios and identify who may add or remove a credential.
Keep: A credential lifecycle transition table.
Complete when: The explanation includes recovery/enrollment authority and does not infer whole-account safety from phishing resistance at login alone.
Open guide : Passkeys and MFA: WebAuthn enrollment, sign-in and replacementTrace the supplied recovery or account-linking request, proof, expiry, consumption and session consequences.
Keep: A recovery threat case and one-use state record.
Complete when: An email match or valid recovery token is not treated as unlimited authority; duplicate and changed-account cases have explicit outcomes.
Open guide : Account recovery: password resets, help-desk resets and account linkingRepair the recovery lab and trace duplicate use plus the credential/session update boundary.
Keep: A tested one-use recovery transition and crash-window explanation.
Complete when: The credential is not usable twice, legitimate recovery succeeds once, and any session-invalidation limitation remains explicit.
Open lab : Password reset token lab: Make a recovery credential single-useApply the supplied role/attribute/relationship rules to one resource matrix and identify authoritative state.
Keep: An authorization contract with permitted and denied examples.
Complete when: Model choice is justified by the resource relationships, with current revocation/tenant checks near the action rather than inferred from login.
Open guide : Authorization models: RBAC, ABAC, ReBAC and policy as code you can testTrace issuance, recipient/scope and downstream resource access for the guide’s service identity.
Keep: A workload trust-and-capability map.
Complete when: A short lifetime does not imply narrow permission, and a trusted workload cannot manufacture a user’s business approval.
Open guide : Workload identity federation: short-lived, scoped identities for services and CIMap the guide’s identity-related data through live stores, logs, exports, caches and restore paths.
Keep: A purpose/retention/deletion evidence table.
Complete when: A removed live row is not a complete deletion claim while active derivatives or a restore can reintroduce the record.
Open guide : Data minimization and retention: collect less and prove that deletion worksDownload the token lifecycle project, install with npm ci --ignore-scripts, run npm test, then pin the token contract and check session and revocation state after verification.
Keep: A key rotation timeline and an incident note explaining how a cached signing key is stopped.
Complete when: All 24 tests pass, and revoking a session takes effect for a token that is still cryptographically valid.
Needs: Internet access for npm ci, which downloads the pinned jose package; the tests run on localhost only.
Open project : Verify tokens through rotation and revocationDownload the identity lifecycle project, run python3 -m unittest -v test_lifecycle.py, then repair apply, authorize and dispatch in exercise.py.
Keep: An authority inventory before and after a disable, and a timeline of duplicate and stale events.
Complete when: All 18 tests pass, old tokens stay invalid after re-enable, and the Beta tenant’s user still works after Acme disables its user.
Open project : Prove deprovisioning reaches sessions and queued workRun the OAuth lab: compare redirect URIs as exact strings with only the loopback port exception, and verify an S256 code_verifier against the stored challenge, refusing plain, missing values and downgrades.
Keep: A repaired authorization server check with the lab's passing cases.
Complete when: Prefix, traversal, query, subdomain and port variations of a registered URI are refused, the RFC 7636 example verifies, and codes issued without a challenge cannot be redeemed.
Open lab : OAuth redirect and PKCE lab: Match redirect URIs and verify PKCERun the password-hashing lab: verify with Argon2id at the OWASP minimum, fail closed on a wrong password or bad hash, and rehash below-policy hashes with check_needs_rehash.
Keep: A repaired login check with the lab's passing cases.
Complete when: A correct password authenticates and a weak or Argon2i hash is rehashed to Argon2id at policy strength, while a wrong password or unusable hash is rejected without crashing.
Open lab : Password hashing lab: Verify and upgrade an Argon2 password hash on loginRemove an employee without leaving a usable session
Use the complete synthetic fixture below in a notebook or text file. No live target, paid service or secret is needed. Make your own decision before opening the worked assessment. Then take the implementation option below, a local project in which you repair running code until its tests pass, and keep its test output with your written answers.
A departing employee still has a signed token and a linked identity. Trace authentication and authorization through removal and recovery.
Supplied material
User U17 belongs to tenant north and has passkey P1, backup codes C, and external login subject (issuer=https://id.example.test, sub=ext-17).
Application keys accounts by exact issuer+subject, not email. Display email is shared by an unrelated account at another issuer.
At 09:00 U17 receives access token T with audience invoices-api, tenant north, exp=09:30, signed by K1. At 09:05 U17 is removed from north. The API currently authorizes using only T.tenant until expiration.
At 09:06 recovery request R proves control of the mailbox but presents no existing factor or approved recovery evidence. Support proposes linking it to the unrelated issuer because email matches.
At 09:07 signer publishes K2; K1 remains valid for already issued tokens until their expiry. At 09:08 token T2 has valid K2 signature but audience analytics-api.
At 09:09 background job J created by U17 requests an invoice export; job payload stores only user ID and tenant. Policy requires current membership at execution.
Retention policy: deleted memberships remain in an access-controlled audit record for 90 days; they must not remain active authorization facts.Work through the case
Draw the source of truth for identity, session, membership and background-job authority.
Decide T, R, the proposed link, T2 and J at the indicated times.
Specify removal, token rollover, recovery and audit-retention tests, including a legitimate active user during K1/K2 overlap.
Write an operational runbook that distinguishes session revocation from deleting the audit history.
Decide the fixed cases
These parts of the case have one right answer, taken from the worked assessment. Check them here; the rubric below assesses your written reasoning. The capstone meets the bar when every decision is right and the self-check reaches it.
Decide each request at its time.
Evidence to retain
- Lifecycle event/decision table.
- Issuer-subject account-linking policy.
- Rollover and removal test matrix.
- Audit retention and revocation acceptance criteria.
Assess your work
Score each criterion with the anchor whose evidence your answer shows: 0, 1 or 2 points. Every anchor describes something a reviewer can point to in your work. Aim for at least 7 of 8, with no unresolved critical failure.
Score your answer against the anchors
Choose the anchor that matches your answer for each criterion.
Recorded checks stay in this browser only, so you can compare attempts. This is a self-assessment, not a certification.
Compare with the worked assessment
T’s valid signature and unexpired lifetime do not satisfy the current-membership policy after 09:05. Enforce current authorization facts or an explicitly designed revocation/session-version control at the protected operation. R does not satisfy the stated recovery proof; an equal email at another issuer cannot authorize linking. T2 is rejected for the wrong audience even though K2 is trusted. J is denied when it rechecks membership at execution. Preserve authorized active-user K1 tokens during the documented rollover window unless compromise requires revocation; do not confuse a planned rollover with user removal. Retained audit records are historical evidence and cannot reactivate membership.
Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.
No draft saved on this device yet.
Implementation option: Prove deprovisioning reaches sessions and queued work
Repair exercise.py until the 18 tests pass, so a directory disable reaches current sessions and tokens, group-derived permissions and queued jobs, including after retries and restarts.
Keep: Failing and passing test output, and a note mapping the T, R, T2 and J decisions in your table to the tests that cover the same rule.
Python 3.11+ · standard library · 60–90 min · 18 tests
Other connected projects
- Verify tokens through rotation and revocation — Node.js 22+ · npm
- Secure a real HTTP API — Node.js 22+ · npm
Cryptography without shortcuts
Pick primitives by job, build authenticated records, rotate keys, run TLS, plan post-quantum migration, then study past failures.
Your progress, your browser
Progress is stored on this device. Export it to carry it to another browser, or clear it whenever you want. Importing a file adds its completed items to the progress already here; items this site no longer offers are skipped and counted, and nothing else is removed.