Skip to content

Basic & Form-Based Authentication

The most common authentication method for websites is a login form on a web page. We've all seen them: enter your username and password, press the Submit button. From the standpoint of the underlying technology, this is no different from submitting any other form. Only the field names distinguish them as login or password fields; the security mechanism is implemented entirely within the web application.

The next most common form is authentication via credentials passed in HTTP message headers, what we call HTTP Authentication. This form of authentication is built into the web browser and the web server, defined by RFCs related to the HTTP specification.

From a performance testing perspective, both methods work similarly but have different implications for how Load Tester handles them during recording and replay. This guide covers both form-based login and HTTP authentication, including Basic, Digest, NTLM, and Windows Integrated Authentication.

Two Types of Basic Authentication

1. Form-Based Login

What it is: Username and password are entered on a web page and submitted by the browser, just like any other form submission.

When you'll see this:

  • Application shows a login page with username/password fields
  • Login form is part of the application's own web pages
  • Works over secure (HTTPS) or insecure (HTTP) connections

How Load Tester handles it:

  • Records the form submission like any other POST request
  • Default behavior: Replays with the same username/password used during recording
  • Customize using Datasets or the Fields View

Form Login Is Just Another Form

There's nothing special about form-based authentication from Load Tester's perspective. The username and password fields are just form fields. ASM handles correlation automatically if dynamic values are involved (like CSRF tokens).

2. HTTP Authentication

What it is: Credentials passed in HTTP headers (WWW-Authenticate and Authorization) based on HTTP specification standards.

When you'll see this:

  • Browser prompts for credentials before showing the page
  • Application uses Apache, IIS, or other web server's built-in authentication
  • Common on intranet sites, internal applications, or API endpoints

How it works: The browser and server negotiate authentication using HTTP headers, not web pages.

Understanding HTTP Authentication

HTTP Authentication includes several protocols that determine how credentials are transmitted from browser to server. From a performance testing perspective they work very similarly, but it's useful to understand the context in which they're used, especially when a developer or web admin mentions a specific protocol name.

The Three Groups of HTTP Authentication

1. Basic and Digest

Defined in: HTTP 1.0 spec (Basic) and RFC 2069 (Digest)

Commonly used on: Apache and other open-source web servers

How they differ:

  • Basic: Sends username and password as Base64-encoded text. The Base64 encoding exists to comply with HTTP protocol specifications; it was never intended to provide security. Anyone who can see the traffic can decode the credentials in seconds.
  • Digest: Encrypts the password using an MD5 hash, making it considerably more secure.

Load Tester support: ✅ Both Basic and Digest are fully supported.

2. NTLM and Negotiate

Defined in: RFC-4559

Commonly used on: Microsoft IIS web servers

How they work:

  • NTLM can be used exclusively
  • Negotiate allows the server and browser to select which scheme will be used (usually NTLM or Kerberos)
  • Modern IIS servers typically use Negotiate, which usually results in NTLM

Integrated Windows Authentication

IIS refers to NTLM/Negotiate as "Integrated Windows Authentication" in most documentation and the Windows UI. The underlying protocols still use NTLM, so we use that terminology here for consistency with HTTP headers.

Load Tester support: ✅ NTLM and NTLM via Negotiate are fully supported. Kerberos is not currently supported.

3. Proxy Authentication

Defined in: HTTP 1.1 spec

Used by: Proxy servers when access to the proxy requires authentication

How it works: Uses different headers to indicate that a proxy is requesting authentication, rather than the target server:

  • Proxy-Authenticate (instead of WWW-Authenticate)
  • Proxy-Authorization (instead of Authorization)

Protocols: May use any of the above schemes (Basic, Digest, NTLM, Negotiate) and operates in the same manner.

Load Tester support: ✅ Proxy authentication is fully supported.

How HTTP Authentication Works

In all HTTP authentication methods, the process begins when the browser requests a URL. If the URL requires authentication, the server returns a 401 response to the browser (or a 407 for a proxy server requesting authentication).

The Basic Authentication Flow (2 Transactions)

Step 1: Server challenges for authentication

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Protected Area"

In the WWW-Authenticate header, the server indicates:

  • Scheme: Which authentication method to use (Basic)
  • Realm: A sub-site within the website for which the credentials apply

Think of the realm as a security boundary. It allows the browser to cache credentials and automatically resend them whenever it is challenged for authentication with the same realm.

