Skip to content

SSO & Modern Auth Patterns

Modern web applications increasingly rely on Single Sign-On (SSO) and federated authentication patterns like SAML and OpenID Connect (OIDC). These methods all share one important characteristic: they ultimately produce OAuth 2.0 Bearer tokens, which means Load Tester's OAuth detection rules handle them automatically.

This guide explains how SSO patterns work with Load Tester and what special considerations apply when load testing modern authentication flows.

The Anti-Bot Reality

There has always been an arms race between web security teams and the people trying to scrape, attack, or otherwise automate against their sites. Load testers are caught in the middle. From the server's point of view, a load test script and a credential-stuffing attack look essentially identical: same headers, same request patterns, same lack of mouse movement. The defenses that legitimately protect production from attackers are exactly the defenses that get in the way of a load test.

The list of defenses you have to either satisfy or bypass keeps growing:

  • Multi-factor authentication (SMS codes, authenticator apps, hardware keys): by design, impossible to automate
  • CAPTCHA and bot-detection challenges: designed specifically to fail on automated traffic
  • Device fingerprinting and behavioral analytics: flag accounts that log in from too many sessions or behave unlike a real user
  • IP reputation and rate limiting: block traffic that hits the auth endpoint too aggressively
  • JavaScript challenges and proof-of-work: require the client to execute JavaScript that Load Tester does not run
  • Geo-fencing and trusted-device requirements: only allow sign-ins from approved networks or devices

The trend is clear: authentication is the hardest part of any non-trivial load test, and it's getting harder. For ordinary sites you can usually push through with patient configuration. ASM and the AI assistant handle most of the standard patterns. For the most secure sites (banks, government, healthcare), programmatic configuration is no longer enough. You need cooperation from the security team.

The Internal Test Server Pattern

For high-security applications, the standard practice is to set up a separate internal test environment that relaxes the most aggressive defenses. This is not a workaround. It's how serious load testing gets done at banks and other regulated organizations. Typically the test environment:

  • Disables MFA for test accounts, or routes test logins through a path that doesn't require MFA
  • Turns off CAPTCHA and bot detection, or whitelists the load generator's IP range so challenges never fire
  • Issues longer-lived tokens to test accounts so refresh logic isn't continuously exercised
  • Exposes a test-only auth endpoint that accepts canned credentials and returns a valid token, bypassing the production login UI entirely
  • Whitelists the load-generator IPs at the WAF, CDN, and any rate-limiting layer

When you can't get a separate environment, the next best thing is to negotiate selective relaxations against a staging copy of production: MFA bypass on flagged test accounts, IP-based CAPTCHA exceptions, or an API-only token-issuance endpoint your test case can call instead of replaying the full SSO flow.

What You Give Up

Relaxing auth defenses in the test environment means your test traffic is no longer fully representative of production. A load test against a CAPTCHA-disabled environment can't tell you how the CAPTCHA service scales. Plan for that. Measure server capacity in isolation, and validate the auth-layer's own scaling separately, often via the vendor's published numbers or a small, targeted test against the real auth path.

Ask the AI About Your Auth Landscape

The AI assistant can help you map your auth flow to the right strategy:

My application uses [auth provider] with MFA enabled. I'm trying to load
test 1,000 concurrent users. What's the right way to handle authentication?

Understanding Modern Authentication Patterns

Single Sign-On (SSO)

What it is: Users authenticate once with an identity provider (like Okta, Auth0, Azure AD), then access multiple applications without re-entering credentials.

How it works for load testing:

  1. User logs in to identity provider (IdP)
  2. IdP issues tokens (access_token, id_token, refresh_token)
  3. Application receives tokens via redirect or callback
  4. Subsequent requests include Bearer token in Authorization header

Key insight: The final result is a Bearer token that works exactly like standard OAuth 2.0.

SAML (Security Assertion Markup Language)

What it is: XML-based protocol for exchanging authentication data between an identity provider and service provider.

How it works for load testing:

  1. Application redirects to SAML identity provider
  2. User authenticates at IdP (this may be recorded or pre-configured)
  3. IdP posts SAML assertion (XML document) back to application
  4. Application converts SAML assertion to session cookie or Bearer token
  5. Subsequent requests use the session/token for authentication

