Unreal Engine EOS Login Failed InvalidAuth - Client Credentials and Sandbox Config Fix - How to Fix

Problem: Unreal Engine login through Epic Online Services (EOS) fails with InvalidAuth, errors.com.epicgames.common.authentication.authentication_failed, or similar auth-denied responses in editor, test builds, or CI-driven packaged runs.

Common signs:

Login works on one machine but fails on another with the same account
Dev environment login succeeds but staging or shipping fails
EOS overlay appears, but token exchange fails after account selection
Logs show sandbox or deployment mismatch around auth initialization

This usually means your credentials and environment mapping do not point to the same EOS product context.

Root cause

In most Unreal EOS projects, InvalidAuth comes from one of these:

Wrong Client ID / Client Secret pair for the active environment
Incorrect Sandbox ID or Deployment ID in config
Build using one EOS environment while backend expects another
Outdated secrets in CI or per-user local environment variables
Product settings changed in Epic Developer Portal but project config was not updated

In short: EOS auth fails when token request context and configured product credentials are out of sync.

Quick fix checklist

Verify Client ID and Client Secret are from the same EOS application entry.
Confirm Sandbox ID and Deployment ID match your intended environment.
Ensure Unreal config, CI secrets, and backend auth validation target the same environment.
Clear stale local credential caches and retry login with verbose EOS logs enabled.
Run one deterministic login smoke test in editor and packaged build.

Step 1 - Validate EOS credentials in Epic Developer Portal

Open the EOS product in Epic Developer Portal and inspect your auth application.

Check:

Client ID and Client Secret belong to the same client.
Client policy includes needed auth scopes for your login flow.
Secret rotation did not invalidate credentials currently stored in Unreal project or CI.
You copied full values without hidden trailing spaces or truncated characters.

If secrets were rotated recently, treat all old stored values as invalid and update every environment source.

Step 2 - Verify Sandbox and Deployment mapping

InvalidAuth is common when sandbox/deployment values drift.

Validate:

Project is pointed at the expected Sandbox ID (for example dev vs stage vs live).
Deployment ID belongs to that same sandbox.
Backend session/token validation is not hardcoded to a different deployment.
Any launch argument or build profile override does not silently switch environment.

Use one source-of-truth environment matrix and compare Unreal config against it line by line.

Step 3 - Audit Unreal EOS config sources

Search your project config and runtime setup paths where EOS credentials and environment are provided.

Typical drift points:

DefaultEngine.ini vs platform-specific ini overrides
Local developer env vars vs CI secret variables
Build pipeline injecting stale values at package time
Test harness using legacy client credentials

Keep credentials out of source where possible, but ensure each environment has a clear, versioned mapping document.

Step 4 - Re-test auth with deterministic logging

Run a controlled retry:

Enable EOS verbose logging in a non-production test environment.
Start with editor login and capture full auth sequence logs.
Run the same account flow in packaged build for your target platform.
Compare client, sandbox, and deployment values in both runs.

If editor works but packaged fails, treat this as build-time config injection drift, not an EOS outage.

Step 5 - Confirm fix with a repeatable smoke route

Use this exact verification path:

Fresh launch with cleared local auth cache/session.
EOS login attempt with known valid test account.
Session creation or presence check immediately after login.
Logout and second login pass to confirm token refresh path.

Only mark the issue resolved after two consecutive clean runs on the same target route.

Alternative fixes

If login fails only in CI-produced builds

Compare CI-injected secrets with local known-good values and confirm build job is reading the intended secret scope (project vs org vs environment).

If login fails after secret rotation

Invalidate old credential artifacts, update secret stores, redeploy backend auth services, and rerun packaged smoke tests.

If only one platform fails

Check platform-specific config overrides and ensure that platform build profile does not pin older Sandbox or Deployment IDs.

Prevention tips

Keep a single EOS environment matrix (client, sandbox, deployment, backend endpoint) in release docs.
Require a post-rotation auth smoke test whenever Client Secret changes.
Add CI preflight checks that fail build when required EOS variables are missing.
Keep editor and packaged login checks in release readiness criteria.

FAQ

Why does EOS login work in editor but fail in packaged build

Packaged builds often use different config merge paths and secret injection. That can point auth to a different sandbox or stale client secret.

Can InvalidAuth happen even when credentials are correct

Yes. Correct credentials can still fail if Sandbox ID or Deployment ID is wrong for that credential pair.

Should we rotate Client Secret immediately after an auth incident

Rotate only if exposure risk exists. First confirm whether this is a config mismatch, then rotate in a controlled window with full environment updates.