OIDC backend jwks

[AaronPlave]

• Tickets addressed: None
• Review: By commit
• Merge strategy: Merge (no squash)

Description

Adds OIDC verification (asymmetric/JWKS – e.g. Keycloak RS256) to the two backend services that validate bearer tokens directly, the action server (TypeScript) and the workspace server (Java), alongside the existing symmetric (HMAC/SSO) path. Both read the same HASURA_GRAPHQL_JWT_SECRET.

• Two modes from one secret: a shared key (HMAC) or a jwk_url (JWKS). The secret is validated up front (exactly one of key/jwk_url, algorithm family must match the mode), and the verification algorithm is pinned, so an RS public key can't be abused as an HMAC secret.
• Aligned accept/reject semantics across both servers (they consume the same secret):
  • audience matches any configured audience (the workspace server uses withAnyOfAudience, matching jsonwebtoken's array behavior)
  • issuer – both honor issuer and the legacy iss alias
  • identity is resolved from a top-level username claim, falling back to x-hasura-user-id in the Hasura claims namespace (OIDC tokens), so both servers attribute a request to the same user.
• Robustness:
  • Require the Hasura claims namespace
  • Guard the RSA key cast so a non-RSA JWKS key returns 401 instead of an uncaught 500
  • Validate audience array elements
  • Bounded JWKS cache + rate limiting so unknown kid (Key ID) floods can't hammer the IdP
  • 401 responses return a curated message (expired vs. invalid) and log the detail server-side rather than echoing library internals / expected issuer/audience to callers.

Verification

• Automated tests added: action-server (tests/app.test.mts, tests/authConfig.test.mts) – x-hasura-user-id username fallback and issuer validation via the legacy iss field. workspace-server (JWTServiceTest.java, new) – identity resolution, role validation, issuer match/mismatch, and audience checks.

Documentation

• HASURA_GRAPHQL_JWT_SECRET now accepts OIDC fields – jwk_url, issuer/iss, audience (string or array), and asymmetric type values (RS256/RS384/RS512) in addition to the existing { type: "HS*", key } form. Any deployment/env docs describing this secret should be updated to cover the JWKS configuration.

Future work

• None

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE