Add oauth secrets support

[remi-td]

We can currently deploy remote teradata MCP servers accessible over https.

However the current way to pass user authentication details is over the http header. Tools such as Claude Desktop that support remote servers, also allow integration with oauth servers.

How:
Use OAuth 2.0 / OpenID Connect with a single IdP (e.g., Auth0 or Cognito) via FastMCP’s OIDC/OAuth proxy.
Interactive login (Auth Code + PKCE) happens in the browser; FastMCP validates tokens (JWKS, iss/aud/exp) and maps the authenticated identity 1:1 to a Teradata DB username. That mapping can come from IdP custom claims or a local mapping (config/service). The MCP server then connects and impersonates the mapped DB user using the existing "Basic" authentication mechanism, so Teradata RBAC policies apply.

Things to Do / Implement
1. Choose IdP & Register App to pilot: Eg. Auth0 or Cognito
• Create an app in IdP; enable Authorization Code + PKCE.
• Configure redirect URI: https:///auth/callback (and localhost for dev).
• Record Client ID/Secret and OIDC discovery URL.
2. FastMCP OAuth Wiring
• Enable OIDC/OAuth Proxy in the server (base URL, discovery URL, client creds).
• Request minimal scopes (openid, optionally profile/email; add audience if needed by Auth0).
• Expose OAuth metadata so clients (e.g., Claude Desktop) auto-discover & launch login.
• --> Use the current auth_mode server option to enable this mode (=='oauth')
3. JWT Verification & Session
• Validate signature via JWKS, and claims: iss, aud, exp, nbf.
• Enforce short access-token TTLs (typ. 5–15 min) and use refresh tokens for silent renewal.
• Cache tokens securely on server/client as appropriate (no logging of tokens).
• --> The mechanisms should already be in place for this
4. Identity → DB Mapping (1:1)
• IdP claims: investigate how a standard attribute can be stored and fetched in the IdP eg.
• Auth0: add custom namespaced claim, e.g. https://your-domain/teradata_user.
• Cognito: add custom:teradataUser attribute; include it in ID token.
• This may have to be implemented differently for each supported IDP...
• Provide local mapping alternative:
• Create a config file templaye (YAML/JSON) mapping email/sub → db_user, or
• The mapping file is loaded on server startup and used to fetch database user from user identity.
• The mapped database user id is used with the current "proxy" pattern used for Basic auth