Make the header the session JWT is read from configurable

[apiloqbc]

LibreChat reads its session JWT from Authorization, hardcoded in api/strategies/jwtStrategy.js:

jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),

That's fine until something in front of LibreChat writes the same header. I run it behind an authenticating proxy that puts the provider's token into Authorization on the request it forwards upstream — in my case a service mesh filter, and oauth2-proxy does the same thing with --set-authorization-header=true. Once that's on, the strategy never receives the token LibreChat issued; it gets the proxy's RS256 token and returns 401 {"message":"invalid algorithm"}.

It's a deployment configuration that isn't supported today rather than a defect — LibreChat is doing exactly what it says it does. But there's no way to work around it from the outside, because the header is replaced before the request reaches node, so the only options are patching the source or not using that proxy configuration.

Two things made it slow to diagnose, in case anyone lands here from a search: it also fires on requests where the browser sent no Authorization at all, since the header is created upstream and the logs then look like a client problem. And #14311 reported the same error string from a different angle — that one was closed correctly, the algorithms fix proposed there is a no-op, but the explanation given in the thread (the error comes from the HS256 jwt fallback) is what happens here too.

What I'd like to add

An optional JWT_AUTH_HEADER naming a header to try before Authorization, unset by default:

const jwtExtractor = () => {
  const extractors = [];
  if (process.env.JWT_AUTH_HEADER) {
    extractors.push(ExtractJwt.fromHeader(process.env.JWT_AUTH_HEADER));
  }
  extractors.push(ExtractJwt.fromAuthHeaderAsBearerToken());
  return extractors.length > 1 ? ExtractJwt.fromExtractors(extractors) : extractors[0];
};

The operator's proxy preserves the client's token in that header; it's expected raw, without a Bearer prefix, since fromHeader doesn't strip one.

Affected areas: api/strategies/jwtStrategy.js only, plus a commented-out line in .env.example and three cases appended to the existing api/strategies/jwtStrategy.spec.js. Unset — the default — the rendered behaviour is the same single extractor as today.

openIdJwtStrategy has the identical line and I'd leave it alone: it verifies an IdP token via JWKS and an audience check, and the standard header is exactly where a proxy like this puts an IdP token.

No new trust is involved. Whatever is in the header still has to be a JWT signed with JWT_SECRET, so setting it without the secret gets you nothing.

Not the same as #1856 / #8562

Those ask LibreChat to trust an identity asserted by the proxy (Remote-User, X-Forwarded-User), which is a much bigger decision and deserves its own discussion. Here the token stays LibreChat's own and stays verified the same way — only where it's read from becomes configurable. The two would compose fine if both landed.

Status

I've opened #14753 with this. 10 suites / 291 tests pass on the branch, against 288 on an unmodified main, so the difference is exactly the three tests added there. Happy to change the shape of it — a config key instead of an env var, a different name, whatever fits better — or to close it if you'd rather not carry the option at all.