You’re running into a mismatch between ODC’s own authentication session and the Entra ID flow, and the fact you’re centralizing everything in an Authenticator app makes OS‑CLRT‑40102 much easier to hit.

Below I’ll focus on the practical side: how to structure the flow in ODC, and what you can still try given the restrictions of the platform.

1. What OS‑CLRT‑40102 is telling you in ODC

The message:

Error performing authentication action because a user is already authenticated via a different mechanism. To proceed, a logout is necessary.

In ODC this typically means:

• There is an authenticated ODC session associated with the current browser context.
• You’re trying to start another authentication flow (via GetExternalLoginURL / Entra ID) that doesn’t match the current session or is being started from an already-authenticated request.
• ODC refuses to proceed until a proper logout runs.

In a centralized SSO setup, this usually happens when:

• The Authenticator app starts an external login while it still has a valid ODC session.
• Or the consumer app that you’re redirecting to (Login_Testing) is still authenticated in the browser while the Authenticator is trying to initiate a new login.

2. Centralized Authenticator in ODC – important constraints

Even in ODC:

• Each application has its own session and authentication state.
• The platform expects you to start and end external auth per app via the built‑in actions (GetExternalLoginURL, GetExternalLogoutURL).

When you build a broker app (Authenticator) you are effectively:

• Calling these actions on behalf of other apps.
• Redirecting through multiple apps while ODC is trying to manage sessions per app.

This increases the chance that:

• One app thinks the user is authenticated,
• Another app tries to kick off a new login,
• ODC sees that conflict and triggers OS‑CLRT‑40102.

So the key is: make sure that no app involved in the flow is still authenticated when you call GetExternalLoginURL for a fresh login.

3. Recommended login/logout pattern in your scenario

Let’s rewrite your sequence in a way that minimizes conflicts.

Logout from consumer app (Login_Testing)

When user clicks “Logout” in Login_Testing:

1. In Login_Testing, call GetExternalLogoutURL() (the ODC‑provided action for that app).
2. Redirect the user to the returned URL.
3. Entra ID performs logout, then redirects to your configured logout return URL.
4. That logout return URL should:
   • Land either in Login_Testing or in Authenticator,
   • Immediately treat the request as non‑authenticated and not start login yet.
5. Only after the logout redirect chain is completely finished, navigate the user to the “central” Authenticator login screen (if that’s your UX).

Key point: The logout should be initiated by the app whose session you want to clear, not only by the Authenticator app.

Login from Authenticator

On the Authenticator login screen:

1. First check if Authenticator itself is authenticated:
   • If yes, perform an ODC logout for Authenticator (call GetExternalLogoutURL() in Authenticator and redirect),
   • Wait for that logout to complete and return to an unauthenticated context.
2. Once Authenticator is confirmed unauthenticated:
   • Call GetExternalLoginURL() with ReturnToURL = "https://<environment>/Login_Testing/...".
   • Redirect to the URL returned by GetExternalLoginURL.
3. Entra ID completes login and ODC will redirect to the ReturnToURL (Login_Testing).
4. Login_Testing receives an authenticated user and routes to its entry screen.

The critical rule: Never call GetExternalLoginURL from an authenticated request (in any app that participates in the flow).

4. Why your current retry flow still ends up at _error.html

Your custom “Login → Logout → Login retry” logic is conceptually correct, but OS‑CLRT‑40102 means logout is not happening from the perspective of the platform:

Typical pitfalls:

• Logout only in Authenticator
  Login_Testing’s session persists, so when you re‑enter Login_Testing via ReturnToURL, ODC sees a valid session and treats the attempt to start a new external login as conflicting.

• ReturnToURL re‑introduces an authenticated app
  If you preserve and reuse a ReturnToURL that points to a screen in Login_Testing while Login_Testing is still authenticated, the “next login” attempt is not really clean.

• Multiple tabs/windows
  Another tab with Login_Testing or another ODC app can keep a session, and any cross‑app redirect chain can then hit OS‑CLRT‑40102 when you restart login from Authenticator.

• Starting login inside error handling
  If your OS‑CLRT‑40102 handling is executed in the same request that is still treated as authenticated, calling GetExternalLoginURL there will again see a conflicting session.

5. Clearing conflicting ODC sessions – what is and isn’t possible

In ODC, you don’t have a “force purge all sessions” API.

You have:

• The platform’s logout actions (GetExternalLogoutURL followed by redirect), which:
  • Clear server-side session state for the app,
  • Reset cookies/tokens appropriately for that app.

To fully clear conflicts in a centralized SSO scenario, you need to:

1. Ensure each app (Authenticator and all consumer apps) uses GetExternalLogoutURL when you want its session gone.
2. Avoid calling GetExternalLoginURL in any app while that app is authenticated.
3. Avoid combining this with custom cookie logic or manual session hacks – those can put the platform in an undefined state that leads to OS‑CLRT‑40102.

6. Handling _error.html as a recovery point

Right now _error.html is a dead end. You can turn it into a recovery step:

• On _error.html, instead of only showing the error:

  1. Log the error and capture:
     • Current URL,
     • Any query parameters,
     • Whether the request is authenticated (using your server-side logic).
  2. Immediately redirect to a “hub” screen in Authenticator, e.g. /Authenticator/AuthHub.

• On AuthHub:

  1. Check if the current request is authenticated in Authenticator.
     • If yes, perform GetExternalLogoutURL in Authenticator and redirect.
     • After redirect back to AuthHub (now unauthenticated), proceed.
  2. Only when Authenticator sees the user as unauthenticated:
     • Start a clean login:
       • Call GetExternalLoginURL(ReturnToURL = OriginalTargetAppURL)
       • Redirect to the returned URL.

This way, any error or inconsistent state is funneled into a deterministic hub screen that always forces a logout first, then a fresh login.

Conceptually this is similar to the “unified login” app approach that OutSystems recommends for multiple apps with shared authentication. Use the same login for multiple apps

7. What you can still log to understand the conflict

You already added logging and exception handling, which is great. Given OS‑CLRT‑40102 is about existing sessions, I’d add:

• Before any call to GetExternalLoginURL or GetExternalLogoutURL:

  • Log:
    • App name (Authenticator vs Login_Testing),
    • Whether your logic considers the user authenticated,
    • The URL you’re about to use as ReturnToURL.

• On _error.html:

  • Log:
    • The full path (/Authenticator/_error.html),
    • Any query string parameters,
    • Whether your logic sees a current user/session.

• Compare logs between Authenticator and Login_Testing:

  • For the same user and timestamp, verify:
    • Did Login_Testing logout complete before Authenticator started a new login?
    • Were there any requests where Authenticator called GetExternalLoginURL while your logs say “user is authenticated”?

If after you align the flow as above you still consistently see OS‑CLRT‑40102, that strongly suggests a platform-level edge case, and at that point it’s worth opening a Support case with the exact redirect sequence and your logs.

8. Direct answers to your specific questions

Has anyone encountered OS‑CLRT‑40102 in an ODC + Entra ID setup with a centralized SSO application?

Yes, it’s a typical symptom in setups where:

• A central app starts external login,
• But one of the other apps in the browser context is still authenticated, or
• Login is triggered from an authenticated request.

Is there an officially recommended way to completely clear conflicting ODC authentication sessions before invoking GetExternalLoginURL?

Within one app: use only the platform logout (GetExternalLogoutURL + redirect), then start login from an unauthenticated request.
Across several apps: you need to ensure each participating app uses platform logout before starting a fresh centralized login flow. There’s no global “kill all sessions” API.

Are there known issues with GetExternalLogoutURL not fully clearing session state in certain scenarios?

The typical issues are not that GetExternalLogoutURL fails, but that:

• It’s called from only one app while others remain authenticated,
• Or custom logic (manual cookies, extra redirects) interferes with the platform’s expected flow.

What is the recommended login/logout sequence for ODC apps using a shared authentication broker application?

In short:

1. Logout:
   • Always from the app being logged out (consumer app first).
   • Broker app (Authenticator) also logs out if it has its own session.
2. Only after all relevant apps are logged out:
   • Broker app, from an unauthenticated request, calls GetExternalLoginURL and uses ReturnToURL to send the user to the consumer app.

Any additional logging/monitoring or configuration to see why the user lands on _error.html after the recovery flow?

• Instrument _error.html and your Authenticator hub screen heavily:
  • Log auth status, app, ReturnToURL, and the sequence of redirects.
• Correlate those with your logout and login attempts.
• If the pattern shows “login called from an authenticated request” even once, that’s the likely trigger for OS‑CLRT‑40102.

If you’re able to outline your exact redirect chain (who calls which action, with which ReturnToURL, in order), I can help you reshape it into a minimal sequence that avoids the conflicting state and OS‑CLRT‑40102.

You’ve essentially debugged the root cause already: in your Authenticator app, the fallback path in the login exception handler is using the app ReturnToURL (Login_Testing) instead of an IdP URL, and because that URL is not a screen of Authenticator, ODC sends you to Authenticator/_error.html.

Let me break it down and then suggest a concrete fix for your flow.

What’s happening step‑by‑step

Your sequence:

1. User opens Login_Testing.
2. Login_Testing redirects to Authenticator (central login broker).
3. Login_Testing passes its own screen path as ReturnToURL (e.g. https://<env>/Login_Testing/...).
4. Authenticator builds something like:
   https://<env>/Authenticator/Login?ReturnToURL=<encoded Login_Testing URL>.
5. Authenticator’s Login screen OnReady calls GetDefaultExternalLoginURL (ODC’s action that returns the Entra ID login URL).
6. GetDefaultExternalLoginURL fails (network / config / session conflict, etc.).
7. Your exception handler falls back to ReturnToURL.
   • At this point, ReturnToURL = Login_Testing URL, not the IdP URL.
8. The platform sees that you’re still in the Authenticator app, and you’re trying to navigate to a relative path /Login_Testing/ that doesn’t exist as a screen in Authenticator, so ODC displays Authenticator/_error.html.

This fallback behavior is very similar to what happens in classic OnException flows when people redirect to the wrong place and land in a loop or in another app’s login instead of their own. Remove login screen

How to fix the flow

You need to separate clearly:

• IdP URL (from GetDefaultExternalLoginURL)
• App ReturnToURL (Login_Testing URL)

…and never use ReturnToURL as a fallback when IdP login fails.

1. Change the exception handling on Authenticator/Login

On the Authenticator login screen’s OnReady:

Current (problematic) pattern (simplified):

Try
    IdpUrl = GetDefaultExternalLoginURL()
    RedirectToURL(IdpUrl)
Catch
    // Fallback
    RedirectToURL(ReturnToURL)
End

Recommended pattern:

• Treat IdP failures as authentication errors, not “go back to target app”.

Try
    IdpUrl = GetDefaultExternalLoginURL()
    RedirectToURL(IdpUrl)
Catch SecurityException or AuthenticationException
    // 1. Log details
    // 2. Redirect to a dedicated error / recovery screen in Authenticator
    RedirectToURL(GetEntryURL(AuthErrorScreen))
Catch AllOtherExceptions
    // Same: log + error screen, NOT ReturnToURL
    RedirectToURL(GetEntryURL(AuthErrorScreen))
End

On AuthErrorScreen (in Authenticator):

• Show a message like: “SSO authentication failed. Please try again or contact support.”
• Optionally expose a “Retry Login” button that:
  • Calls GetDefaultExternalLoginURL again from a clean, unauthenticated context;
  • Or, if needed, first calls GetExternalLogoutURL for Authenticator, then restarts the login flow.

This is conceptually the same advice given for SSO exceptions in the classic platform: you send the user to a dedicated error screen, not back to the original page, to avoid loops and confusion. Remove login screen

2. Preserve ReturnToURL separately

You still need ReturnToURL (= Login_Testing URL) to know where to send the user after IdP login succeeds, but it should not be used when IdP login fails.

Pattern:

• Maintain a client variable or input parameter for ReturnToURL in Authenticator.
• Use it only:
  • When building the GetExternalLoginURL request that will be sent to the IdP.
  • When redirecting the user after successful authentication.

Do not use ReturnToURL in:

• Exception handlers for GetDefaultExternalLoginURL,
• Internal error flows in Authenticator (OnException, error.html, etc.).

Using a dedicated client variable to store the post-login URL is similar to how OutSystems templates handle post-login navigation in reactive apps (store target URL in client state and use it after login). Redirect to correct link from Email after login

Relation to OS‑CLRT‑40102

In your broader scenario, OS‑CLRT‑40102:

“Error performing authentication action because a user is already authenticated via a different mechanism. To proceed, a logout is necessary.”

is about conflicting session state when starting a new external login. Fixing your exception handling won’t by itself clear sessions, but it will:

• Stop sending users to invalid URLs (like treating ReturnToURL as if it were an IdP URL),
• Prevent _error.html from being the default “fallback”, and instead funnel errors to a recoverable screen.

Combined with a careful login/logout sequence (per app, as discussed before), this should significantly reduce the inconsistent states that cause both OS‑CLRT‑40102 and _error.html redirects.

Practical summary for your Authenticator app

1. OnReady of Login screen:

   • Call GetDefaultExternalLoginURL.
   • On success: redirect to IdP URL.
   • On failure: redirect to AuthErrorScreen; don’t use ReturnToURL.

2. AuthErrorScreen (Authenticator):

   • Show error, log details.
   • Optional: “Retry” that:
     • Ensures Authenticator is logged out if necessary (GetExternalLogoutURL),
     • Calls GetDefaultExternalLoginURL again from a clean context.

3. ReturnToURL handling:

   • Only used to:
     • Build the external login URL (GetExternalLoginURL(ReturnToURL = Login_Testing URL)),
     • Redirect after successful login.
   • Never used as a fallback navigation for failed IdP calls.

If you adjust the exception handling like this, the platform won’t try to resolve /Login_Testing/ as a screen in Authenticator, and your users should stop landing in Authenticator/_error.html for this specific case.