Edit Issue - .issue.db

Title *

Description

EARS SPEC:
- When a token endpoint fails, the API shall return a generic error code and message to the caller;
  the underlying exception text shall be logged server-side only, never included in the response body.
- No error response shall interpolate a caught exception into a client-visible field.

FOUND DURING #880 (split of api/blueprints/v1/tokens.py). PRE-EXISTING - the split was pure-move and
left it byte-identical, correctly. Not introduced by the refactor.

DEFECT:
- api/blueprints/v1/tokens.py `_get_jwt_config` raises with an f-string interpolating the caught
  exception: f"JWT configuration missing in Vault: {e}"
- Several handlers in the same module return details={"error": str(e)} to the CALLER.

WHY IT MATTERS: this is the token-issuance path, and its exceptions come from Vault lookups and JWT
config. A 500 body can therefore carry secret-store paths, connection strings, or internal state to
an unauthenticated or low-privilege caller. #851 showed exactly how much a Vault error message can
reveal about internal topology.

REPRODUCTION (do NOT assume - exercise it):
Break the Vault path or revoke the token so _get_jwt_config raises, then call the token endpoint and
inspect the RESPONSE BODY, not the log. Confirm the exception text appears in the body. That is the
known-positive; only then is a fix's absence-of-leak meaningful.

FIX: log the exception with logger.exception / logger.error("...: %s", e) server-side, and return a
fixed error code + generic message. Sweep the module for every str(e) / {e} that reaches a response.

SCOPE NOTE: check whether the same pattern exists in the other auth-adjacent blueprints
(api_keys.py, secrets.py, oauth_handlers/) - if so, widen this ticket rather than fixing one file.

Due Date (YYYY-MM-DD)

Tags (comma separated)

Related Issues (IDs)

Enter IDs of issues related to this one. They will be linked as 'related'.

Edit Issue #911