API Server Web Portal Troubleshooting (4382867)

Users may be redirected back to the login page, receive session-expired or unauthorized errors, fail SSO after a successful identity provider redirect, or experience inconsistent behavior across API servers.

Here are some things to look for and try when troubleshooting API server login issues:

1) Login loops

Typical causes

• Browser is not accepting cookies.
• CSRF/XSRF cookie is not being stored or returned.
• SameSite behavior prevents the browser from sending cookies after cross-site authentication.
• Load balancer sends follow-up requests to a different API server.
• SSO is enabled, but IIS/authentication mode is misaligned.

What to check

• Open browser developer tools and confirm that session and XSRF cookies are actually being set.
• Confirm the browser sends the XSRF token header expected by the API Server.
• Verify the API Server cookie path and domain settings match the deployed URL.
• If the environment uses a reverse proxy or alternate host name, confirm the portal is always accessed through the same external URL.
• If multiple API servers exist, confirm the same user stays on the same server during the session.

Practical guidance

• Clear site cookies and test again.
• Test from a clean browser profile or incognito session.
• Verify the CSRF/XSRF cookie configuration in the Administration Portal.
• Review SameSite configuration if the login flow includes an identity provider redirect.
• If load balancing is used, enable sticky sessions and retest.

2) Session expiration and repeated reauthentication
The platform uses session cookies and security tokens to restore or continue a session. If those cookies are missing, reset, or routed to a different server context, users can be forced to log in again.

Check these configuration settings on the API Servers Administration Portal

• Session timeout (SessionTimeout): default 1.00:00:30
• Persistent authentication tokens (AuthTokensEnabled)
• Persistent authentication token lifetime in minutes (AuthTokensLifetimeMinutes)

What to check

• Whether the timeout behavior matches the current configuration.
• Whether the browser or endpoint security tools clear cookies at close or on idle.
• Whether a proxy/load balancer is changing affinity mid-session.
• Whether users expect browser-close persistence but persistent authentication tokens are disabled or too short-lived.

Practical guidance

• If users are logged out too aggressively after browser restarts, review persistent authentication token settings.
• If users are logged out during active use, review session timeout values and any infrastructure behavior that breaks affinity.
• If REST/API clients use bearer-token authentication, ensure they also preserve the assigned session cookie across subsequent requests; otherwise a new session is created repeatedly.

3) SSO issues Active Directory / Windows SSO

What to check

• IIS is configured for Windows authentication if SSO is intended.
• If SSO is not intended, do not force Windows authentication.
• SPNs are configured correctly for the host serving the Web Portal.
• If the API Server connects through an application server, SPNs may be needed for both the API Server and the application server.
• The user can be resolved to the expected identity and has permission to use the database.

Practical guidance

• Confirm that anonymous authentication is turned off in IIS
• Confirm that the site is added to the Local Intranet zone within Internet Options
• Check SPNs, see Microsoft Learn Article

4) OAuth 2.0 / OpenID Connect

What to check

• The correct OAuth/OpenID Connect authentication module is enabled.
• Only the intended OAuth/OpenID Connect module is enabled.
• The identity provider redirect URI and application configuration match the deployed portal URL.
• The API Server trusts the identity provider certificate chain.
• The token presented to the application is valid and not expired.

Practical guidance

• Recheck the identity provider configuration and redirect URL for the specific portal/app entry.
• Confirm the required CA/root/intermediate certificates are installed on the API Server.
• Retest after confirming certificate trust on the API Server host.

5) SameSite and cookie behavior
SameSite cookie policy is a frequent cause of login loops after external authentication or cross-site redirects.

Why it matters

If SameSite is too restrictive for the login flow, the browser may refuse to send the session or XSRF cookie after redirect. The result is usually a fresh login prompt, session mismatch, or failed post-login request.

What to check

• The SameSite cookie setting on the API Server API project.
• Whether the issue appears only in certain browsers or after browser updates.
• Whether the sign-in flow includes an external identity provider, reverse proxy, or hostname transition.

Practical guidance

• If the issue started after a browser policy change or identity-provider redirect change, review SameSite first.
• Keep the portal URL consistent from the user’s first request through the full authentication round-trip.
• If cookies are set for the wrong domain or path, correct the cookie path/domain settings and retest.

6) CSRF/XSRF protection and cookie path/domain settings
The API Server issues an XSRF-TOKEN cookie and expects the client to send the token value back in the X-XSRF-TOKEN header. If the header is missing, requests can fail with 400.

Check these settings on the API Servers Administration Portal

• XsrfProtectionCookieName
• XsrfProtectionCookiePath
• XsrfProtectionCookieDomain

Practical guidance

• Make sure the cookie domain matches the hostname users actually browse.
• Make sure the cookie path matches the application path in the requested URL.
• Avoid changing these values unless there is a clear deployment reason.
• If the browser reports an incorrect CSRF protection cookie, confirm the browser is accepting the cookies sent by the portal.

7) API server affinity and load balancing
Load balancing can cause login loops and session instability when session restoration is possible but requests bounce between servers.

Required conditions

All API Servers in the load-balanced pool must use the same session token certificate and load balancing should support sticky sessions / session bindings.

Practical guidance

• Verify the same session token certificate is installed across all API Servers in the pool.
• Verify the load balancer keeps all requests from the same session on the same API Server.
• If troubleshooting an intermittent issue, temporarily bypass the load balancer and test directly against one API Server.