IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Federation trust — metadata, keys & discovery
Maya's app has never talked to her company's IdP before. Yet it knows where to send her, and which key checks the token that comes back. Your goal: explain discovery, published keys and the one string you must never get wrong.
- An IdP publishes a discovery document at a fixed, well-known address.
- It lists endpoints, the issuer and the address of its public keys.
- The kid in a token's header picks the right key from the key set.
- Rotate keys by publishing first, signing next and retiring last.
- The issuer string must match exactly, character for character.
The business card: OIDC discovery
An identity provider (IdP) publishes a "business card" at a fixed address. The app fetches GET https://issuer/.well-known/openid-configuration. It gets a small JSON file, the discovery document. It answers the app's questions:
- Where do I send the user to log in?
authorization_endpoint - Where do I trade a code for tokens?
token_endpoint - Where are the public keys?
jwks_uri - Who is this issuer, officially?
issuer
The folder name /.well-known/ is a well-known URL. Point an app at one URL, and it sets up the rest by itself.
the direction board at a railway station. It is always at the station and always laid out the same way. You need no guide. You read the board and go.
The keys: JWKS and the kid
Tokens are signed so nobody can forge them (see claims you can trust). To check a signature, you need the IdP's public key. The IdP publishes its keys at its JWKS address (JSON Web Key Set), named by jwks_uri. An IdP usually publishes several keys. Which one signed this token? Each key has a label, a kid (key ID). The token's header has the matching kid. The app finds the key with the same kid and checks with that one.
Rotating keys
Keys should not live forever. Retiring them on a schedule is key rotation. If the IdP just swapped its key, every old token would fail. So rotation takes three calm moves:
1 · Publish first
The new key appears in the JWKS beside the old one, each with its own kid. The IdP still signs with the old key.
2 · Then start signing
The IdP signs new tokens with the new key. Old tokens still check against the old key. Nothing breaks.
3 · Retire last
When every token signed by the old key has expired, the IdP drops it. At no moment is a live token missing its key.
The issuer string
All this trust hangs on the issuer string matching exactly. It is https, not http. It has the right host. It has no extra trailing slash. The app compares the token's iss claim with the issuer it was set up with. The issuer inside the discovery document must also be identical to the issuer used to build the address.
Why so strict? An attacker can host https://idp.example.evil-cdn.com and serve a document that claims to be https://idp.example. Match the string exactly, and the impostor is stopped.
Never "helpfully" tidy the issuer. Do not change its case. Do not drop a slash. Do not follow a surprise redirect to a new host and keep trusting it. The issuer string is a security wall, not a display label.
Go deeper: SAML metadata and OpenID Federation
SAML says the same in XML. The older standard SAML uses the same idea. It publishes a metadata XML file. It holds the same endpoints, an entity ID (SAML's issuer) and the public signing certificates. Two systems swap metadata once. Then each can check the other's signatures.
Swapping metadata by hand works for two parties. It does not scale to thousands, such as all the universities in a country. OpenID Federation 1.0 (final in February 2026) adds a chain of signed statements. Each party signs a statement about the next. A trust anchor sits at the top, and a party trusts anyone whose chain leads back to it. OAuth servers have a similar discovery file for non-OIDC use, defined in RFC 8414.
Now play it. The lab shows an app setting itself up from one address. Then it breaks the setup three ways: a look-alike document, a key that is not published yet and an extra slash. After that, you read documents and rotate a key.
🧪 Interactive lab — enable JavaScript to play with this one.
Map and grade a real domain's discovery surface with Well-Known Scan. Then check the signing keys behind it with JWKS Check.