OIDC auth config not parsed at endpoint level; context.auth.username not injected into SQL templates

[zoi-nt]

Summary

Two related issues prevent using OIDC/Google ID token authentication end-to-end in flAPI:

1. OIDC config not parsed at endpoint level — parseEndpointAuth() in src/config_manager.cpp handles bearer and basic auth types but does not parse the oidc block. Moving OIDC config to the global flapi.yaml level works (parsed by parseAuthConfig()), but the parsed config is stored in a local variable and never propagated to endpoint.auth.oidc, so authenticateOIDC() in src/auth_middleware.cpp always sees an empty config.

2. context.auth.username documented but not available in SQL templates — CONFIG_REFERENCE.md (section 7.4) documents {{{ context.auth.username }}} as a template variable, but createTemplateContext() in src/sql_template_processor.cpp only injects conn, env, cache, and params — it never adds auth context. This means there is no way to use the authenticated user's identity in SQL queries via the documented mechanism.

Steps to Reproduce

Bug 1: OIDC not parsed at endpoint level

Add OIDC config to an endpoint YAML:

auth:
  enabled: true
  type: oidc
  oidc:
    issuer: https://accounts.google.com
    audience: my-client-id
    jwks-url: https://www.googleapis.com/oauth2/v3/certs

Result: OIDC auth is not enforced. The oidc block is silently ignored by parseEndpointAuth().

Moving to global config (flapi.yaml) parses the OIDC block but does not propagate it to endpoints.

Bug 2: context.auth.username not in template context

Configure bearer/JWT auth (which works), then use in SQL template:

SELECT * FROM my_table WHERE user_id = '{{{ context.auth.username }}}'

Result: context.auth.username renders as empty string. The sub claim is extracted during authentication (ctx.username in auth_middleware.cpp) but never passed to the template context.

Expected Behavior

1. OIDC config should be parseable at endpoint level (like bearer/basic), and global OIDC config should propagate to endpoints.
2. context.auth.username (and potentially other auth claims) should be available in SQL templates as documented.

Workaround

For now, we use JWT/bearer auth with a shared secret (HS256) between Apigee and flAPI, and pass the user email as a query parameter (auth_user) instead of relying on context.auth.username.

Environment

• flAPI: latest Docker image (ghcr.io/datazoode/flapi:latest)
• Source: src/config_manager.cpp, src/auth_middleware.cpp, src/sql_template_processor.cpp