Authenticate clients with SPIFFE JWT-SVIDs

[jhrozek]

Summary

Part of the SPIFFE client-authentication epic (#6199), issue #6203. Stacks on top of #6562 (the coordination dispatcher).

• Implements the JWT-SVID arm of newSPIFFEClientAuthenticationStrategy: a serialized JWT-SVID client assertion (client_assertion_type/client_assertion form fields, capped at 16 KiB) is validated with go-spiffe's jwtsvid.ParseAndValidate against the configured JWT bundle source, requiring the assertion's sole audience to be the configured authorization-server issuer.
• After validation, the resolved SPIFFE ID is passed through the shared SPIFFEAssociationRegistry.Resolve path (the same one Implement X.509-SVID OAuth client authentication (spiffe_x509) #6202's X.509 arm will use) to bind the configured immutable static OAuth client to the resolved principal.
• Malformed request fields fail with a generic OAuth invalid_request; validation, association, and mixed-credential failures fail with a generic invalid_client — deliberately generic so a probing attacker can't distinguish failure reasons. An HTTP Basic authorization header or any client_secret form field alongside a SPIFFE JWT assertion is rejected outright (SPIFFE auth must be the sole credential in the request).
• SPIFFEAssociationRegistry.Resolve is extended to accept an optional client ID: an empty one derives the configured client from the association, letting the JWT arm resolve without the caller needing to separately supply client_id.
• Adds architecture documentation (docs/arch/18-spiffe-association-declarations.md) covering the association model and this authentication path's behavior and known limitations (no application-level replay protection/jti persistence/nonce yet; inherits go-jose's default one-minute claim leeway).

Type of change

• New feature

Test plan

• Unit tests (task test)

go test ./pkg/authserver/... and the touched cmd/thv-operator packages pass. go build ./... and go vet ./... are clean.

API Compatibility

This PR does not touch operator API surface (no CRD/v1beta1 changes).

Changes

File	Change
pkg/authserver/server/spiffe_client_auth.go	Implement the JWT-SVID validation and resolution arm
pkg/authserver/spiffe_association_registry.go	Resolve accepts an optional (derivable) client ID
pkg/authserver/server/provider.go, server_impl.go	Wire issuer + JWT bundle source through to the dispatcher
pkg/authserver/server/registration/spiffe_client.go	Supporting registration-client changes
docs/arch/18-spiffe-association-declarations.md	New architecture doc for the SPIFFE association model

Does this introduce a user-facing change?

No — SPIFFE JWT client authentication is not reachable yet; the embedded auth server still rejects any non-empty spiffeTrustDomains configuration until the trust-bundle loading work (#6201) lands.

Special notes for reviewers

Second PR in the stack: #6562 (clientauth, base of this PR) → this PR (#6203, JWT) → #6202 (X.509, stacks on top of this one, not yet sent). Please review/merge in that order.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.90%. Comparing base (9fe5c43) to head (a2d9cc5).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #6563    +/-   ##
========================================
  Coverage   78.90%   78.90%            
========================================
  Files         780      781     +1     
  Lines       77683    77823   +140     
========================================
+ Hits        61298    61409   +111     
- Misses      16380    16409    +29     
  Partials        5        5            

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JAORMX]

Fresh panel review of the incremental stack diff 5dee1fb7521e74127473258a63175a702a71f747...08e84f13ff636de2dc41c28544f9658150405616 against #6203.

Blocking — require no iss claim from a JWT-SVID

pkg/authserver/server/spiffe_client_auth.go:111-117 rejects an otherwise valid JWT-SVID unless it has an iss claim equal to the trust-domain string. iss is optional application-specific JWT-SVID metadata; #6203 requires a valid SPIFFE sub, valid expiry, exactly the AS issuer as audience, and validation against the associated trust-domain bundle—not an issuer claim. Once bundle wiring lands, conformant signed SVIDs without iss will be rejected. Remove this unconditional requirement, or make it an explicit documented/configured extension.

Blocking — the shared dispatcher changes unrelated authentication behavior

pkg/authserver/server/spiffe_client_auth.go:46-53 rejects duplicate client_assertion_type values before checking whether SPIFFE is configured or selected. This changes default/Fosite handling of entirely non-SPIFFE (including RFC 7523 private-key JWT) requests, contrary to #6203's explicit constraint that this arm must not modify the shared dispatcher. The SPIFFE path should reject ambiguous requests when any assertion type selects SPIFFE, while entirely non-SPIFFE requests must continue directly to defaultStrategy. Please move the shared dispatcher adjustment to #6562 along with its needed duplicate-SPIFFE detection, then rebase this PR.

The JWT bundle source is intentionally not connected to production configuration until dependency #6201; the PR documents that it remains unreachable, so that is not a finding. Standards, reuse, duplication, and DevEx panel members found no additional actionable issues; no assertion/claim logging was found.

[JAORMX]

Fresh review at 08e84f1, scoped strictly to this PR's stacked range from #6562 head 5dee1fb.\n\nApproved. The code-review, security, protocol, and architecture panel found no merge blockers. The JWT arm enforces assertion cardinality and size, verifies only through the configured JWT bundle source, requires a sole issuer audience, rejects mixed credentials, and fails closed without a bundle source or association. The documented absence of deployable bundle wiring is an explicit, safe deferral: validation cannot be reached from the production configuration path.\n\nNon-blocking: docs/arch/18-spiffe-association-declarations.md:3-5 still says no JWT-SVID is verified anywhere in the build, contradicting the implemented but non-deployable validation described at :81-116. Narrow it to no deployable construction path being wired to a trust bundle source.\n\nExact-head CI is green; that status is independent of this approval.

[JAORMX]

Superseding my approval: I rechecked the current-head JAORMX review (5154974136) against this PR's exact stacked range and its two blockers remain unresolved.\n\n### Blocking — do not require an application-specific iss claim\n\npkg/authserver/server/spiffe_client_auth.go:111-117 rejects an otherwise valid JWT-SVID unless it contains iss equal to the trust domain. #6203 requires the valid SPIFFE sub, expiry, sole AS-issuer audience, and bundle verification; iss is not among its JWT-SVID acceptance requirements and relying on undeclared claims harms interoperability. Remove the unconditional requirement, or make it a documented/configured extension.\n\n### Blocking — this JWT arm modifies unrelated default authentication behavior\n\npkg/authserver/server/spiffe_client_auth.go:46-53 rejects duplicate client_assertion_type before selecting SPIFFE. That changes fully non-SPIFFE/default Fosite requests (including RFC 7523 private-key JWT) and conflicts with #6203's scope: this arm must not modify the shared dispatcher. Put the required ambiguous-SPIFFE detection in #6562, and ensure entirely non-SPIFFE inputs continue to defaultStrategy.\n\nThe absent production bundle wiring remains an explicitly documented, safe fail-closed deferral. Exact-head CI is green and separate from these review blockers.