Machine-to-machine API auth: OAuth2 resource server + API key management

[coopernetes]

Context

We have a single shared API key today (GITPROXY_API_KEY env var, X-Api-Key header → full ADMIN). This is fine for CI scripts but isn't a real machine-to-machine auth story.

The Node.js git-proxy has a "JWT API auth" config (authorityURL, clientID, expectedAudience), but that's just an OAuth2 resource server — no reason to treat it as something separate from the OIDC support we already have.

Approach: OAuth2 Resource Server (Bearer token validation)

Since we already support OIDC for dashboard login, the cleanest path is adding a second Spring Security filter chain for /api/** that accepts Bearer tokens:

• Machines authenticate via client_credentials grant against the same IdP (Keycloak, Entra ID, Okta, etc.)
• Spring Security validates the JWT against the IdP's JWKS endpoint
• Role mapping reuses the existing auth.role-mappings + groups-claim config
• No new auth system to build — this is a standard Spring Security OAuth2 Resource Server setup

auth:
  provider: oidc
  oidc:
    issuer-uri: https://accounts.example.com
    client-id: gitproxy-client
    client-secret: gitproxy-secret
  # Existing role-mappings apply to both browser (auth code) and machine (client_credentials) tokens
  role-mappings:
    ADMIN:
      - git-admins

MVP

• Add OAuth2 Resource Server filter chain for /api/** (validates Bearer JWTs from the configured OIDC issuer)
• Map claims/roles using the same role-mappings config
• Keep the existing GITPROXY_API_KEY env var as a fallback for environments without an IdP

Future

• Per-user API key generation (admin-only), with expiry
• Read/write scopes grouped by API surface
• User-level API keys (ROLE_USER, read-only across most endpoints)