chore(deps): upgrade authkestra 0.5.1 -> 0.5.4

[stephane-segning]

Summary

Bumps all four pinned authkestra-* crates (authkestra-op, authkestra-engine, authkestra-axum, authkestra-resource) in Cargo.toml from =0.5.1 to =0.5.4 in lockstep, per the pinning discipline the root Cargo.toml's own comment documents ("pre-1.0, fast-moving... the whole family must move in lockstep"). authkestra-devsig is not a vpay dependency — grepped and confirmed absent from both Cargo.toml and Cargo.lock. The default-features = false, features = ["rustls-no-provider"] configuration and its surrounding rationale comments (single-ring-CryptoProvider constraint) are unchanged.

Source of truth: https://github.com/marcjazz/authkestra/releases/tag/authkestra-v0.5.4 (10-commit range authkestra-v0.5.1..authkestra-v0.5.4, read directly from the cloned authkestra source at /Users/selast/dev/authkestra, not from a changelog).

Scope

Read all 10 commits in range and diffed the actual API surface vpay touches (authkestra_op::{client_assertion, sqlx_store, store}, authkestra_engine::client_assertion, authkestra_resource::jwt::{JwksCache, ValidationError, validate_jwt_generic, Jwk}) rather than trusting commit prose:

• 8644cb5 fix(op): validate requested audience against allowed_audiences in client_credentials (#230) — before this fix, handle_client_credentials always stamped aud = client_id, ignoring req.audience/client.allowed_audiences entirely (no audience-scoping enforcement at all, not "requests to any audience accepted" — either way vpay's exposure question is the same). vpay is not exposed: grepped the whole workspace for handle_client_credentials — zero call sites. vpay's authkestra-op usage today is a persistence-layer spike only (vpay-db implements ClientAssertionStore/SqlxOpStore plumbing for a future OP; backends/tests/integration/tests/authkestra_op_smoke.rs exercises SqlxOpStore/AuthorizationCodeStore/ClientStore at the storage layer). No OP router is mounted, no client_credentials grant is ever handled by vpay's own running code, and authkestra-axum — the crate that would mount OP routes onto a Router — isn't even a real dependency edge (declared in [workspace.dependencies], absent from Cargo.lock both before and after this bump; nothing depends on it).
• 884d4a9 fix(oidc): derive ID-token Validation from discovery instead of Validation::default() (#228) — touches only crates/authkestra-oidc/src/provider.rs, a crate vpay does not depend on (not in the four pinned crates). Separately, vpay's own resource-token validation (backends/crates/vpay-api/src/resource_auth.rs) does not use authkestra's ID-token validation at all — it hand-builds jsonwebtoken::Validation::new(Algorithm::RS256) and calls .set_audience(&[surface.audience()]) explicitly (see the file's own doc comment explaining why authkestra_resource::jwt::JwtStrategy was deliberately not used: its Validation is opaque once built via ValidationConfigBuilder). vpay was never exposed to either the authkestra-oidc default-permissive validation or its fix, because it never called into that code path.

Also in range, all non-breaking for vpay's usage:

• b206bc3 private_key_jwt client auth for ClientCredentialsFlow (#229) — touches authkestra-op/src/client_assertion.rs, but only converts CLIENT_ASSERTION_TYPE_JWT_BEARER/MAX_CLIENT_ASSERTION_LIFETIME_SECS from pub const to pub use re-exports of the identically-typed constants in authkestra-engine — source compatible, vpay-db/src/client_assertion.rs's ClientAssertionStore impl is untouched.
• 4daeb25 revocation_endpoint added to OidcDiscovery (#226) — additive field on authkestra-op/src/handlers/discovery.rs; vpay does not construct or read OidcDiscovery.
• 571b904 E2E adapter tests (#232), 96a00e6 cargo-deny setup, d896fc7 CI lint/deny drift fix — all internal to authkestra's own CI/tests, no API surface change.
• f2ac3e4 RFC 8705 certificate-bound access tokens for client_credentials (0.5.4, #231) — new authkestra_engine::token::cert_binding module and a new handle_token_with_client_cert, added alongside the existing 5-argument handle_token/handle_client_credentials, which keep their original signatures ("every existing call site keeps compiling untouched", confirmed by diff — no call site in vpay to begin with anyway). authkestra-resource's ValidationConfig gains an opt-in require_cert_binding field (off by default); vpay doesn't construct ValidationConfig so this is a no-op for vpay.

cargo diff --stat of the store/discovery/jwt-generic surface confirms authkestra-op/src/{store,sqlx_store,lib}.rs and authkestra-resource/src/jwt.rs's validate_jwt_generic/JwksCache function signatures are untouched in this range — only authkestra-resource/src/jwt.rs grew (opt-in ValidationConfig/JwtStrategy additions vpay doesn't use) and authkestra-engine gained the new cert_binding module.

Net: this bump is mechanical for vpay. No code changes required beyond the four version pins.

Verification

Baseline established first on a clean origin/master (16c3663) before making any change — cargo build --workspace, cargo fmt --all -- --check, and cargo clippy --workspace --all-targets -- -D warnings all passed clean, and cargo nextest run --workspace passed 139/139 (3 skipped). No pre-existing failures to distinguish from.

With the bump applied:

• cargo build --workspace — clean, Finished dev profile [unoptimized + debuginfo] target(s) in 5.96s.
• cargo fmt --all -- --check — clean, zero diff.
• cargo clippy --workspace --all-targets -- -D warnings — clean, zero warnings.
• cargo nextest run --workspace (matches CI's rust job) — Summary [ 25.729s] 139 tests run: 139 passed, 3 skipped, identical pass count to baseline. Includes the Postgres-backed suites CI cares about: vpay-tests-integration::authkestra_op_smoke::sqlx_op_store_round_trips_a_client_and_enforces_single_use_codes and all 14 vpay-tests-integration::postgres_smoke::* tests, run against real postgres:16-alpine testcontainers per .config/nextest.toml's serialized postgres-containers group (Docker was available locally; ran for real, not skipped).
• cargo deny check — advisories FAILED (RUSTSEC-2026-0258, h2 v0.4.15, low severity, unbounded empty DATA frames, pulled in via testcontainers → bollard → tonic/hyper, a dev-only dependency chain). Pre-existing on origin/master before this PR — confirmed by running the identical cargo deny check advisories on a stash of this change (i.e. against unmodified master), which fails identically. git diff Cargo.lock confirms h2 is untouched by this bump (only the three authkestra-* entries change version/checksum, plus authkestra-resource gains a tracing dependency edge per upstream commit f2ac3e4). Not fixed here — out of scope for an authkestra version bump, and unrelated to either flagged security fix; bans, licenses, and sources all report ok.

Risk Assessment

Low. Exact-pin dependency bump within a pre-1.0 crate family vpay does not yet wire into any running code path (dependency spike per docs/adr/0009-dashboard-oidc-provider.md) — no OP router mounted, no client_credentials handler called, ID-token validation is vpay's own hand-rolled jsonwebtoken::Validation, not authkestra's. Full local test suite (including real-Postgres integration tests) passes identically to baseline.

AI Usage Declaration

• AI assisted: dependency version bump, commit-range analysis of the upstream authkestra source (cloned locally), impact assessment against vpay's actual call sites (not just changelog prose), and this PR description.
• Human accountability:
  • I reviewed every line of the diff (2 files: Cargo.toml, Cargo.lock).
  • I independently verified the security-fix impact claims against vpay's own source (resource_auth.rs, client_assertion.rs, the integration test files) rather than trusting the commit messages alone.
  • I ran the full validation suite listed above myself and pasted real output, not assumed-passing placeholders.
  • I am accountable for this change and can explain every line.

Reviewer Focus

• Confirm the "vpay never calls handle_client_credentials / never validates ID tokens via authkestra-oidc" exposure conclusion independently if you want a second read — the grep commands are reproducible: grep -rn "handle_client_credentials\|authkestra_oidc" backends/.
• cargo deny's h2/RUSTSEC-2026-0258 failure is real but pre-existing and out of scope here; flagging in case it isn't already tracked separately.

🤖 Generated with Claude Code