feat: add perform device-code, make update oauth2-client non-destructive, report key set in get jwk

[alnr]

Closes #264

Wires hydra's OAuth 2.0 Device Code flow into ory perform, alongside the existing authorization-code and client-credentials subcommands, and bumps github.com/ory/hydra/v2 to pick it up.

$ ory perform --help
Available Commands:
  authorization-code Example OAuth 2.0 Client performing the OAuth 2.0 Authorize Code Flow
  client-credentials Perform the OAuth2 Client Credentials Flow
  device-code        Example OAuth 2.0 Client performing the OAuth 2.0 Device Code Flow

The wiring itself is five lines. No extra plumbing was needed: NewPerformDeviceCodeCmd uses the same two cliclient hooks as authorization-code (NewClient and GetOAuth2URLOverride), and client.ContextWithClient already registers both context keys, so project resolution to <slug>.projects.oryapis.com works as-is.

The -p, --port flag is passed through unmodified, matching how every other wrapped hydra command behaves. It starts a local server serving the device verification page and requires pointing urls.device.verification at http://127.0.0.1:<PORT>/device, so it is primarily a self-hosted debugging aid — Ory Network has its own verification UI in Account Experience. There is no shorthand collision: --project has no shorthand, and perform authorization-code already binds -p to its own --port.

Dependency bump

github.com/ory/hydra/v2 moves to 20260727152228-962ddb5de40a. hydra's go.mod carries replace github.com/ory/x => ./oryx plus a placeholder ory/x version, which MVS ignores — so bumping hydra alone leaves ory/x behind and the build fails with undefined: prometheusx.Handler. ory/x is bumped in lockstep to its matching monorepo commit.

Two user-visible behavior changes ride along with the bump:

• ory update oauth2-client no longer resets fields you did not pass. It now PATCHes only the flags actually set, instead of PUTing the entire client. Passing --file keeps the previous replace-everything semantics.
• ory get jwk output shape changed. Each key now carries its own set field, and the collection-level set is omitempty, dropped when results span multiple sets. Worth noting for anything parsing that JSON.

Critical CVE fix (kin-openapi)

The Docker Image Scan started failing on this branch. It gates on severity-cutoff: critical, and the only Critical finding is GHSA-r277-6w6q-xmqw — a fail-open authentication bypass in kin-openapi's ValidationHandler.Load() via the NoopAuthenticationFunc default, affecting <= 0.143.0. Bumped github.com/getkin/kin-openapi v0.131.0 → v0.144.0.

This is not a regression from this PR. master pins the same v0.131.0 and last went green on 2026-07-22; the advisory landed after that, so master fails the same scan if re-run today. This branch just happens to be the first PR to surface it.

We are not actually exposed: the only consumer is ory dev openapi migrate, which uses openapi2/openapi2conv for Swagger 2.0 → OpenAPI 3.0 conversion and never touches the vulnerable validation middleware. The scanner gates on the resolved version regardless.

Since that is a 13-minor-version jump on a package with no test coverage, I verified it by hand: converting a Swagger 2.0 fixture covering path/query/body parameters, $ref'd definitions and an accessCode security definition produces byte-identical output before and after the bump.

Remaining scan findings (all below the gate, none actionable here)

Finding	Severity	Notes
stdlib go1.26.4 (CVE-2026-39822, GO-2026-4970, CVE-2026-42505, GO-2026-5856)	High / Medium	Fixed in Go 1.26.5. .docker/Dockerfile-build uses the floating golang:1.26-alpine3.22 tag, so this clears itself on the next upstream image rebuild — nothing to pin.
busybox, busybox-binsh, ssl_client (CVE-2025-60876)	Medium	Floating alpine:3.22 base, same story.
golang.org/x/crypto (GO-2026-5932)	Unknown	No fix exists — the advisory is that x/crypto/openpgp is unmaintained, introduced at v0 and never patched. Bumping to v0.54.0 would not clear it.

Related Issue or Design Document

n/a — this exposes an already-designed upstream hydra command.

Checklist

• I have read the contributing guidelines and signed the CLA.
• I have referenced an issue containing the design document if my change introduces a new feature.
• I have read the security policy.
• I confirm that this pull request does not address a security vulnerability.
• I have added tests that prove my fix is effective or that my feature works.
• I have added the necessary documentation within the code base (if appropriate).

Further comments

On the missing tests checkbox: no dedicated test was added, matching the existing pattern — neither authorization-code nor client-credentials has one. Device code cannot be driven headlessly: it blocks on a human approving the user code at the verification URL. A real test would need either a live project plus browser automation or a stubbed device endpoint, which is a larger piece of work than this wiring. Happy to build that harness in a follow-up if wanted.

TestUsageTemplating walks the full command tree and now covers the new command's help templating. Build, vet, and all non-cloudx tests pass; ./cmd/cloudx/oauth2/... also passes against live staging, which covers the commands affected by the dependency bump.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TVLKg5HjkMS47rksPeVP7L

Summary by CodeRabbit

• New Features
  • Added support for performing OAuth2 device-code flows through the CLI.
  • Device-code authentication is now available alongside existing authorization-code and client-credentials flows.

[coderabbitai]

📝 Walkthrough

Walkthrough

The cloudx CLI adds a Hydra-backed OAuth2 device-code perform command and registers it alongside existing flows. The module manifest also updates several direct and indirect dependency versions.

Changes

Device-code command support

Layer / File(s)	Summary
Register device-code command cmd/cloudx/oauth2/flows.go, cmd/cloudx/perform.go	Adds NewPerformDeviceCode and registers the resulting subcommand with NewPerformCmd.

Dependency version updates

Layer / File(s)	Summary
Update module versions go.mod	Advances selected ORY, golang.org/x, pgx, pop, and gRPC module versions.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title covers the main feature and related dependency behavior changes, even if it is broader than the core PR.
Description check	✅ Passed	The description follows the template well with a summary, related issue, checklist, and further comments.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/perform-device-code

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}