feat: OIDC compliance — add standard authorization server endpoints

[chokoblitz]

Context

We need to integrate auth-server as the authentication provider for APISIX (API gateway in the velo project).

APISIX's openid-connect plugin requires a standard OIDC provider. The current auth-server uses a custom session-cookie flow, which forces us to use the forward-auth plugin instead — adding latency (1 HTTP call per request) and making auth-server a potential SPOF.

PR #7 (feat/kms_login) starts moving in the right direction by adding /.well-known/jwks.json. This issue tracks the remaining work for full OIDC compliance.

Missing endpoints

Endpoint	Status	Notes
GET /.well-known/jwks.json	🔄 PR #7	Moves from /public/jwks
GET /.well-known/openid-configuration	❌	Discovery document — required by all OIDC clients
GET /authorize	❌	Authorization Code Flow with PKCE (redirect-based)
POST /token	❌	Exchange code → access_token + id_token (signed JWT)
POST /token (refresh)	❌	refresh_token grant
GET /userinfo	❌	Returns claims from Bearer token (replaces /whoami + cookie)

Expected behavior

With these endpoints in place:

• APISIX openid-connect plugin handles the full auth flow natively
• JWT validation is done locally by APISIX (via JWKS) — no per-request call to auth-server
• Standard redirect flow works for browser clients
• Any OIDC-aware tool (Grafana, ArgoCD, etc.) can use auth-server directly without adaptation

Out of scope

• Dynamic client registration (RFC 7591) — static client config is sufficient for now
• Token introspection endpoint — local JWT validation covers this use case

Relationship to existing work

• PR Feat/kms login #7 covers the JWKS part — this issue covers the rest of the authorization server flow
• The add_role_to_user branch adds roles to users — role claims should be included in the id_token and /userinfo response as part of this work

[charming-wicket-5502]

In its current state the Authentication Server is tailor-made for VELO, KMS and other highly secure applications that require a simple and verifiable codebase. As far as I know, it's not meant to become a full on OIDC Identity Provider. This seems to be out of scope and possibly against the flow of what the server is trying to achieve.