Step 2: Browser responds with credentials

After prompting the user for credentials (or fetching them from the cache), the browser responds with the same request, but with an additional Authorization header that includes the scheme and the credentials:

GET /protected/page.html HTTP/1.1
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

For the Basic scheme, the credentials are a Base64-encoded version of username:password.

After verifying the credentials, the server returns the requested content with a 200 (OK) response.

The NTLM Authentication Flow (3 Transactions)

NTLM and Negotiate are more complex than Basic authentication. They require three transactions instead of two to fetch a single URL.

Step 1: Server challenges for authentication

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Note that the server has returned two WWW-Authenticate headers, giving the browser a choice of which scheme to use. The order of the schemes implies the server's preference.

Modern browsers on Windows elect to use the Negotiate scheme. When the server is IIS and Kerberos is not configured on the workstation, the browser masquerades NTLM as the Negotiate scheme.

Step 2: Browser begins negotiation

GET /protected/page.html HTTP/1.1
Authorization: Negotiate TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==

The browser has chosen Negotiate and included some encoded information in the Authorization header. This does not yet include the credentials (username & password). The browser and server are still negotiating how the credentials will be sent.

Step 3: Server responds with negotiation details

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAADAAMADgAAAAFgooCBqqVKFrKPCMAAAAAAAAAAJYAlgBEAAAABgOAJQAAAA9JAEkAUwAwADEAAgAMAEkASQBTADAAMQABAAoASQBJAFMAMAAxAAQACgBpAGkAcwAwADEAAwAKAGkAaQBzADAAMQAHAAgAMLEcSGjLzAEAAAAA

The server responds with another 401 status and a WWW-Authenticate header that includes additional encoded information the browser can use to finally send the authentication credentials.

Step 4: Browser sends final credentials

GET /protected/page.html HTTP/1.1
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAHIAAACcAJwAigAAABIAEgBYAAAADAAMAGoAAAASABIAdgAAAAAAAAAmAQAABYKAogYBsR0AAAAPYs1k3N+dD3kPm5OJXLmqmISS+9Ao2YskTQ==

This time the Authorization header includes the actual authentication credentials. You can't tell by looking at it, but buried in that Base64 blob is an encrypted conglomeration of the username, workgroup/domain, password hash, and a few other values to improve security.

After verifying the authentication credentials, the server returns the requested content with a 200 (OK) response.

Performance Implications: Why Load Testers Should Care

It's worth pausing to consider the performance implications of HTTP authentication:

  1. Extra transactions: There is an additional transaction (or two for NTLM) required to get the web page. That implies the user will wait longer to get the web page, and the server will encounter a higher request rate under load.

  2. HTTP is stateless: Each request is independent of every other. As a result, this authentication process could happen for every request to the web server. For some methods, every JavaScript, CSS, and image request could require two full transactions to satisfy a single resource fetch.

  3. Browser optimization: If the browser is smart enough to remember that a URL is part of a particular realm, then it will not need to make the second request; it can send the credentials with the first request. It might even try to guess what realm a URL belongs to based on, for example, the path of the URL.

For any system you are testing, inspect the recording closely to determine how many additional transactions the authentication scheme is generating. If the overhead is significant, it may be worth switching to a more efficient authentication scheme.

CAN Transactions: Connection Authentication Negotiation

Load Tester uses the term "CAN transactions" for these preliminary authentication transactions.

It's tempting to simply call them "authentication transactions," but since the authentication actually happens in the final transaction, that name would be misleading. In CAN transactions, the browser and server are negotiating what protocol will be used to transmit authentication credentials for the remainder of the connection.

NTLM Requires Persistent Connections

At first glance, NTLM would have a significant performance disadvantage because of the additional transaction (and for a single URL this is true). However, NTLM and Negotiate are intended for use on modern servers that support persistent connections (indeed, they cannot work otherwise).

Under these implementations, the authentication is not for a single request (as was the case for Basic authentication), but rather for the life of the connection. Assuming that many requests will be made on a single connection, then the overhead of the Connection Authentication Negotiation (CAN) is constant: two transactions per connection.

If the connection is reused for 100 transactions, the overhead is a mere 2% of the total. In reality it is even less than that, since the 401 responses from the server have little or no content and are therefore much smaller than the average response size.

Large POST Requests