Key insight: SAML assertions are typically short-lived and converted to session cookies or Bearer tokens. You'll extract the final session credential, not the SAML assertion itself.

OpenID Connect (OIDC)

What it is: Modern authentication layer built on top of OAuth 2.0, providing identity information in addition to authorization.

How it works for load testing:

  1. Application redirects to OIDC provider (like Google, Microsoft)
  2. User authenticates at provider
  3. Provider returns tokens: access_token, id_token (JWT), optional refresh_token
  4. Application validates id_token and establishes session
  5. Subsequent requests use Bearer token or session cookie

Key insight: OIDC is OAuth 2.0 with identity information. Load Tester's OAuth detection rules handle it automatically.

Modern Auth = OAuth 2.0

SAML, OIDC, and SSO all ultimately produce OAuth 2.0 tokens or session credentials. Load Tester's OAuth detection rules (covered in OAuth & Bearer Tokens) handle these automatically in most cases.

How Load Tester Handles SSO & Modern Auth

Automatic Detection via OAuth Rules

Load Tester's OAuth detection rules work with SSO and modern auth patterns:

For OIDC: - oauth2-access-token extracts access_token from JSON responses - oauth2-jwt-token validates and extracts id_token (JWT format) - oauth2-refresh-token captures refresh_token for long tests

For SAML: - ASM detects session cookies or tokens created after SAML assertion - oauth2-bearer-header handles tokens in response headers - Standard cookie correlation handles SAML-generated sessions

For SSO (general): - Works like OAuth 2.0 after initial authentication - Bearer token or session cookie extracted automatically - OAuth refresh rules handle token expiration

Recording SSO Flows

The key challenge with SSO: You need to record the complete authentication flow including identity provider interaction.

Recommended approach:

  1. Start recording before any authentication happens
  2. Navigate to your application (triggers SSO redirect)
  3. Complete authentication at identity provider
  4. Get redirected back to your application
  5. Navigate to a few pages to capture authenticated requests
  6. Stop recording

The recording will include: - Initial application page (triggers SSO redirect) - Identity provider pages (login form, authentication) - Callback/redirect back to application - Token exchange or session establishment - Authenticated application pages

Record the Complete Flow

Don't start recording AFTER you're already logged in. Record the entire authentication flow from the beginning, including the identity provider interaction. This captures all the redirect URLs, state parameters, and token exchanges that ASM needs to configure.

Configuration Workflow

Step 1: Record Complete SSO Flow

Before you start: - Make sure you're logged out of both the application and identity provider - Clear browser cookies to ensure a clean authentication flow - Have test credentials ready (username/password for IdP)

Recording:

  1. Start Load Tester recording
  2. Navigate to your application URL
  3. Complete authentication at identity provider when redirected
  4. Return to application (happens automatically via redirect)
  5. Use the application - navigate to several pages
  6. Stop recording

Step 2: Run ASM

ASM will automatically:

  • Detect OAuth tokens in the callback/token exchange
  • Extract Bearer tokens or session cookies
  • Configure Authorization headers with "Server authentication header" datasource
  • Create user variables for tokens (e.g., bearer_token[1], id_token[1])

What to verify after ASM:

✅ Authorization headers show "Server authentication header" (GOOD) ✅ User variables created for tokens (check Fields View) ✅ Session cookies correlated if SAML-based

Step 3: Run Replay

Run a replay to verify SSO authentication works:

  1. Click Play in toolbar
  2. Watch for successful authentication at identity provider
  3. Verify callback redirects to application
  4. Check all transactions are green (success)

If replay fails, see Troubleshooting SSO Issues below.

Ask the AI About SSO Configuration

I recorded an SSO flow using Azure AD as the identity provider. ASM ran
but I'm not sure if the tokens were detected correctly. Can you analyze
my test case and verify the SSO configuration?

Special SSO Considerations

Identity Provider State Parameters

Most SSO protocols use state parameters to prevent CSRF attacks and track authentication requests.

Common patterns: - state=abc123xyz in OAuth/OIDC redirect URLs - RelayState in SAML requests - nonce values for replay protection

How ASM handles this: State parameters are detected as dynamic values and automatically correlated. You typically don't need manual configuration.

