We’ve root-caused why our Forge app (Custom UI + Forge Remote) shows an endless loading screen whenever a site admin uses “Log in as user” — and we believe it affects every Forge app rendered in an impersonated session. Filed as ECOHELP-139577; posting here for community visibility
Symptom
Admin uses “Log in as user”→ opens a Forge module . Use Forge App.. In DevTools, every invokeExtension (useInvokeExtensionRelayMutation) fails with:
{
"message": "Failed to validate FCT: 'accountId' claim mismatch",
"extensions": { "errorType": "FCT_VALIDATION_CLAIM_MISMATCH", "statusCode": 400 }
}
The app’s backend is never invoked — the rejection happens entirely inside Atlassian’s gateway, so vendors see nothing in their logs. Direct login as the same customer works perfectly.
Root cause (verified by decoding both sides)
-
The session cookie (
tenant.session.token, decoded) knows both identities — during impersonation it containssub: <admin's accountId>plus animpersonation: [{ "aaId": "<users accountId>", … }]entry. There’s even a cleartextum.user.impersonated.userid=<user>cookie. -
FCT minting honors the impersonation: the
contextTokensent withinvokeExtension(decode its middle JWT segment) carriesaccountId: <users accountId>. -
FCT validation apparently resolves the session to the raw
sub— the admin — compares it with the FCT’saccountId(the user), and rejects.
Mint says user; validate says admin; these always differ under impersonation → 100% of Forge invocations in a “Log in as User” session fail, deterministically.
Asks for Atlassian
-
Make FCT minting and FCT validation resolve the impersonated session to the same identity, so Forge apps work under “Log in as User”.
-
If impersonation is intentionally unsupported for Forge apps: document it.
Has anyone else hit FCT_VALIDATION_CLAIM_MISMATCH this way?