feat(auth): forwardedClientId strategy and opt-in apikey/path secret locations

[snowkide]

Two opt-in auth additions for deployments where eRPC sits behind an API gateway or is used by clients that only take a single RPC URL, plus a tracing fix found along the way. Nothing changes for existing configurations.

Commits (reviewable separately):

1. feat(auth): forwardedClientId strategy. When a gateway or reverse proxy already authenticates callers and forwards the client id in a header, eRPC trusts that header as the user id, so per-client rate-limit budgets, method scoping and the user metric label work without duplicating the gateway's key store. Only active when configured.
   • header (default X-Client-Id)
   • allowedProxies: only trust the header from these direct TCP peers (socket address, not X-Forwarded-For)
   • allowedIds: optional allowlist, also bounds user label cardinality
   • rateLimitBudget
   • Multiple header values are rejected, as are empty ids, ids over 256 bytes, or ids with whitespace, commas or non-ASCII.
2. fix(tracing): redact ?secret=, ?token= and ?jwt= values from the http.url span attribute. Today they are exported verbatim to the tracing backend.
3. feat(auth): opt-in secret locations for the secret and database strategies, via additionalLocations (empty by default). Consulted only when none of the existing locations supplied a secret:
   • apikeyQuery: ?apikey=
   • apikeyHeader: X-Api-Key / apikey header
   • path: the URL path as a single segment (https://host/<secret>), only when a domain alias preselects project, architecture and chain; /admin, /healthcheck and /metrics are never treated as secrets.
   • A secret found in a location a strategy does not list is ignored by it. These locations never change the credential type, so requests without one of the existing credentials still reach a network strategy as before. Unknown location names fail validation.
   • Path secrets are redacted to /REDACTED in tracing and in the CORS metrics path label, and ?apikey= like ?secret=.

auth:
  strategies:
    - type: forwardedClientId
      forwardedClientId:
        header: X-Client-Id
        allowedProxies: ["10.0.0.0/8"]
        rateLimitBudget: per-client
    - type: secret
      secret:
        id: wallet-app
        value: ${WALLET_APP_SECRET}
        additionalLocations: [apikeyHeader]

Security note: forwardedClientId trusts a header. Enable it only behind a proxy that strips or overwrites that header from clients, and restrict allowedProxies to that proxy.

Verification

Based on erpc/erpc main @ 094b912.

• go build ./..., go vet ./... and gofmt -l on touched files are clean.
• make test-fast (what CI runs): passes, exit 0, no failing test.
• Tests for the opt-in: TestAuthRegistry_SecondarySecretLocations (each location accepted only when listed; standard locations unaffected), TestSecretStrategyConfig_ValidateAdditionalLocations, TestPathSecretAuth_FullyAliasedDomain; plus the forwardedClientId tests (TestAuthRegistry_ForwardedClientId*, TestAuthStrategyConfig_Validate_ForwardedClientIdRequiresBlock).
• TypeScript config types regenerated with tygo generate.

Notes for review:

• forwardedClientId is inert unless configured, and is only offered requests that carry its header. It authenticates (budgets, method scoping and allowClientDirectives apply), unlike trustUserIdHeader, which only labels.
• Not addressed here (pre-existing): the database strategy logs apiKey at debug/error level, and the secret strategy's comparison is not constant-time.
• Could be split into two PRs (forwardedClientId; secret locations with the tracing redaction fix) if reviewers prefer.

Docs: config/auth, operation/tracing.

AI assistance

• Model: anthropic/claude-opus-5.5
• Harness / skills: Claude Code
• Human-reviewed: no, pending

🤖 Generated with Claude Code