There is one other performance-related detail to note: If the first request on a connection is a POST with very large content (e.g., a file upload or a very large Viewstate), then the cost of that POST is incurred twice, since it must be re-sent along with the final request.

Recording Authentication

Recording Form-Based Login

There's nothing special about recording form-based authentication. Record your login flow normally:

  1. Start recording in your browser
  2. Navigate to the login page
  3. Enter username and password
  4. Submit the login form
  5. Continue with your test scenario
  6. Stop recording

The username and password fields are captured like any other form fields. When you run a replay, Load Tester will submit the same credentials by default.

Recording HTTP Authentication

When you record a test case that uses HTTP authentication (NTLM, Basic, etc.), you'll encounter one of two scenarios:

Scenario 1: Browser Prompts for Credentials

The browser displays a username/password prompt before showing you the page, since authentication is being performed at the HTTP layer (not in a web form).

What you'll do:

  1. Enter your credentials in the browser prompt
  2. Continue recording your scenario normally
  3. Finish recording

Scenario 2: Browser Uses Cached Credentials

For some sites (especially internal/intranet sites), the browser prompt may not appear at all. The browser may use your local account credentials or other cached credentials automatically.

What you'll see: The page loads normally without any visible authentication prompt.

What Your Recording Will Look Like

After recording HTTP authentication, your test case will show transactions with 401 Unauthorized responses. This is normal.

The "401 Unauthorized" may look strange, but it's actually how bots (such as Google's crawlers) see your page. When the server sends this response, the browser recognizes the HTTP headers as a request for credentials and displays the username/password prompt instead of showing the 401 page.

Example test case view:

1. GET /protected/page.html → 401 Unauthorized (CAN)
2. GET /protected/page.html → 401 Unauthorized (CAN)
3. GET /protected/page.html → 200 OK

The first two transactions are the CAN (Connection Authentication Negotiation) transactions. The third transaction is the successful request after authentication.

Hiding CAN Transactions

After you configure authentication (next section), Load Tester hides the CAN transactions by default to show just the business logic of your test case. You can reveal them for debugging using Test Case Editor → Properties → Show connection negotiation transactions.

Configuring Authentication for Replay

After recording, you need to configure Load Tester to provide credentials when replaying the test case. Load Tester provides an automated wizard to make this easy.

Using the Test Case Configuration Wizard

Step 1: Launch the wizard

After recording a test case with HTTP authentication, run a replay. Load Tester will automatically launch the Test Case Configuration Wizard since the test case hasn't been configured yet.

Alternatively, you can manually launch the wizard:

  • Navigate to: Tools → Wizards → Test Case Configuration Wizard

Step 2: Configure connection authentication

In the wizard, select "Configure user identity for connection authentication" to enter user identities for virtual users to use when the server requires them to authenticate.

Step 3: Choose authentication strategy

The wizard asks if the same credentials can be used for simultaneous sessions. You have two options:

Option When to Use How It Works
Use a dataset Recommended for most users Creates a spreadsheet of usernames and passwords. Each virtual user gets a unique credential from the dataset. Many servers do not behave predictably with concurrent sessions using the same credentials.
Share a username Single-user replays or environments with restricted access All virtual users use the same username/password. May work for environments where access to the server is restricted to some personnel, and the application is not aware of the environmental authentication. Can also be used to configure the test case for single-user replays with the intent of revisiting the wizard later before running a load test.

Step 4: Enter credentials

If you chose "Use a dataset":

  1. Enter usernames in the table (one per row)
  2. Enter passwords (if different from usernames)
  3. Specify domain (for Windows/NTLM authentication, format: DOMAIN\username)
  4. Press Finish

If you chose "Share a username":

  1. Enter a single username
  2. Enter password
  3. Specify domain (if using Windows/NTLM authentication)
  4. Press Finish

Ask the AI to Configure Authentication

If you're not sure whether to use a dataset or shared username:

I recorded a test case with NTLM authentication. Should I configure a
dataset with multiple usernames or share a single username for all
virtual users?

The AI can:

  • Analyze your server type and authentication method
  • Recommend dataset vs. shared username based on application behavior
  • Create the dataset for you with sample usernames
  • Explain WHY one approach is better for your scenario

After Configuration: Simplified Test Case View

After running the wizard, the Test Case Editor shows just the pages that the browser showed during recording, with the hidden 401 responses and CAN transactions tucked away.

