Skip to content

Debugging 401 Authentication Failures

A 401 response means the server doesn't recognize the virtual user as authenticated. The test case might not be sending credentials at all, the login succeeded during recording but the session cookie isn't being replayed correctly, the session expired in the time between recording and replay, or the server expects HTTP-level authentication (Basic, Digest, NTLM, Negotiate) instead of form-based login.

For systematic debugging that gets you here, see Debugging Failed Replays. Apply the cascade rule before drilling in: 401 on transaction five is often a missing session cookie that should have been extracted from the login response at transaction two, so fix the first red transaction first.

Symptom

Visual indicators:

  • Replay View: First few transactions show green (login form loads), then red 401 appears
  • Content View: Response body shows "Please log in" or "Authentication required" message
  • Headers View: Response includes WWW-Authenticate header

Example failure sequence:

✓ GET /login (200 OK) - Login form loads successfully
✓ POST /login (302 Redirect to /dashboard) - Login appears to succeed
❌ GET /dashboard (401 Unauthorized) - Protected page rejects request

Diagnostic Steps

Step 1: Check if authentication is configured

  1. Open the test case in Test Case Editor
  2. Look for: Authentication folder in the Navigator tree (left panel)
  3. If "Authentication" folder exists: Authentication was configured. Proceed to Step 2
  4. If "Authentication" folder is missing: Authentication needs configuration. Go to Fix 1: Configure Authentication

Step 2: Identify the authentication mechanism

  1. Open Headers View for the failed 401 transaction
  2. Check Response Headers for the WWW-Authenticate header
Header value What the server wants Where to configure
WWW-Authenticate: Basic HTTP Basic authentication Basic/Form Authentication
WWW-Authenticate: Digest HTTP Digest authentication Basic/Form Authentication
WWW-Authenticate: NTLM NTLM authentication Basic/Form Authentication
WWW-Authenticate: Negotiate Kerberos / SPNEGO Basic/Form Authentication
WWW-Authenticate: Bearer OAuth 2.0 token OAuth & Bearer Tokens
(no WWW-Authenticate header) Form-based or session-based auth Proceed to Step 3

Step 3: Check session cookies

  1. Open Headers View for the login POST transaction
  2. Check Response Headers for Set-Cookie headers
  3. If you see Set-Cookie: sessionid=...: Server sent the session cookie. Proceed to Step 4.
  4. If no Set-Cookie headers: Login may have failed during recording. Verify credentials and re-record.

Step 4: Verify cookies are sent on subsequent requests

  1. Open Headers View for the failed 401 transaction
  2. Check Request Headers for the Cookie header
  3. If the session cookie is missing or stale: ASM didn't correlate it. Go to Fix 2: Re-Run ASM.
  4. If the cookie is present but the response is still 401: The session probably expired between the login and this request. Go to Fix 3: Reduce Think Time.

Solutions

Fix 1: Configure Authentication

If your application uses HTTP-level authentication and you haven't configured it on the test case, do that now. The Basic/Form Authentication and OAuth & Bearer Tokens pages walk through each mechanism. For SSO / SAML / OIDC flows, see SSO & Modern Auth, and read The Anti-Bot Reality if you're hitting MFA or CAPTCHA challenges.

Fix 2: Re-Run ASM

The session cookie is the most common case of an unconfigured dynamic field. If the cookie wasn't correlated, run the full Configure for Replay wizard (which runs ASM as page two). If hostnames are already restricted, you can re-run ASM standalone via Right-click → Configure → Application State...

After ASM, verify the session cookie has a gray background in the Fields View of the login response, and that the Cookie request header on subsequent transactions uses a "Server authentication header" datasource.

Fix 3: Reduce Think Time

If the session expired between login and the protected page, the replay's think time is longer than the server's session timeout. Either replay in Play Fast mode (zero think time) to confirm it's a timeout issue, or reduce think time on the affected pages so the replay finishes inside the timeout window.

For long load tests against short-session-timeout applications, you'll also need re-login logic in the test case so each virtual user can refresh their session mid-test.

Still Failing?

If you've configured authentication, ASM has correlated the session cookie, and the session isn't expiring, the AI assistant can compare the recorded and replayed login flows and find the specific difference:

Ask the AI

My replay is failing with 401 on the dashboard page after a successful
login. Authentication is configured. The session cookie appears to be
extracted. What else should I check?

Or return to the systematic debugging methodology and re-check the first red transaction. 401 at page five is often caused by a problem at page two.