SEC-SSO-03: Cache JWKS instead of fetching on every callback

[remyluslosius]

Filed from SSO security review 2026-04-14. Severity: LOW (performance + availability).

Current state

`backend/app/services/auth/sso/oidc.py:103-113` does a synchronous `httpx.get()` to the IdP's JWKS endpoint on every SSO login. No caching.

Risks

• Latency: adds a round-trip to every SSO login
• Availability coupling: if the IdP's JWKS endpoint is slow or down, all SSO logins stall
• Rate-limiting: frequent JWKS fetches may be rate-limited by some IdPs

Industry practice

IdPs publish JWKS with Cache-Control / ETag headers; clients cache for minutes to hours. Google, Auth0, Okta all advise clients cache JWKS.

Recommendation

In-process TTL cache (5-15 min) via `cachetools.TTLCache`, with refresh-on-miss if the id_token's `kid` isn't in the cached set.

References

• Source: `docs/SSO_SECURITY_REVIEW_2026-04-14.md`

[remyluslosius]

Still valid in the Go rebuild, re-scoped from the archived Python backend to the Go code. internal/sso/oidc.go:194-208 (jwksKey / validateIDToken) re-fetches JWKS on every token validation with no TTL cache; the inline comment documents this as a deliberate 'correct over fast' tradeoff (small responses, immediate key-rotation pickup). Risk is bounded (SSRF-guarded httpclient.NewGuardedClient, 1 MiB body cap) but the latency / IdP-availability-coupling / rate-limit concerns are real. LOW severity, design decision rather than a defect. Keeping open for a decision on adding a short-TTL cache.