Example simplified view:

1. GET /protected/page.html → 200 OK
2. GET /dashboard.html → 200 OK
3. POST /api/data → 200 OK

The CAN transactions are still there, but they're hidden by default to make the test case easier to read and work with.

Manual Configuration: User Identity Wizard

If you need to change authentication credentials after initial configuration, you can use the User Identity Wizard:

  1. Open the User Identity Wizard:
  2. Navigate to: Tools → Wizards → User Identity Wizard

  3. Or: Right-click test case in Navigator → Properties → User Identity tab

  4. Configure credentials:

  5. For HTTP authentication: Enter domain, username, password

  6. For form-based login: The wizard locates username/password fields and lets you specify values or link to a dataset

  7. Use datasets for load testing:

  8. Create a dataset with multiple user credentials
  9. Link the dataset to username/password fields
  10. Each virtual user will use a unique credential from the dataset

Different Credentials Per Virtual User

We recommend using different credentials for each virtual user during a load test to accurately simulate the behavior of real-world users. Use the dataset approach to provide unique credentials.

Advanced: Manual Configuration via Fields View

For advanced users, you can manually configure authentication by locating and editing fields in the Fields View:

  1. Open Fields View: Window → Show View → Fields View
  2. Locate authentication fields:
  3. HTTP authentication: Look for Authorization header fields
  4. Form login: Locate username/password fields by name (e.g., username, password, login)
  5. Change datasource:
  6. Constant value: Enter a fixed username/password
  7. Dataset: Link to a dataset column
  8. User variable: Use an extractor or dataset to populate a variable

This approach gives you complete control over authentication field configuration but requires understanding Load Tester's field correlation system.

Revealing CAN Transactions for Debugging

By default, Load Tester hides CAN transactions to keep your test case view clean. But you can reveal them for debugging purposes.

Method 1: Headers View

The Headers View always shows CAN transactions:

  1. Open Headers View: Window → Show View → Headers View
  2. Select a transaction in the Test Case Editor
  3. Headers View shows all HTTP headers, including 401 responses and CAN transactions

Method 2: Test Case Editor Properties

You can configure the Test Case Editor to show CAN transactions inline:

  1. Open Test Case Editor Properties:
  2. Test Case Editor → Edit → Properties

  3. Or: Right-click in Test Case Editor → Properties

  4. Enable "Show connection negotiation transactions"

  5. Press OK

Now the Test Case Editor expands the summarized transaction to show all three transactions in the NTLM sequence:

1. GET /protected/page.html → 401 Unauthorized (CAN - Challenge)
2. GET /protected/page.html → 401 Unauthorized (CAN - Negotiate)
3. GET /protected/page.html → 200 OK (Final authenticated request)

This is useful for diagnosing authentication issues, verifying credentials are being sent correctly, or understanding the authentication flow.

Troubleshooting Authentication Issues

Sudden 401 Errors After Security Policy Changes

Symptom: You've been running regular tests on an internal site with Integrated Windows Authentication with no difficulty. Then, an administrator runs a security tool (such as the Windows Security Configuration Wizard) and suddenly your Load Tests now fail with HTTP 401 Unauthorized responses.

What happened?

One cause of this can be a feature of NTLM security being enabled, requiring clients to support NTLMv2 "session" security. While this security feature is stronger, it is not universally supported by all clients.

Solution: Load Tester v5.4+ includes up-to-date support for stronger NTLM authentication whenever it is required by the server, without requiring any custom configuration. If you're using an older version, upgrade to the latest Load Tester.

Check Credentials First

Windows uses the HTTP 401 error message for a broad number of authentication-related issues, in addition to requiring stronger client security. If you're seeing 401 errors during a replay or Load Test, you should always check that the credentials the test is supplying are valid before investigating other causes.

Ask the AI to Diagnose 401 Errors

If replay fails with 401 Unauthorized errors:

My replay is failing with 401 errors on all transactions. I configured
NTLM authentication using the Test Case Configuration Wizard but it's
still not working. Can you help diagnose the issue?

The AI can:

  • Verify credentials are configured correctly
  • Check if authentication is being sent on the right transactions
  • Identify NTLMv2 session security requirements
  • Analyze Headers View to see actual HTTP authentication headers
  • Suggest specific fixes based on your authentication method

