Entra External ID SSO issue: AADSTS700056 on repeat sign-in when ESTSAUTHPERSISTENT cookie exists

Question

Entra External ID SSO issue: AADSTS700056 on repeat sign-in when ESTSAUTHPERSISTENT cookie exists

Yuliia Bashko 80

Hello Support Team,

We are seeing a repeatable sign-in issue in our Entra External ID / MSAL browser flow.

Problem summary

A user can sign in successfully on the first attempt. After logout, the same user may fail on the next sign-in attempt with:

AADSTS700056: User account does not exist in organization

This happens only when the Entra SSO cookie ESTSAUTHPERSISTENT is still present in the browser.

When the browser cookies are cleared, the same user can sign in successfully again.

Environment

Authentication library: @azure/msal-browser 2.38.1
Redirect flow used
Custom login domain is used
Tenant/policy path in requests: .../***.onmicrosoft.com/oauth2/v2.0/...

Repro steps

User signs in successfully.
User logs out from the SPA using msalInstance.logoutRedirect(...).
Browser still contains Entra SSO cookie ESTSAUTHPERSISTENT.
User starts sign-in again in the same browser session.
Sign-in fails with: AADSTS700056: User account does not exist in organization

Important observations

1. Clean browser cookies make the problem disappear

If we remove Entra cookies and retry, the same user is allowed in successfully.

2. `prompt: "login"` works

If we force login with:

prompt: "login"

the repeat sign-in succeeds.

3. `prompt: "select_account"` does not work reliably

If we use:

prompt: "select_account"

the issue still occurs.

This suggests the problem is related to SSO session reuse, not the user's actual eligibility.

4. The same user and same tenant are used

This is not a case where the user intentionally changes account or tenant between attempts.

Expected behavior

If the same user signs out and then signs in again, or signs into another app in the same tenant/browser session, Entra should not incorrectly resolve the user into a context that leads to:

AADSTS700056: User account does not exist in organization

especially when the same user can sign in successfully after clearing cookies or using prompt=login.
Our question

Can you confirm whether this is a known Entra External ID / SSO session reuse issue with persisted cookies such as ESTSAUTHPERSISTENT, especially when using:

custom login domain
multiple apps in the same tenant
prompt=select_account
MSAL browser redirect flow

We would also like guidance on:

why prompt=select_account reuses an invalid identity/session context,
why prompt=login consistently works,
whether logoutsession returning postLogoutRedirectUriValid=0 is related,
how to ensure server-side sign-out fully clears the Entra session for the intended account.

Thank you.

Our question

Can you confirm whether this is a known Entra External ID / SSO session reuse issue with persisted cookies such as ESTSAUTHPERSISTENT, especially when using:

custom login domain
multiple apps in the same tenant
prompt=select_account
MSAL browser redirect flow

We would also like guidance on:

why prompt=select_account reuses an invalid identity/session context,
why prompt=login consistently works,
whether logoutsession returning postLogoutRedirectUriValid=0 is related,
how to ensure server-side sign-out fully clears the Entra session for the intended account.

Thank you.

Shubham Sharma 13,000 Reputation points Microsoft External Staff Moderator

2026-04-06T15:58:10.7633333+00:00
Hello Yuliia Bashko

Thank you for reaching out to Microsoft Q&A.

It looks like what you’re running into is a known SSO session‐reuse quirk when the ESTSAUTHPERSISTENT cookie is still present. Here’s the short version of what’s happening and how to work around it:

Why prompt=select_account still fails • prompt=select_account only tells Azure AD to show you the account picker, it does not force the STS to drop its existing SSO cookie. • Because ESTSAUTHPERSISTENT is still around, the STS reuses the old (and now invalid) session context and ends up resolving a “user not found” scenario.

Why prompt=login always works • prompt=login forces a “fresh” authentication (it sends forceAuthn under the covers), so the existing cookie is ignored and you get a clean sign-in flow.

postLogoutRedirectUriValid=0 and why you’re not fully signing out • That return code means the post-logout-redirect URI you passed to the end_session endpoint doesn’t match exactly one of the URIs in your app registration. • When the logout request isn’t accepted, Azure AD never deletes the ESTSAUTHPERSISTENT cookie, so your next login still reuses the stale session.

How to fully clear the Entra session on logout • Call the end_session (v2 logout) endpoint on your custom domain’s OIDC metadata (/.well-known/openid-configuration → end_session_endpoint). • Include id_token_hint from the last login and a post_logout_redirect_uri that exactly matches one registered in your app. • Once that succeeds, ESTSAUTHPERSISTENT will be removed and subsequent logins will behave normally (even without prompt=login).

Workarounds and next steps

Short term: keep using prompt=login or manually clear cookies after logout.

Medium term: make sure your custom login domain’s metadata and your app’s logout URIs are in sync so the end_session call can clear the SSO cookie.

Longer term: we have a bug logged against this behavior (2502270050002440) and a fix is targeted for an upcoming release.

If you need to dig deeper, grab a HAR/Fiddler trace around your logout call or share the exact end_session_endpoint + parameters you’re using. Also, the CIAM data-collection guide can help you pull detailed STS logs:

https://supportability.visualstudio.com/AzureAD/_wiki/wikis/AzureAD/1293072/Entra-External-ID-for-Customers-(CIAM)-Data-Collection

Hope this helps! Let me know if you have any questions .

Reference list

• Known Issue with Entra External ID Login (internal bug ID 2502270050002440)

• Entra External ID for Customers (CIAM) Data Collection

https://supportability.visualstudio.com/AzureAD/_wiki/wikis/AzureAD/1293072/GeneralPages/AAD/AAD%20Account%20Management/Microsoft%20Entra%20External%20ID%20(CIAM)/Entra%20External%20ID%20for%20Customers%20(CIAM)%20Data%20Collection
Yuliia Bashko 80 Reputation points

2026-04-07T10:05:13.0033333+00:00
Hi @Shubham Sharma
Thank you for the quick response.

There is no sense STS reuses the old, as when I log in using a clean browser (no ESTSAUTHPERSISTENT cookies) - first login is always successful. Second login (after 5 min from first login) - failing. Even if it reuses the previous session, the session should be ok.

I double-check it, and the post-logout-redirect URI I passed to the end_session endpoint matches exactly one of the URIs in my app registration.

Could you please start a private conversation so I can share end_session_endpoint + parameters?
Shubham Sharma 13,000 Reputation points Microsoft External Staff Moderator

2026-04-08T14:31:41.6733333+00:00
Yuliia Bashko

Thank you for your reply.

What is actually happening

1. ESTSAUTHPERSISTENT is not just a session cookie

Microsoft documents that Entra ID uses multiple cookies to reconstruct sign‑in context, including home realm, policy, and user type (external/local).

For External ID (CIAM), this context is policy-bound.

When ESTSAUTHPERSISTENT exists, the STS attempts silent account resolution before policy evaluation 🔹 If the reconstructed context does not exactly match:

policy

login domain

user type

tenant boundary

the STS fails early, before interactive resolution, resulting in:

AADSTS700056 – User account does not exist

This happens even though the account exists.

➡ This explains why:

First login ->true

Second login (same user, same browser) ->false

Why this ONLY happens with External ID (CIAM)

External ID tenants use separate identity resolution paths than workforce tenants.

User resolution in External ID for customers relies on policy‑driven evaluation and identity context stored in cookies.

Why prompt=select_account does NOT fix it

Microsoft documents the difference clearly:

prompt=select_account

Shows an account picker only if needed

Does not clear or ignore SSO cookies

Still allows silent sign‑in optimization

prompt parameter behavior

https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow#request-an-authorization-code

So if ESTSAUTHPERSISTENT exists, Azure AD:

Attempts silent resolution

Pulls an invalid CIAM user context

Fails before the picker becomes useful

Why prompt=login ALWAYS works

prompt=login forces reauthentication and ignores existing cookies and SSO session state.

This:

Bypasses ESTSAUTHPERSISTENT

Forces full policy + user evaluation

Correctly recreates the session

About logout and postLogoutRedirectUriValid=0

If the post_logout_redirect_uri does not exactly match a registered value, sign‑out becomes best‑effort and cookies may persist.

OIDC Logout behavior

https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc#send-a-sign-out-request

Even one of the following causes cookie retentions:

Wrong domain (custom vs default)

Scheme mismatch (https vs http)

Trailing slash difference

App registration mismatch between SPA and CIAM policy

This aligns with:

ESTSAUTHPERSISTENT surviving logout

Next login reusing broken context

Below is the resolution:-

Use one of the following:

prompt: "login"

OR explicitly redirect to:

https://<custom-domain>/<tenant>/oauth2/v2.0/logout

with:

id_token_hint

exact post_logout_redirect_uri

Use one login domain consistently

Avoid mixing default + custom domains

Use one CIAM policy per app where possible
Shubham Sharma 13,000 Reputation points Microsoft External Staff Moderator

2026-04-10T10:31:50.6466667+00:00

Yuliia Bashko

Following up to check if the resolution provided was helpful. Please let us know if you need any further assistance.

1 answer

Your answer

Yuliia Bashko 80 Reputation points

2026-04-07T10:05:13.0033333+00:00

Hi @Shubham Sharma
Thank you for the quick response.

There is no sense STS reuses the old, as when I log in using a clean browser (no ESTSAUTHPERSISTENT cookies) - first login is always successful. Second login (after 5 min from first login) - failing. Even if it reuses the previous session, the session should be ok.

I double-check it, and the post-logout-redirect URI I passed to the end_session endpoint matches exactly one of the URIs in my app registration.

Could you please start a private conversation so I can share end_session_endpoint + parameters?
Shubham Sharma 13,000 Reputation points Microsoft External Staff Moderator

2026-04-10T10:31:50.6466667+00:00

Yuliia Bashko

Following up to check if the resolution provided was helpful. Please let us know if you need any further assistance.

Answer 1

Yutaka_K_JP 1,655

I think it’s just External ID stickin u to a stale ESTSAUTHPERSISTENT home‑realm hop, so the STS drops u in the wrong tenant. Try one clean prompt=login or wipe that cookie, and if it still loops check the end_session redirect chain.

0 comments

Share via

Entra External ID SSO issue: AADSTS700056 on repeat sign-in when ESTSAUTHPERSISTENT cookie exists

Problem summary

Important observations

1. Clean browser cookies make the problem disappear

2. prompt: "login" works

3. prompt: "select_account" does not work reliably

4. The same user and same tenant are used

Expected behavior

Our question

1 answer

Your answer

2. `prompt: "login"` works

3. `prompt: "select_account"` does not work reliably