Support public-key-only Secrets in wristband `signingKeyRefs` for verification

[pierDipi]

Summary

Allow signingKeyRefs in the wristband response configuration to accept Secrets containing only public keys (for signature verification), not just private keys (for signing). Currently, Authorino rejects public-key-only Secrets with "invalid signing key algorithm".

Problem

In a multi-cluster federation setup, each cluster issues wristband JWTs signed by its own private key. Peer clusters need to verify these tokens but do not need to sign with them. The current signingKeyRefs API requires every referenced Secret to contain a private key — there is no way to add a key for verification only.

This forces operators to distribute private signing keys to every peer cluster, which creates a cascading compromise risk: an attacker who compromises any single cluster gains access to every peer's private signing key and can forge tokens that appear to originate from any cluster in the federation.

Current behavior

response:
  success:
    headers:
      x-wristband-token:
        wristband:
          issuer: "https://..."
          signingKeyRefs:
            - name: local-signing-key    # private key — signs tokens ✓
              algorithm: ES256
            - name: peer-cluster-key     # must also be private key ✗
              algorithm: ES256           # rejected if public-key-only

If peer-cluster-key contains only a public key (e.g., PEM with BEGIN PUBLIC KEY), Authorino rejects it with "invalid signing key algorithm".

Desired behavior

signingKeyRefs:
  - name: local-signing-key        # private key — used for signing
    algorithm: ES256
  - name: peer-cluster-key         # public key only — used for JWKS verification
    algorithm: ES256

The first key (private) signs new tokens. All public keys are published in the JWKS endpoint for verification. The second+ keys only need public keys.

Use case

• Multi-cluster wristband federation: Clusters issue wristband JWTs for cross-cluster identity portability. Each cluster signs with its own key and verifies tokens from all peers. Currently requires distributing all private keys to all clusters.
• Key rotation with overlap: During key rotation, the old key (public only, private destroyed) should remain in the JWKS for verification of in-flight tokens while the new key signs.
• Zero-trust posture: Verification-only peers should never hold signing keys they don't own.

Security impact

With public-key-only support, compromising a peer cluster would only expose:

• That cluster's own private signing key
• Other clusters' public keys (non-sensitive)

Without it (current state), compromising any peer exposes all clusters' private keys — a single breach cascades into full federation compromise.

Alternatives considered

1. Separate JWKS endpoint per peer: Each peer cluster serves its own JWKS at a different URL. The consumer configures multiple jwt authentication entries, one per peer. This works but doesn't scale — adding a peer requires adding a new auth rule on every cluster.
2. External JWKS aggregator: A sidecar or service that aggregates multiple JWKS endpoints into one. Adds operational complexity.

[guicassolato]

The wristband.signingKeyRefs in an AuthConfig are primarily for signing the wristband tokens. The fact they also require a public key paired to a private one is for distribution of the key only. The instance of the service that signs a token (with a private key) should be the only source of truth for distributing the key that allows to validate such signature (the public one). I do not see how a wristband configuration could be composed only of references to public keys or contain references to public keys not guaranteed to pair to their corresponding private ones.

For the distribution of the public keys, each wristband config in an AuthConfig exposes two endpoints that request authenticators can consume from:

• OIDC Discovery endpoint: :8083/{namespace}/{authconfig-name}/{response-config-name}/.well-known/openid-configuration
• JWKS endpoint: :8083/{namespace}/{authconfig-name}/{response-config-name}/.well-known/openid-connect/certs

While the OIDC Discovery endpoint is for convenience and easy setup in an authentication.jwt config (typically at another AuthConfig), the JWKS endpoint only serves the public key, not the private one.

IIUC, it sounds like what you want to do is to avoid using these endpoints for key distribution across clusters, but replicating them within the consumer cluster with an AuthConfig that contains a wristband rule whose purpose is fundamentally different than what it was designed for. Whereas the actual counterpart of a response.success.wristband rule should be an authentication.jwt another, not yet another response.success.wristband, only so you get convenient key distribution endpoints within the same local cluster, which effectively breaks the single source of truth principle.

[guicassolato]

What I think could be a more reasonable RFE that does not disrupt the purpose of the Wristband feature (i.e., of injecting a signed JWT into the pipeline) is an extension of authentication.jwt to support reading the public key from a Kubernetes Secret instead of fetching it from an HTTP endpoint.

It would require some additional configuration to specify things like the signing algorithm for example. However, you would be able to craft one Secret for the signing cluster that contains both private and public key and another Secret for the authenticator cluster containing only the public key. It still breaks the single source of truth but since you seem to be willing to create two separate secrets anyway, it may be a better compromise IMO.

[pierDipi]

Agree, the major problem is the coupling of signingKeyRefs with the wristband JWKS endpoint response since to get JWKS endpoint to include all public keys we need to add it signingKeyRefs