feat(sts)!: fail closed on empty trust fields, check token type, require exp, log successes

[alukach]

Closes #143. Two commits; each compiles and tests on its own.

What I'm changing

Four things in multistore-sts were unreachable for a host serving one hardcoded Role and become reachable the moment Roles are user-authored or a second issuer is trusted — which source-cooperative/source.coop#491 is about to do:

• An empty required_audiences accepted any audience, and an empty subject_conditions skipped the subject check. Both fields default to empty, so a Role that omitted either trusted everything its issuer signed. Both now accept nothing; "any subject" is written "*"; and static-config validation rejects a Role with either list empty, so the omission is reported at load rather than discovered at exchange time.
• No token-type check. A token whose header carries typ must say JWT. Access tokens (at+jwt) and other typed tokens are not identity tokens, whoever signed them.
• Tokens with no exp were accepted. A third-party token with no expiry is an indefinitely replayable credential its issuer never meant to issue. exp is now required — except from issuers listed in the new RoleConfig.allow_missing_exp_from, which exists for a host's own long-lived tokens whose validity it tracks itself (Source Cooperative's API keys, with server-side revocation, are the case the issue's caveat describes). The exemption is an explicit field, not a side effect of configuration.
• Successful exchanges were never logged. They are now, at info, with issuer, subject, role and duration.

And the item the issue marks as worth fixing here: resolve_scopes substituted an empty string for a missing or non-string claim. For a bucket that fails safe; for a prefix, an empty string matches every key, so a missing claim silently granted the whole bucket — the opposite of what the doc comment promised. An unresolvable template is now an error at mint time.

Breaking: a Role must set required_audiences and subject_conditions; RoleConfig gains allow_missing_exp_from, which struct-literal constructors must add; mint_temporary_credentials returns Result. The example server config and the docs are updated. For source-cooperative/data.source.coop, the hardcoded _default Role currently sets subject_conditions: vec![] and must become vec!["*"] on bump.

How I did it

• crates/sts/src/jwks.rs — audience_allowed returns false for an empty accepted set. Claim validation moves out of verify_token into validate_claims(header, claims, issuer, role, now), which takes the clock so every rule is tested without a key pair: typ, issuer, audience, exp (required unless exempt), nbf. verify_token verifies the signature and calls it.
• crates/sts/src/lib.rs — the subject check becomes subject_allowed(subject, &conditions), which is any over the list with no empty-list bypass; the success log; ? on mint.
• crates/sts/src/sts.rs — resolve_template and resolve_scopes return Result; mint_temporary_credentials propagates it. The doc comment now says what actually happens.
• crates/core/src/types.rs — RoleConfig.allow_missing_exp_from, and the field docs say "accepts nothing" where they said "unrestricted".
• crates/static-config/src/lib.rs — validate rejects a Role with empty required_audiences or subject_conditions, alongside the existing no-issuers check; the fixture Role gets both.
• docs/configuration/roles.md, docs/auth/proxy-auth.md, docs/reference/config-example.md, crates/sts/README.md, examples/server/config.toml — the new semantics, the new field, and audiences on every example Role (the integration tests mint for sts.amazonaws.com).

Test plan

• cargo fmt
• cargo test --workspace — all green; new tests: empty accepted set denies; well-formed token passes with and without typ; at+jwt rejected; a Role with no audience accepts nothing; exp required unless the issuer is exempt; expiry honours the 60s skew; empty subject conditions allow no subject; missing/non-string template claim is an error; static-config rejects empty audiences and subjects.
• cargo clippy --all-targets — only the pre-existing 11-argument warning in crates/core/src/auth/tests.rs.
• cargo check and cargo check -p multistore-cf-workers --target wasm32-unknown-unknown.
• make test-integration — not run here (needs docker); the example config's roles now carry the audience the tests mint for.

🤖 Generated with Claude Code

https://claude.ai/code/session_01REZWKgQy2PDETn6j9YpM4z

[claude]

Claude finished @alukach's task in 1m 39s —— View job

---

Review complete

• Gather context (diff, CLAUDE.md, changed files)
• Review correctness/security/best-practice issues in diff
• Apply ponytail-review pass for over-engineering
• Post final review

✅ No blocking issues — safe to merge.

Traced the full flow (assume_role_with_web_identity → jwks::verify_token/validate_claims → subject_allowed → sts::mint_temporary_credentials/resolve_scopes) against origin/main. Notes:

• audience_allowed/subject_allowed/exp-required logic correctly fail closed on empty lists, and static-config::validate catches the empty-list case at load time, matching the PR's stated intent.
• The exp-exemption check in validate_claims (crates/sts/src/jwks.rs:246) compares against the issuer parameter, not an unverified claim — by that point token_issuer == issuer has already been enforced, and issuer itself was already checked against role.trusted_oidc_issuers before signature verification (crates/sts/src/lib.rs:132), so the exemption can't be spoofed via an untrusted issuer string.
• resolve_template's new Result-returning error path is correctly propagated all the way through resolve_scopes → mint_temporary_credentials → the one call site in crates/sts/src/lib.rs:173 (?).
• Confirmed every RoleConfig struct literal (prod code, static-config tests, jwks tests) and every example/integration TOML with a subject_conditions role picked up required_audiences/allow_missing_exp_from — nothing left that would fail the new fail-closed validation or fail to compile.
• Success-path logging is placed after token_key.seal(...) and right before Ok(creds), so it only fires once the exchange has actually succeeded, as described.
• Docs (docs/auth/proxy-auth.md, docs/configuration/roles.md, crates/sts/README.md) and docs/reference/config-example.md accurately reflect the new fail-closed semantics and the new field.

Minor, non-blocking observations:

• crates/sts/src/lib.rs:186 logs the token's subject (the sub claim) at info. This is exactly what the PR describes, but depending on the OIDC provider sub can carry an email or other semi-identifying string — worth confirming that's acceptable for wherever these logs end up.

Simplify (ponytail)

Nothing to flag — no new dependencies, no speculative abstractions; validate_claims/subject_allowed are thin extractions that exist specifically to make each rule unit-testable without a key pair, which is a reasonable tradeoff here, not gratuitous indirection.

---

💰 Estimated review cost: $0.62 · 1m39s · 30 turns

[github-actions]

📖 Docs preview deployed to https://multistore-docs-pr-146.development-seed.workers.dev

• Date: 2026-09-25T06:23:54Z
• Commit: 91b047e

[github-actions]

🚀 Latest commit deployed to https://multistore-proxy-pr-146.development-seed.workers.dev

• Date: 2026-09-25T06:23:54Z
• Commit: 91b047e