Disabling NTLMv2 Session Security (Legacy Workaround)

If you're using Load Tester 5.3 or earlier and cannot upgrade, you may attempt to disable the stronger security requirement on your server:

On your server:

  1. Open Local Security Policy: Start → Run → secpol.msc
  2. Navigate to: Security Settings → Local Policies → Security Options
  3. Find policy: "Network security: Minimum session security for NTLM SSP (including secure RPC) servers"
  4. If checked: Uncheck "Require NTLMv2 session security" and press OK

Security Implications

Disabling NTLMv2 session security weakens your server's security. This is a workaround for legacy Load Tester versions. The recommended solution is to upgrade to Load Tester v5.4 or later, which supports NTLMv2 session security automatically.

403 Forbidden Errors

Symptom: Replay succeeds with 200 OK on the login page, but subsequent pages return 403 Forbidden.

Likely causes:

  1. Insufficient permissions: The authenticated user doesn't have permission to access the requested resource
  2. Session not established: Authentication succeeded, but the application didn't establish a session
  3. CSRF token missing: Application requires a CSRF token that wasn't correlated

Diagnosis:

  • Check credentials: Verify the user has the correct permissions in the application
  • Compare headers: Use Headers View to compare successful browser request vs. failed replay request
  • Check cookies: Verify session cookies are being set after authentication
  • Run ASM: Application State Management may detect missing correlation fields

Ask the AI to Diagnose 403 Errors

If authentication succeeds but you get 403 errors:

Authentication works (login returns 200 OK) but the next transaction
fails with 403 Forbidden. Can you help identify what's missing?

The AI can:

  • Compare successful authentication vs. failed subsequent request
  • Identify missing session cookies or headers
  • Check for CSRF tokens or other correlation issues
  • Recommend running ASM to detect dynamic fields

Proxy Authentication Issues

Symptom: Replay fails with 407 Proxy Authentication Required.

Solution: Configure proxy authentication credentials:

  1. Open Test Case Properties: Right-click test case → Properties
  2. Navigate to: Proxy tab
  3. Enter proxy credentials: Username, password, domain (if applicable)
  4. Select authentication method: Basic, Digest, or NTLM
  5. Press OK

Proxy authentication works exactly like server authentication, but uses Proxy-Authenticate and Proxy-Authorization headers instead of WWW-Authenticate and Authorization.

Best Practices

1. Use Unique Credentials for Each Virtual User

Why: Many servers don't behave predictably when the same user is logged in from multiple sessions simultaneously. Some servers will:

  • Invalidate earlier sessions when a new session is created
  • Rate-limit concurrent sessions from the same user
  • Show unpredictable behavior (session conflicts, data corruption)

How: Use the dataset approach when configuring authentication. Create a spreadsheet with multiple usernames/passwords and link it to the authentication fields.

2. Inspect Recordings for Authentication Overhead

Why: HTTP authentication adds extra transactions (2 for Basic, 3 for NTLM per connection). If your application makes many small requests (images, CSS, JavaScript), the authentication overhead can significantly impact performance.

How:

  1. Reveal CAN transactions in the Test Case Editor
  2. Count how many 401 responses appear in your recording
  3. Compare: Are there 401s for every resource, or just once per connection?
  4. If overhead is high: Consider switching to a more efficient authentication scheme (e.g., NTLM with persistent connections, or moving to OAuth 2.0)

3. Verify Credentials Before Load Testing

Why: Invalid credentials cause 401/403 errors during load tests, wasting time and resources.

How:

  1. Run a single-user replay first after configuring authentication
  2. Verify all transactions return 200 OK (or expected status codes)
  3. If using a dataset: Test with at least 2-3 different credentials to ensure they all work
  4. Only then: Proceed to load testing

4. Understand Your Server's Authentication Method

Why: Different authentication methods have different performance characteristics and configuration requirements.

How:

  1. Check with your web admin or developers about which authentication method the server uses
  2. Inspect Headers View during recording to see actual WWW-Authenticate headers
  3. Look for realm names (Basic/Digest) vs. Negotiate/NTLM indicators
  4. Know if persistent connections are enabled (critical for NTLM performance)

Next Steps

After configuring basic or form-based authentication, verify your test case replays successfully:

  • Running a Replay - Verify all transactions show green (success) in the Replay View

If your application uses modern authentication instead:

For advanced configuration scenarios: