How to Fix 'authentication failed in production' in LangChain (TypeScript)

When you see authentication failed in production in a LangChain TypeScript app, it usually means the model provider rejected your API credentials at runtime. The annoying part is that the same code often works locally, then fails after deployment because the production environment is missing a secret, has the wrong key, or is loading the wrong config.

In LangChain, this typically shows up when instantiating classes like ChatOpenAI, AzureChatOpenAI, or other provider wrappers and then calling invoke(), stream(), or generate().

The Most Common Cause

The #1 cause is simple: your local .env is correct, but production is not loading the right environment variable, or it’s loading an empty value.

With LangChain + OpenAI-style integrations, this usually means OPENAI_API_KEY is missing, misnamed, or injected too late.

// ❌ Broken
import { ChatOpenAI } from "@langchain/openai";

const model = new ChatOpenAI({
  apiKey: process.env.OPENAI_API_KEY || "", // empty string in prod = auth failure
  model: "gpt-4o-mini",
});

await model.invoke("Hello");

// ✅ Fixed
import "dotenv/config";
import { ChatOpenAI } from "@langchain/openai";

const apiKey = process.env.OPENAI_API_KEY;

if (!apiKey) {
  throw new Error("Missing OPENAI_API_KEY");
}

const model = new ChatOpenAI({
  apiKey,
  model: "gpt-4o-mini",
});

await model.invoke("Hello");

If you’re using a platform secret store, make sure the variable name matches exactly. LangChain won’t “guess” your secret name; it passes what you give it to the provider SDK.

Other Possible Causes

1. Wrong provider variable for Azure OpenAI

A common mistake is using OpenAI env vars with AzureChatOpenAI.

// ❌ Broken
import { AzureChatOpenAI } from "@langchain/openai";

const llm = new AzureChatOpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  azureOpenAIApiKey: process.env.OPENAI_API_KEY,
  azureOpenAIApiInstanceName: process.env.AZURE_OPENAI_INSTANCE_NAME,
  azureOpenAIApiDeploymentName: process.env.AZURE_OPENAI_DEPLOYMENT_NAME,
});

// ✅ Fixed
import { AzureChatOpenAI } from "@langchain/openai";

const llm = new AzureChatOpenAI({
  azureOpenAIApiKey: process.env.AZURE_OPENAI_API_KEY!,
  azureOpenAIApiInstanceName: process.env.AZURE_OPENAI_INSTANCE_NAME!,
  azureOpenAIApiDeploymentName: process.env.AZURE_OPENAI_DEPLOYMENT_NAME!,
  azureOpenAIApiVersion: "2024-02-15-preview",
});

Azure auth failures often show up as 401 Unauthorized or messages like Authentication failed due to invalid subscription key.

2. Secret injected at build time instead of runtime

This bites people using Next.js, Docker, or CI/CD pipelines. The app builds with one env set, but runs with another.

// ❌ Broken in serverless/runtime split
const model = new ChatOpenAI({
  apiKey: process.env.NEXT_PUBLIC_OPENAI_API_KEY,
});

// ✅ Fixed
const model = new ChatOpenAI({
  apiKey: process.env.OPENAI_API_KEY!,
});

Do not expose provider keys through public env prefixes like NEXT_PUBLIC_. That variable gets bundled into client code and is the wrong place for secrets.

3. Wrong key type or revoked key

Sometimes the key exists, but it’s not valid for that provider or environment. You’ll see errors like:

• •401 Incorrect API key provided
• •Authentication failed
• •Invalid authentication credentials

// Example config issue
OPENAI_API_KEY=sk-test-not-a-real-prod-key

Check whether production is pointing to a stale rotated key, a sandbox key, or a key from another account.

4. Proxy or gateway stripping auth headers

If you’re routing requests through an internal proxy, API gateway, or egress filter, it may remove the Authorization header before the request reaches OpenAI/Azure/Anthropic.

// Example: custom fetch/proxy layer can break auth if misconfigured
const model = new ChatOpenAI({
  apiKey: process.env.OPENAI_API_KEY!,
  configuration: {
    baseURL: "https://internal-proxy.company.com/openai",
  },
});

If that proxy does not forward headers correctly, LangChain will look fine while the upstream provider returns authentication errors.

How to Debug It

1. •

   Log only presence, never the secret

   • •Confirm the variable exists in production.
   • •Use this pattern:

   console.log("OPENAI_API_KEY present:", Boolean(process.env.OPENAI_API_KEY));
   

2. •

   Check which class you are actually using

   • •ChatOpenAI expects OpenAI-compatible auth.
   • •AzureChatOpenAI expects Azure-specific fields.
   • •A mismatch here produces misleading auth errors.
3. •

   Reproduce with a minimal script

   • •Strip your app down to one file and one call.

   import { ChatOpenAI } from "@langchain/openai";
   
   const llm = new ChatOpenAI({ apiKey: process.env.OPENAI_API_KEY!, model: "gpt-4o-mini" });
   console.log(await llm.invoke("ping"));
   

   • •If this fails too, the problem is config/auth, not your chain logic.
4. •

   Inspect runtime env inside the deployed container

   • •In Docker/Kubernetes/serverless logs, verify the exact env names.
   • •Common failure:
     • •local .env uses OPEN_AI_KEY
     • •code expects OPENAI_API_KEY

Prevention

• •

  Fail fast on startup if required secrets are missing.

  if (!process.env.OPENAI_API_KEY) throw new Error("OPENAI_API_KEY missing");
  

• •

  Keep provider-specific config explicit.

  • •Don’t reuse one generic key name across OpenAI, Azure OpenAI, Anthropic, and Bedrock unless your wrapper maps them correctly.
• •

  Add a deployment smoke test.

  • •Run one authenticated LangChain call after deploy so broken secrets fail immediately instead of during customer traffic.

If you want the shortest path to resolution: check the exact env var name first, then verify whether you’re using ChatOpenAI vs AzureChatOpenAI, then confirm production actually has the secret at runtime. In most cases, that’s where "authentication failed in production" comes from.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.