chore(deps): upgrade authkestra 0.3.4 -> 0.5.1

[stephane-segning]

Summary

Bumps all four authkestra-* exact-version pins in Cargo.toml (authkestra-op, authkestra-engine, authkestra-axum, authkestra-resource) from 0.3.4 to 0.5.1 in lockstep, per the pinning discipline the root Cargo.toml's own comment already documents ("pre-1.0, fast-moving; the whole family must move in lockstep").

Source of truth: ADR-0009 (vpay runs Authkestra as its own OP — the reason these crates are pinned at all), cross-checked against upstream's own per-crate changelogs and tagged sources at https://github.com/marcjazz/authkestra (real upstream, not a fork; confirmed isFork: false). 0.5.1 (tagged 2026-08-15) is genuinely the latest release for every one of the four crates as of this PR.

Scope

Read every per-crate CHANGELOG.md across the full 0.3.4..0.5.1 range (not just the two flagged landmarks) and diffed the actual tagged sources against 0.3.4 for the API surface vpay touches (crates/authkestra-op/src/{client_assertion,error,sqlx_store,store}.rs, crates/authkestra-resource/src/jwt.rs, crates/authkestra-engine/src/token/{mod,jwk}.rs), not just the changelog prose:

• PR #191 (OpStore::handle_refresh_token/handle_token_exchange) added two defaulted trait methods mirroring the pre-existing handle_custom_grant seam — confirmed by diffing crates/authkestra-op/src/store.rs between the two tags. vpay does not implement OpStore itself; it uses the crate's own SqlxOpStore (backends/tests/integration/tests/authkestra_op_smoke.rs), and sqlx_store.rs, client_assertion.rs, and error.rs are byte-for-byte identical between 0.3.4 and 0.5.1 (empty git diff). No code change required here.
• PR #190 (Ed25519/EdDSA signing, RFC 8037 OKP JWKS) widened authkestra_engine::token::jwk::Jwk with two new fields (crv, x), re-exported as authkestra_resource::jwt::Jwk. This is what actually broke compilation (cargo clippy --all-targets, not caught by a bare cargo build): resource_auth.rs's test-only RSA Jwk fixture is a struct literal, so it needed crv: None, x: None added — both None for the RSA-only shape vpay builds today. One-line-per-field fix, no behavior change.
• 0.5.0 added an optional redis feature to authkestra-op (a new RedisClientAssertionStore) — not enabled by vpay, no effect.
• authkestra-resource carries no functional changes in this range (its own CHANGELOG.md shows nothing past 0.3.4); authkestra-axum likewise (nothing past 0.3.4 in its changelog, and it isn't even a real dependency edge yet — declared in [workspace.dependencies] but not consumed by any member crate, confirmed absent from Cargo.lock before and after). Both crates' version bump to 0.5.1 is a workspace-version lockstep bump only (release-plz stamps every crate in the workspace with the same version on each release, whether or not that crate's own files changed).

No opportunistic changes: no new authkestra features adopted, no unrelated cleanup.

Verification

• cargo build --workspace — clean.

• cargo clippy --workspace --all-targets -- -D warnings — clean (this is what caught the Jwk literal breakage; cargo build alone did not, since it doesn't compile test targets).

• cargo fmt --all -- --check — clean.

• cargo deny check bans licenses sources — clean (bans ok, licenses ok, sources ok); confirmed aws-lc-rs/aws-lc-sys did not re-enter the graph (cargo tree -i aws-lc-rs / -i aws-lc-sys: no match, both before and after). The advisories check itself could not run in this sandbox (no network access to github.com/RustSec/advisory-db) — the existing RUSTSEC-2023-0071 (rsa, unpatched) ignore entry in deny.toml is unaffected by this bump either way.

• cargo nextest run --workspace: 139 passed (1 pre-existing benign LEAK flag on an unrelated adapter test), 3 skipped — identical counts to the pre-bump baseline. This genuinely includes the Docker/testcontainers-backed suites, not just in-process unit tests: vpay-tests-integration::authkestra_op_smoke::sqlx_op_store_round_trips_a_client_and_enforces_single_use_codes drives the real SqlxOpStore<Postgres> against a live Postgres 16 container (client lookup, JSONB decoding, single-use code enforcement), and vpay-tests-integration::postgres_smoke (13 tests) + vpay-db::postgres/vpay-db::repositories (6 tests, including client-assertion replay and signing-key rotation) all ran against real containers too — visible container-startup latency in the run, not a mocked-out skip.

• Auth path coverage, named honestly: vpay-api::resource_auth (11 tests) exercises real RSA sign/verify round-trips through authkestra_resource::jwt::{JwksCache, validate_jwt_generic} — valid/expired/wrong-key/wrong-audience/missing-aud/unknown-kid tokens, both Surface::Merchant and Surface::Dashboard. authkestra_op_smoke exercises SqlxOpStore's find_client/store_code/consume_code. What is genuinely NOT covered: neither OpStore::handle_refresh_token nor token issuance/refresh over HTTP, because no shipping binary mounts /dash/v1 or /v1 yet (docs/status.md's own 🟡 rows say so) — there is no live OP token endpoint in this repo today for either PR #191's new seam or the pre-existing refresh grant to run against. This bump doesn't change that gap; it just confirms it's the same defaulted-behavior codepath either version.

• Live smoke run: real Postgres 16 container + cargo run -p vpay-server against config/application.yml (the repo's realistic example config, including one merchant OAuth client and the dashboard OAuth client — exercising vpay_config::oauth's validated shape). Booted clean:

  configuration loaded and validated deployment=vpay-sandbox livemode=false providers=2 merchant_clients=1 dashboard_client_configured=true
  database connected and migrations applied
  listening addr=127.0.0.1:18080
  

  curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:18080/healthz → 200. Clean shutdown, container removed after.

• cargo build --workspace clean.

• cargo clippy --workspace --all-targets -- -D warnings clean.

• cargo fmt --all -- --check clean.

• cargo deny check bans licenses sources clean; advisories check unavailable offline (documented above, not silently skipped).

• cargo nextest run --workspace: 139 passed / 3 skipped, same as baseline, DB-backed and testcontainers suites confirmed to have genuinely run (not silently skipped).

• Live boot + /healthz 200 against a real Postgres container with the repo's realistic example config.

Risk Assessment

Low. The two changelog-flagged landmarks (PR #190, #191) both turned out to be additive/defaulted for vpay's actual usage — verified by diffing tagged sources, not inferred from changelog prose alone. The one real breakage (Jwk's two new fields) is a test-fixture-only compile error with no runtime behavior implication, fixed by adding two None fields. No behavioral change to token issuance, refresh, or JWKS output was found or introduced — there is no live code path in this repo yet that issues, refreshes, or validates a token against a real OP, so there was nothing to regress there. authkestra-axum is bumped but remains an unused workspace-dependency declaration (not a real edge in Cargo.lock), so it carries zero build/runtime risk either way.

Left out deliberately, not silently: no attempt to adopt the new Ed25519 signing path, RedisClientAssertionStore, or the handle_refresh_token/handle_token_exchange override seams — all out of scope for a version bump per the task brief, and none of them are needed until the OP is actually wired to a route (tracked in docs/status.md, unchanged by this PR). docs/status.md's existing prose narrating the 0.3.4 pin (e.g. "this migration is pinned to authkestra-op = "=0.3.4"... any future version bump requires re-reading sqlx_store.rs's migrate() block") is left as the historical record of that pass rather than edited in place, consistent with how this doc already treats past passes' claims (correcting forward with new dated notes, not rewriting history) — re-reading sqlx_store.rs at 0.5.1 is exactly what this PR did, and it's byte-for-byte unchanged, so the coupling that row warns about still holds.

AI Usage Declaration

AI (Claude Sonnet 5 via Claude Code) performed this upgrade: read every per-crate CHANGELOG.md from 0.3.4 to 0.5.1 against a freshly git fetch --tags'd local checkout of upstream (/Users/selast/dev/authkestra, read-only), diffed the actual API surface vpay touches at the source level rather than trusting changelog summaries, bumped the pins, fixed the one real compile break, and ran the full local verification suite (build/clippy/fmt/deny/nextest) plus a live boot smoke test.

• A human is accountable for this change and has reviewed it.
• Every claim above was verified by running the command or diffing the source, not inferred from a changelog alone.
• Limitations stated explicitly — see Verification's "genuinely NOT covered" note and Risk Assessment.
• No functionality was fabricated or adopted opportunistically; the diff is exactly the version bump plus the one forced fixture fix.

Reviewer Focus

1. The Jwk fixture fix in backends/crates/vpay-api/src/resource_auth.rs — confirm crv: None, x: None is the right (only) fix and doesn't mask something more meaningful.
2. The OpStore seam claim — confirm the reasoning that vpay's exclusive use of the crate-provided SqlxOpStore (never a custom OpStore impl) means PR #191's new defaulted trait methods needed no code change here.
3. Whether the advisories check being unavailable offline (no network to github.com/RustSec/advisory-db in this sandbox) is acceptable to merge on, or should be re-run with network access before merging.

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 26913aa

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[stephane-segning]

CI status on this branch (run 32117462209):

Job	Result
rust (fmt-check, clippy -D warnings, cargo nextest run --workspace)	✅ pass
self-checks (no-mocks, status)	✅ pass
e2e (compose)	❌ fail
web	❌ fail
supply chain (cargo deny check)	❌ fail

The three failures are pre-existing and unrelated to this dependency bump, not something this PR introduced:

• e2e (compose) / web: both fail identically at the pnpm/action-setup@v4 step — Error: Multiple versions of pnpm specified: version 9 in the GitHub Action config vs pnpm@9.15.0 in package.json's packageManager. This is a CI-infra/action-config conflict, nothing to do with Rust or authkestra. Confirmed pre-existing: PR docs(roadmap): add the phased roadmap from scaffold to deployable #8 (docs(roadmap), a docs-only change with zero code diff) hit the exact same two failures on its own ci run (31440797764).
• supply chain: cargo deny check advisories fails on a newly-published RUSTSEC-2026-0258 (h2 crate, low-severity unbounded empty-DATA-frame DoS, patched in h2 v0.4.16). h2 v0.4.15 is unchanged by this PR — it's byte-identical in Cargo.lock before and after this bump (confirmed via git diff HEAD~1 HEAD -- Cargo.lock, no h2 entry touched), reached via hyper/reqwest/tonic/bollard, not via any authkestra-* crate. This is the RustSec advisory database catching up on master too — not something this PR's dependency change caused. (My own local cargo deny check couldn't reach advisories.db at all — no network in this sandbox — so this is the first time the check actually ran against a live advisory DB for this branch.)

Local verification for the actual change (build/clippy/fmt/deny-minus-advisories/nextest, plus a live boot smoke test) is in the PR description above and all passed before this push.

Left for a human/separate PR, out of scope here: fixing the pnpm/action-setup version conflict, and deciding whether/how to address RUSTSEC-2026-0258 (upgrade h2, or add a deny.toml ignore entry with justification, matching how RUSTSEC-2023-0071 is already handled) — both are pre-existing repo-wide issues, not scoped to an authkestra version bump.