Load test apps behind any standard auth scheme.
OAuth 2.0, OpenID Connect, PKCE, SAML, Azure AD / Microsoft Entra ID, NTLM, HTTP Basic, authenticating proxies. The recorder captures whatever the browser does to authenticate; ASM correlates the resulting tokens for replay; the AI Assistant catches anything ASM has not yet learned. Most auth schemes need no manual configuration.
Modern web authentication.
The protocols that protect today’s web and mobile applications. WPLoadTester records the full handshake from the browser and replays it for every virtual user, with the tokens that have to differ per VU correlated automatically.
OAuth 2.0 and OpenID Connect.
The recorder captures the authorization request, the IdP login interaction, the redirect back with the authorization code, and the token-exchange POST that returns the Bearer token (and optionally a refresh token, ID token, or both). ASM detects Bearer tokens in JSON responses and correlates them with Authorization: Bearer headers on every protected request. Refresh-token flows are handled the same way: the refresh response’s new Bearer rotates into subsequent requests automatically. OpenID Connect adds an ID token alongside the access token; ASM treats it as another correlated JSON field. Read about Automatic Configuration
PKCE (Proof Key for Code Exchange).
The OAuth 2.0 extension that mobile, SPA, and other public clients use. The client generates a code_verifier, derives a code_challenge from it, sends the challenge with the authorization request, and submits the verifier on the token exchange. The two have to match at the IdP. WPLoadTester treats the verifier / challenge pair like any other correlated value: the recorded pair persists for replay, and per-VU generation happens automatically when you parameterize the user identity. Standard PKCE shapes (S256 hashing, plain verifier) work without manual configuration. The screenshot above is a PKCE flow as captured.
SAML 2.0.
Enterprise SSO via SAML works through the standard redirect-and-POST workflow. WPLoadTester records the SAML AuthnRequest your application sends to the IdP, the user’s login interaction at the IdP, and the SAML Response that gets POSTed back to your application’s AssertionConsumerService endpoint. The base64-encoded SAML assertion is a normal correlated request-body field for replay. For unusual IdP response shapes, a JavaScript custom extractor handles the extraction.
Azure AD and Microsoft Entra ID.
Azure AD authentication is OAuth 2.0 / OIDC (sometimes SAML, depending on the application’s configuration). The recorded HTTPS traffic to login.microsoftonline.com captures the full flow including any conditional-access challenges, MFA redirects, and consent screens. The tokens returned at the end of the flow correlate via ASM in the standard OAuth manner. The same is true for other IdPs built on the same protocols (Okta, Auth0, Google Identity Platform, Ping Identity): WPLoadTester does not need IdP-specific handling because the protocols underneath are standard.
Windows-integrated authentication.
NTLM / Integrated Windows Authentication.
WPLoadTester implements the full NTLM challenge-response handshake at replay time. The User Identity page of the test case properties holds the credentials (or a list of credentials for per-VU rotation). Test cases recorded without IWA can use IWA later, and the reverse, without re-recording. The recorder also accurately simulates the speculative authentication some Windows clients send to reduce round trips.
Kerberos environments (via NTLM fallback).
WPLoadTester does not implement the Kerberos protocol natively. In Kerberos-capable environments, WPLoadTester completes the SPNEGO negotiation with the server and requests Integrated Windows Authentication (NTLM) instead. When the server is configured to accept NTLM as a fallback (the common case for IIS on Windows Server), the test runs transparently. The performance characteristics of NTLM replay against a Kerberos-configured server are not meaningfully different from native Kerberos in practice.
The case where this does not work: servers configured to require Kerberos only, with no NTLM fallback enabled. WPLoadTester cannot complete authentication in that configuration. If your environment has that restriction, contact us before deploying a load test.
Basic and proxy authentication.
HTTP Basic.
Basic authentication is configured via the User Identity page and applied automatically for every replay, including when Basic was not in the original recording. Useful for staging environments that wrap a production app in Basic for access control.
Authenticating proxy servers.
Test case recording, test case replay, software updater, and cloud engine provisioning all work through authenticating proxy servers (corporate egress proxies with username / password requirements). One configuration covers every WPLoadTester component that goes through the proxy.
What ASM and the AI Assistant do for auth.
The two engines that handle dynamic state in WPLoadTester apply to auth tokens the same way they apply to any other dynamic value:
- ASM detects standard token shapes up-front during recording analysis (OAuth Bearer, refresh, JWT, ID token, CSRF, SAML assertion) and configures correlation rules automatically
- The AI Assistant watches the replay for runtime auth failures and generates new correlation rules when an IdP returns a non-standard shape
- Custom extractors handle the cases where you want explicit control: a JavaScript extractor for multi-step token derivation, a JSON Array Collector for IdPs that return arrays of credentials per user
The combined effect: most authentication schemes need no manual configuration. The recording captures the handshake, ASM correlates the tokens, the test runs.
Load-test your authenticated application.
OAuth, PKCE, SAML, Azure AD, NTLM, Basic, and authenticating-proxy support ship in every edition of WPLoadTester 7. Request the beta to run a cloud-scale test through your real IdP, or download the free single-machine edition to evaluate locally.
Reference: the canonical authentication docs live at docs.webperformance.com.