If state correlation fails: The AI can help identify which state parameters aren't being extracted:

Troubleshoot State Parameters

My SSO replay is failing because the 'state' parameter in the callback
URL doesn't match what the IdP is expecting. Can you help me configure
the state parameter extraction?

Session Timeout vs Token Expiration

SSO introduces two timeout layers:

  1. Application session timeout - How long your app keeps you logged in
  2. IdP token expiration - How long the identity provider's token is valid

For load testing: - Short tests (< 1 hour): Usually no special handling needed - Long tests (> 1 hour): May need refresh token logic (see OAuth refresh tokens)

Token refresh with SSO: If your tokens expire during a load test, Load Tester's OAuth refresh detection rules (oauth2-grant-type-refresh, oauth2-rotating-refresh-token) handle renewal automatically.

Multi-Factor Authentication (MFA)

The MFA challenge: Many SSO implementations require MFA (SMS code, authenticator app, hardware key), and none of these can be automated during load testing. That's the entire point of MFA.

Workarounds:

  1. Disable MFA for test accounts (if your IdP allows it)
  2. Use longer-lived sessions - Authenticate once manually, then test with long-duration tokens
  3. Skip MFA challenge - Some IdPs let you mark devices as "trusted" to bypass MFA
  4. Pre-authenticated tokens - Generate tokens via API rather than recording full flow

MFA During Load Testing

You cannot automate MFA challenges (SMS codes, push notifications, TOTP codes) during load testing. Work with your security team to configure test accounts that bypass MFA or use longer session durations for test environments.

AI Can Help with MFA Strategies

My SSO flow requires MFA and I can't automate the TOTP code entry.
What are my options for load testing this application?

Common SSO Patterns

Pattern 1: OIDC with Google/Microsoft

How it works: - Application redirects to Google/Microsoft login - User authenticates (may already be logged into Google/Microsoft) - Receives id_token (JWT) + access_token - Application validates id_token and establishes session

Load Tester configuration: - Record complete flow including Google/Microsoft login - ASM extracts id_token and access_token via oauth2-jwt-token and oauth2-access-token rules - Bearer token automatically injected in subsequent requests

Special consideration: Google/Microsoft may detect automated login and present CAPTCHA. Use dedicated test accounts that bypass anti-automation measures.

Pattern 2: SAML with Okta/OneLogin

How it works: - Application redirects to Okta/OneLogin - User authenticates at IdP - IdP posts SAML assertion (XML) back to application - Application validates assertion, creates session cookie - Subsequent requests use session cookie

Load Tester configuration: - Record complete flow including Okta/OneLogin login - ASM correlates session cookie created after SAML assertion - No Bearer token (uses session cookie instead) - Cookie correlation works like standard session-based auth

Special consideration: SAML assertions are typically short-lived (minutes). Your recording must include the complete flow without pauses.

Pattern 3: SSO with Session Extension

How it works: - Initial authentication via SSO creates short-lived token - Application extends session via refresh token or background token renewal - User stays logged in for hours/days without re-authenticating

Load Tester configuration: - Record initial SSO flow + extended application usage - ASM captures both initial token and refresh token - OAuth refresh rules (oauth2-refresh-token, oauth2-rotating-refresh-token) handle renewal - Load tests can run for extended duration without re-authentication

Troubleshooting SSO Issues

Problem: Replay Fails at Identity Provider Login

Symptoms: Test case reaches IdP login page but authentication fails or hangs.

Likely causes: - Test account credentials not configured correctly - IdP detects automation and blocks login - CAPTCHA or bot detection triggered - MFA challenge can't be bypassed

Solution steps:

  1. Verify test account credentials work manually in browser
  2. Check if IdP requires MFA bypass for test accounts
  3. Contact IdP administrator to whitelist test automation
  4. Consider using API-based token generation instead of recording full flow

AI Can Diagnose IdP Issues

My replay fails at the Azure AD login page with a 403 error. The test
account works fine when I log in manually. What's blocking the replay?

Problem: State Parameter Mismatch

Symptoms: Callback from IdP fails with "invalid state" or "state mismatch" error.

Likely causes: - state parameter not extracted from initial request - state parameter not correlated with callback URL - State parameter has server-side validation that fails during replay

