[Enhancement]: Resolve LibreChat placeholder templates in BEDROCK_AWS_BEARER_TOKEN for per-user gateway auth

What features would you like to see added?

Allow BEDROCK_AWS_BEARER_TOKEN to contain LibreChat placeholder templates — e.g. {{LIBRECHAT_OPENID_ID_TOKEN}} or {{LIBRECHAT_USER_ID}} — resolved per request rather than being treated as a single static literal.

Today the Bedrock endpoint can authenticate in exactly two ways:

1. AWS SigV4 — access key / secret / session token
2. A static bearer token — one BEDROCK_AWS_BEARER_TOKEN shared by the whole deployment

Both are deployment-wide. There is no way for Bedrock traffic to carry the identity of the user who actually made the request.

This matters when BEDROCK_REVERSE_PROXY points at an AI gateway that authenticates the caller itself (via httpBearerAuth) instead of AWS SigV4. In that topology the gateway wants a per-user credential so it can attribute usage, apply per-user quotas, and authorize model access. With a single static token, every LibreChat user arrives at the gateway as the same principal — the gateway cannot tell them apart, and per-user policy becomes impossible.

More details

The capability already exists elsewhere in LibreChat

Custom endpoints solve exactly this with header templating:

headers:
  Authorization: "Bearer {{LIBRECHAT_OPENID_ID_TOKEN}}"

The resolution machinery is already in the codebase (resolveHeaders, and the LIBRECHAT_OPENID_* / LIBRECHAT_USER_* placeholder set). The Bedrock endpoint simply has no equivalent — it reads BEDROCK_AWS_BEARER_TOKEN and passes the literal string through.

So this is not a new subsystem. It is applying an existing, established mechanism to one endpoint that currently misses out.

Why not just use a custom endpoint?

A custom endpoint loses what the Bedrock endpoint provides: Bedrock model listing, the Converse API shape, guardrail configuration, inference profiles, and the region/proxy handling already built around ChatBedrockConverse. Reimplementing Bedrock as a generic custom endpoint to gain per-user auth means giving all of that up.

Backwards compatibility

A token containing no {{ is returned unchanged, so existing static Bedrock API keys and SigV4 setups behave exactly as they do today. The feature is inert unless an operator opts in by writing a placeholder into the value.

Behavior worth deciding explicitly

If the placeholder cannot be resolved — for example an expired OIDC session when using {{LIBRECHAT_OPENID_ID_TOKEN}} — the request should fail closed with a re-authentication signal rather than forward a stale or empty credential to the gateway. LibreChat already has OpenIDReauthRequiredError for this, which maps to 401 invalid_token.

Possible solution

PR #14426 implements this: https://github.com/danny-avila/LibreChat/pull/14426

Scope is small — 3 files, ~95 insertions:

• packages/api/src/endpoints/bedrock/initialize.ts — resolve the token through the existing resolveHeaders when it contains a placeholder; pass it through untouched otherwise
• packages/api/src/endpoints/bedrock/initialize.spec.ts — coverage for OIDC ID-token resolution, user-field placeholders, static-token pass-through, and expired-token rejection
• .env.example — document the new usage

It reuses the existing placeholder resolver rather than adding a parallel path, and it is currently rebased on dev. I am happy to rework the approach if a different shape fits the codebase better — the capability is what matters, not this particular patch.

Related issues and discussions

• #8430 (closed, shipped) — "Support new AWS Bedrock API Keys" introduced the static BEDROCK_AWS_BEARER_TOKEN. This request is the per-user continuation of that work.
• #14299 (open) — "Configurable baseURL + header templating (e.g. {{LIBRECHAT_OPENID_ID_TOKEN}}) for gemini_image_gen, to support LLM gateways" — the same mechanism requested for a different endpoint, which suggests this is a general gap rather than a Bedrock-specific one.
• #9444 (closed) — "Forward JWT Token from logged-in LibreChat User to Custom Endpoints" — precedent for forwarding per-user identity downstream.
• Discussion #11877 (unanswered) — "Support for AWS SigV4 + Passing OIDC Token to AgentCore Runtime" — an adjacent need to carry a user's OIDC token into AWS.

Which components are impacted by your request?

• General
• UI
• Endpoints
• Plugins
• Other

Which components are impacted by your request?

No response

Pictures

No response

Code of Conduct

• I agree to follow this project's Code of Conduct