test(auth): finish the P1 matrix and pin 11 behaviours the specs never asserted

[camreeves]

Spec-only — no source changes. Closes matrix rows ID-04, RF-10, PK-05, PK-06, OI-04, OI-05, OI-06, OI-09, OI-11, MT-03, IR-04, AU-07.

Every one of these was a row where nobody had ever written down what auth.cr actually does. In eight cases it turned out to differ from what the RFC, the discovery document, or my own reading of the code said. Nothing here is exploitable — several are safer than the spec requires — but each is something an integrator would otherwise discover in production.

I was wrong about three of them before testing, which is the argument for the specs existing.

Enforced and now locked down

ID-04 — SAML assertion Conditions. Every check in crystal-saml is guarded by a skip if not configured clause (validate_audience returns true when sp_entity_id is nil, and so on), so which ones are live depends entirely on what build_saml passes. Now asserted: NotOnOrAfter, NotBefore, Audience (another SP), Destination (another deployment's ACS) — each with a valid-window control, without which a build that refused everything would pass all five. Relevant to UCLA, which is SAML/Shibboleth.

MT-03 / IR-04 — tenant boundaries. One process serves eight authorities. Cross-tenant introspection answers {"active": false} with no scope/client_id/exp and no trace of the foreign user or client in the body.

AU-07 — the deny path. DELETE /auth/authorize is session-gated and bounces to login rather than emitting access_denied. That distinction matters: an unauthenticated deny reaching the client would let anyone fabricate a user's refusal.

OI-06 — userinfo. GET and POST return identical bodies, and sub matches the ID token's sub.

Divergences, pinned rather than fixed

Each is deliberate, with the reason it wasn't fixed here.

Row	What actually happens	Why it's pinned
MT-03	The session cookie is not authority-bound — new_session stores uid/exp/iat and one process-wide secret, so an A-session validates at B	A browser never sends it cross-host, and the token minted from it carries aud = the user's authority, so it's refused at B. The tenant boundary is on the token, not the session — asserted end-to-end. Anyone adding a session-only surface inherits this
RF-10	The scope parameter is ignored on refresh, both directions — oauth.cr never forwards it to Authly.access_token	Errs safe. Making narrowing work means forwarding it, and validate_scope! only checks the client registration, not the granted scope — so forwarding without a subset check would create an escalation. See below
PK-05 / OI-09	plain is accepted although discovery advertises S256 only	Not exploitable across clients (the method is baked into the code at authorize time), but a capability document is a promise
PK-06	An unknown method mints a code that can never be redeemed → 401 unauthorized_client	Fails closed. The cost is diagnosability: that error sends an integrator to their client registration
OI-04	nonce is silently dropped — no authorize param, no field on the code, never emitted	Any RP library that sends one (most do) will reject our ID token. Safe direction; no PlaceOS client sends one
OI-05	A token outliving its user gives 404 {"error":""}, not the unknown subject 401 the code intends — User.find raises, escaping the rescue JWT::Error	RFC 6750 §3.1 wants 401. The fix is a semantic call (is a userless token authenticated?) that needs the guest-scope path considered too
OI-11	Issued tokens carry no kid while the JWKS publishes one	⚠️ Latent blocker on key rotation. Works only because there is exactly one key; the moment the JWKS holds two, kid-less tokens are ambiguous and strict RPs reject them. Fix this before any rotation
ID-04	The declared <saml:Issuer> is never validated (idp_entity_id is never passed), and there is no one-time use — an assertion replays until NotOnOrAfter	Issuer: needs a column + a value for every strat, i.e. a migration. Replay: Ruby behaved the same and Shibboleth issues short windows — the accepted SAML bearer model

The near-miss worth reading

I went looking for a privilege escalation in RF-10 and did not find one, but only by accident. validate_scope! checks a requested scope with Authly.clients.allowed_scopes?, which asks "may this client ever hold this scope" — the client registration — not "was this scope granted to this token". Doorkeeper checked the latter (RefreshTokenRequest#validate_scope against refresh_token.scopes). It is safe today purely because the parameter never reaches the grant.

So: if anyone implements scope narrowing, the subset check has to land in the same commit. The spec says so at the point where someone would make that change.

Verification

• 322 examples, 0 failures, 1 pending (the known AU-11 RFC-SHOULD half).
• crystal tool format --check src spec clean.
• The "does NOT" specs assert current behaviour deliberately and are named so they read as findings, not approvals.

Matrix state

Every P1 row is now closed except three, all blocked outside this repo: ID-13 (needs DEV_SSO_EMAIL/DEV_SSO_PASSWORD — the spec is written and waiting), CFG-03 and CFG-05 (the parked helm/compose changes).

P2 remaining: AU-12, TK-09, AZ-07, SC-09, SC-11, ID-10, ID-12, ID-14, AK-03, AK-05, SEC-06, plus AZ-08/AZ-09 which belong to rest-api and staff-api.

Also outside this diff: SC-06 is now automated in tasks/PPT-2536/config-parity/check.sh, and 17 P1 rows turned out to be already covered despite ❌/◐ marks — ID-03 (SAML signature enforcement) was marked "❌ deferred" while carrying five assertions including defect 1's own regression test. All re-marked with the covering example named.

🤖 Generated with Claude Code