Solution steps:

  1. Check if ASM detected state as a dynamic field
  2. Search for state= in your test case to find where it's set and used
  3. Verify the state value in the callback matches the initial request
  4. Ask AI to analyze state parameter correlation

State Parameter Help

The OAuth state parameter isn't matching between the initial request
and the callback. Can you show me where the state is being set and
where it should be extracted?

Problem: Tokens Expire During Test

Symptoms: Load test runs fine for 30-60 minutes, then starts getting 401 errors.

Likely causes: - Access tokens are short-lived (typical: 1 hour) - Refresh token not captured or not being used - IdP session timeout shorter than load test duration

Solution steps:

  1. Check token expiration time (JWT tokens include exp claim)
  2. Verify ASM captured refresh_token
  3. Enable OAuth refresh detection rules via AI
  4. Consider shorter load test duration or background token refresh

See OAuth Token Refresh for detailed refresh configuration.

Problem: "Server authentication header" Not Appearing

Symptoms: After running ASM, Authorization headers still show "Recorded Value" instead of "Server authentication header".

This means: OAuth tokens weren't detected automatically.

Solution steps:

  1. Ask AI to enable OAuth detection rules (they may be disabled)
  2. Check if your SSO flow uses non-standard field names
  3. Verify response content-type is JSON (required for JSON detection rules)
  4. Fall back to manual OAuth configuration if needed

See OAuth Troubleshooting for detailed steps.

Testing Different SSO Providers

Azure Active Directory (Azure AD / Microsoft Entra ID)

Token format: OIDC with JWT tokens Typical flow: Redirect to login.microsoftonline.com → authenticate → callback with tokens Load Tester support: Automatic via oauth2-jwt-token and oauth2-access-token rules Special considerations: May require app registration for test environment, supports MFA bypass for test accounts

Okta

Token format: OIDC or SAML (configurable) Typical flow: Redirect to [domain].okta.com → authenticate → callback Load Tester support: Automatic via OAuth rules (OIDC) or session cookies (SAML) Special considerations: Test accounts can bypass MFA, supports API token generation

Auth0

Token format: OIDC with JWT tokens Typical flow: Redirect to [domain].auth0.com → authenticate → callback Load Tester support: Automatic via OAuth rules Special considerations: Flexible MFA configuration, good API support for test setup

Google Identity

Token format: OIDC with JWT tokens Typical flow: Redirect to accounts.google.com → authenticate → callback Load Tester support: Automatic via OAuth rules Special considerations: May detect automation, use Google Workspace test accounts

OneLogin

Token format: SAML or OIDC Typical flow: Similar to Okta Load Tester support: Automatic Special considerations: SAML implementation may require session cookie correlation

Ask About Your SSO Provider

I'm using [SSO Provider] for authentication. What special configuration
do I need for load testing? Are there any known issues or best practices?

Best Practices for SSO Load Testing

1. Use Dedicated Test Accounts

  • Never use production accounts for load testing
  • Create accounts in test/staging IdP environments
  • Configure accounts to bypass MFA
  • Use realistic usernames/passwords (avoid test123)

2. Record Clean Authentication Flows

  • Log out completely before recording
  • Clear all cookies and browser storage
  • Record the entire flow from first redirect to final authenticated page
  • Don't pause during recording (keep authentication flow continuous)

3. Test Token Expiration

  • Run load tests longer than token lifetime to verify refresh works
  • Monitor for 401 errors that indicate token expiration
  • Verify refresh tokens are captured and used correctly

4. Coordinate with Security Team

  • Explain load testing requirements to security/IdP administrators
  • Request MFA bypass for test accounts
  • Ensure test traffic doesn't trigger security alerts
  • Get approval before testing against production IdP

5. Use AI for Complex SSO Debugging

Modern SSO flows can be complex with multiple redirects, token exchanges, and state parameters. The AI assistant understands SSO patterns and can help debug issues:

Complex SSO Debugging

I recorded an SSO flow with multiple redirects between my app and the
identity provider. After running ASM, I'm not sure which tokens were
extracted and where they're being used. Can you analyze the flow and
explain what Load Tester detected?

Next Steps

Related Topics: