Troubleshooting Ignition Perspective Logout Redirect Issues

The system.perspective.logout function in Inductive Automation's Ignition Perspective module is the standard mechanism for terminating a user session. A common field problem, tracked internally as FEATURE-12767 / FEATURE-14002, is that when a logout action is chained with a navigation action, the second navigation's browser redirect "wins" the race against the logout handshake, so the SAML/IdP session cookie is never cleared and the next launch of the project silently signs the previous user back in. This reference explains the underlying redirect flow, why the race exists, the workarounds available in current 8.1.x code, and how to verify a proper logout.

1. Problem Description

Symptom observed on Perspective Sessions (project session bound to a browser tab):

• User clicks a button wired to onClick → Logout + Navigate.
• Browser URL changes to the configured target, but the Ignition gateway session, the IdP session, or both remain active.
• Subsequent access to the project URL bypasses the credential prompt and drops the user directly into the running project.
• If the navigation action is removed and only the Logout action remains, the credential prompt reappears on next launch — confirming the navigation step is what suppresses the IdP challenge.

2. Root Cause: Redirect Race Condition

The Perspective Logout component action (or the equivalent system.perspective.logout() script function) is implemented as a client-side window.location redirect to a gateway-managed logout route. The route is responsible for:

1. Invalidating the Perspective session token on the gateway.
2. Checking the project-level IdP configuration for a Single Logout (SLO) callback.
3. If an IdP logout callback is configured, redirecting the browser to the IdP's logout endpoint (e.g. the SAML SLO URL, the OIDC end_session_endpoint, or the Azure AD logout URL).
4. On completion, returning the browser to the originating project/page URL.

A subsequent Navigate action or system.perspective.navigate(url="...") also issues a window.location assignment. Because both events fire from the same onClick handler, the JavaScript event loop schedules two competing location assignments. The browser honors whichever location change resolves last, which in practice is the user's target URL — bypassing steps 2 and 3 entirely. The gateway never sees a chance to revoke the IdP token, so the cookie set by the IdP (e.g. __Host-azure-auth-session, JSESSIONID, Okta session cookie) is still valid when the user next visits the project.

For reference, the documented contract for the logout call is:

Source: system.perspective.logout — Ignition 8.1 User Manual.

3. Affected Versions and Configurations

4. Solution A — Recommended Workaround (Pre-SLO)

Until the SLO enhancement tracked under FEATURE-12767 ships in a stable build you are running, the cleanest workaround is to remove the navigation step from the button entirely and rely on the gateway's built-in post-logout redirect behavior. Configure the destination directly on the IdP or the project's login settings.

4.1 Configure the post-logout destination

1. Open the Perspective project in the Designer.
2. Navigate to Project → Properties → Perspective → Identity Provider.
3. If using the bundled Ignition IdP, the logout callback is wired automatically; you only need to set the default landing page on the IdP itself.
4. If using an external IdP (Azure AD, Okta, ADFS, Keycloak, Auth0, etc.), configure the IdP's post-logout redirect URI to point to the desired landing URL — not to the project URL.

4.2 Simplify the button to a single action

Replace the two-step onClick handler with a single Logout action, or call system.perspective.logout() from a single Script action. Do not chain a Navigate after it.

// Button onClick → Script
system.perspective.logout()
// Do NOT call system.perspective.navigate() after this line.

The gateway will then perform the full handshake and return the browser to a URL where the credential prompt is required. See the Login and Logout Actions video on Inductive University for the canonical binding pattern.

5. Solution B — Explicit SLO (SAML / OIDC)

For deployments using SAML 2.0 or OIDC, the long-term fix is the Single Logout callback tracked in FEATURE-12767. When shipped, it adds a configurable SLO URL to the Perspective project IdP settings so that Ignition can notify the IdP when the user has logged out. Configuration steps once available in your build:

1. In the Designer, open Project → Properties → Perspective → Identity Provider → SAML (or OIDC, depending on your auth profile).
2. Set the Single Logout Service URL (SAML) or End Session Endpoint (OIDC) provided by the IdP.
3. Whitelist the Ignition gateway callback in the IdP's allowed redirect URIs (typical pattern: https://<gateway>:<webport>/auth/logout/callback).
4. Save and commit the project. The logout flow will now clear the IdP session, not just the local Perspective session.

For background on the recommended identity-security posture in Ignition, review the Changing Your Perspective on Security webinar, which covers SLO, token lifetimes, and gateway hardening.

6. Solution C — Azure AD / MSAL Edge Case

Projects federated through Azure AD via the Microsoft Authentication Library (MSAL) can exhibit a related failure where no logout request is observed in Fiddler or browser dev tools. The reference issue and the diagnostic procedure (open Fiddler, click login, enter credentials, then clear traces and click logout) is documented in AzureAD/microsoft-authentication-library-for-js #127. Apply the same principle to a Perspective deployment:

1. Open the browser's DevTools → Network tab with "Preserve log" enabled.
2. Click the logout button.
3. Confirm that a request to /auth/logout is issued before any request to your target URL.
4. If the navigation request fires first, the navigation is winning the race and steps 1–2 of the gateway logout handshake are skipped.

7. Verification

After applying Solution A or B, validate the logout end-to-end:

1. Sign in to the Perspective project from a private/incognito window.
2. Open Diagnostics → Sessions in the Gateway Web Interface and note the active session count.
3. Click the logout button.
4. Confirm in DevTools that /auth/logout returns 302/200, and that any IdP logout endpoint is contacted.
5. Refresh Diagnostics → Sessions; the session row for the test user must be removed within a few seconds.
6. Close the browser, reopen, and navigate to the project URL. The credential prompt must appear — if the previous user is silently re-authenticated, the race is still present.

8. Troubleshooting Matrix

9. Best Practices for Logout UI Design

• Use a single Logout component action; never chain a Navigate.
• If the project must land on a specific URL after logout, configure that URL on the IdP (SLO post-logout redirect), not on the button.
• Place the logout button in a shell view that lives outside the authenticated route tree, so the user does not need a navigation event to leave restricted content.
• For kiosk / Workstation deployments, consider a periodic session-expire binding that calls system.perspective.logout() when dateDiff(now, session.props.auth.lastActivity) > configuredTimeout.
• For compliance-sensitive environments, enable gateway audit logging on the auth/logout route and export to a SIEM.

10. Security Considerations

A logout that does not terminate the IdP session is, in audit terms, a soft logout. The browser cookie persists, the IdP SSO assertion remains valid, and the next browser launch on the same machine is treated as a continuing session. For environments subject to FDA 21 CFR Part 11, IEC 62443, or similar regulations, this is a finding-class issue. Treat it as such by:

• Documenting the SLO configuration in the system's security context.
• Validating SLO behavior in the FAT/SAT scripts, not just the SAT.
• Disabling browser "remember me" / persistent session cookies at the IdP where policy permits.

The Changing Your Perspective on Security webinar covers the full posture checklist; cross-reference it for your specific threat model.

11. FAQ