Change tenant settings, watch the metadata follow, and guard your refreshes

Setup

1. You need lab-collage with its lab-collage ID token manager on key B, ES256 key D from the key rotation lab, ISSUER2, ID_ALGS and rp_discover from the provider discovery lab.

2. Save a baseline copy of the Lab Photos document:

curl -s "$ISSUER/.well-known/openid-configuration" | jq -S . > meta-0.json

3. In Lab Photos, press Start.

Walkthrough

1. Endpoints and keys. Fill in the lesson's endpoint table from meta-0.json: issuer, authorization_endpoint, token_endpoint, jwks_uri, userinfo_endpoint and end_session_endpoint. The last one is absent, because this provider offers no RP-initiated logout. Every address uses HTTPS, and you use each one exactly as written, never assembled from the issuer.

2. Advertised capabilities. Read the lists:

jq '{scopes_supported, response_types_supported, subject_types_supported, id_token_signing_alg_values_supported, claims_supported, claims_parameter_supported, code_challenge_methods_supported, authorization_response_iss_parameter_supported}' meta-0.json

On a new tenant: scopes_supported includes openid, profile, email and the lab scopes; response_types_supported is ["code"]; subject_types_supported is ["public"]; claims_parameter_supported is false; code_challenge_methods_supported is ["S256"]; and every response carries iss. Also note the provider-specific btl_service_status and btl_endpoint_status, which mark which catalogued endpoints exist.

Why it matters: these lists describe what the provider can do for clients that ask. None of them describes your client.

3. Change a flow. In Flow policy, allow the implicit grant, the response type id_token and the fragment response mode. Fetch the document again as meta-1.json and compare:

curl -s "$ISSUER/.well-known/openid-configuration" | jq -S . > meta-1.json; diff meta-0.json meta-1.json

New values appear in response_types_supported, grant_types_supported and response_modes_supported.

Restore: set the Flow policy back to the authorization code grant with the code response type and the query and form_post modes, and confirm that a fresh copy matches meta-0.json again.

4. Change the claims. On the lab-collage ID token manager, add a mapping named lab_note with the text value hello, for both destinations. Fetch the document: claims_supported now lists lab_note. Delete the mapping.

5. Change the algorithms. Point the lab-collage ID token manager at ES256 key D. Fetch the document: id_token_signing_alg_values_supported is now ["ES256","RS256"]. Your ID_ALGS is still RS256, so an ES256 ID token is still refused by your verifier.

Restore: point the lab-collage ID token manager back to key B.

Why it matters: the document never widens what your relying party accepts. Its registration and its own allowlist do.

6. Publish informational fields. In Metadata Management, add op_policy_uri (an HTTPS address you own) and x_lab_contact (any text), and save. Both appear in the document. Then try to add claims_parameter_supported with the value true. The tenant refuses it: advertising a capability the server lacks would mislead every client that reads the document.

7. Write a refresh guard. It compares a new copy with the last good one and holds anything that would change where you send people or whose keys you trust:

guard() { local old=$1 new=$2
  for f in issuer jwks_uri token_endpoint authorization_endpoint; do
    [ "$(jq -r .$f "$old")" = "$(jq -r .$f "$new")" ] || echo "HOLD: $f changed, needs a person"; done
  jq -e '.code_challenge_methods_supported | index("S256")' "$new" >/dev/null || echo "HOLD: S256 no longer listed, keep sending PKCE"
  jq -e '.authorization_response_iss_parameter_supported == true' "$new" >/dev/null || echo "HOLD: iss promise withdrawn, keep requiring it"; }
curl -s "$ISSUER/.well-known/openid-configuration" | jq -S . > meta-2.json; guard meta-0.json meta-2.json

It prints nothing: the informational fields changed, and nothing that matters to your relying party did.

Why it matters: a missing entry never switches off a protection you rely on, and a refreshed copy is compared with the last one, not simply absorbed.

Break it

1. Move the key set. In Metadata Management, rename the JWKS path to /oauth/keys-v2. Fetch a new copy and run the guard: HOLD: jwks_uri changed. Your relying party keeps its last good configuration until someone decides.

Restore: set the JWKS path back to /oauth/jwks.

2. A copy that names another issuer. Feed the guard the Lab Mail document as if it were a refresh:

curl -s "$ISSUER2/.well-known/openid-configuration" | jq -S . > meta-mail.json; guard meta-0.json meta-mail.json

Every entry is held, starting with issuer. A document that names another issuer is not a change to adopt: it fails discovery and is discarded whole.

Check your work

Press Check my progress in Lab Photos. It looks for, in order: the Flow policy change and its restore, a lab-collage ID token manager update, the informational fields published, and the JWKS path moved and moved back.

Audit also records the refused claims_parameter_supported field as a rejected tenant.oauth.metadata.update, unless the portal stopped it before sending. Your diff output shows each runtime change reflected in the document.

Cleanup

1. Confirm that the Flow policy matches meta-0.json, the JWKS path is /oauth/jwks, and the lab-collage ID token manager uses key B without lab_note.

2. Keep or remove the informational fields. Delete meta-*.json.

Missing infrastructure

• G66 Second lab tenant: this lab uses Lab Mail, a second tenant. Additional tenants currently need a paid subscription or a BTL grant, so an ordinary learner can do only the Lab Photos steps until every learner can have a second lab tenant.