Lion Cipher Lab
Stop apps from tracking users across each other with OIDC pairwise subject identifiers
- Identity & Access Management
- Advanced
- ~90 min
- Free · no account required
Why it matters
When you click 'Sign in with ...' on a website, the identity provider sends that site a signed note about you, and one line of that note, the `sub` (subject) claim, is the permanent ID the site files you under. If the provider gives every site the SAME `sub`, then any two sites that share or leak their user tables can stitch your accounts together with a one-line database join, no matter how careful you were to use them separately. OpenID Connect has a built-in fix called pairwise subject identifiers: each site, or each group of sites run by one company, gets its own unrelated `sub` for you.…
What you'll learn
- explaining what the OIDC `sub` claim is and why a single value shared by every app is a ready-made tracking key
- implementing public and pairwise subject identifiers in an OpenID Provider, including the sector identifier rules from OIDC Core section 8.1
- validating a sector_identifier_uri at client registration so a stranger cannot claim another company's sector
- measuring re-identification with a join harness instead of guessing: correct links, wrong links, and certain links per column
- applying claim minimisation, and naming exactly which correlation channels pairwise identifiers do NOT close
- treating the pairwise secret like a signing key: what rotation breaks, and what a leak with guessable account ids gives away
Steps in this lab
- The problem in one picture: one sub, every app
- Public vs pairwise, and the three rules a pairwise sub must follow
- Set up: Python and an empty folder
- Build the toy OP: registration, the sub, and the ID token
- Run it: one user, two RPs, public then pairwise (and a flaw in the literal recipe)
- Build a small world: 1,000 users and four RPs
- BEFORE: public sub, full claims. Every shared user is joinable
- AFTER, part 1: pairwise sub. The sub join drops to 0%, and nothing else moves
- AFTER, part 2: minimise the claims. Now measure what is left
- Same-sector RPs share a sub on purpose
- Validate the sector document at registration (and measure what skipping it costs)
- The secret is load-bearing: rotate it, then leak it
- Honest negatives: what pairwise does not stop
- How a pro deploys this