Skip to content
MaxoPerf MaxoPerf docs

Auth login + token capture flow

Problem: Your API needs a login step to get a session token (JWT, cookie, or API key), and every later request must send that token. The load test has to run the full authenticate → act sequence so the results match what real users do.

Test type: API performance test or Load test.

Prerequisites

Section titled “Prerequisites”
  • A MaxoPerf account, workspace, and a test already created (or follow REST API CRUD load test first).
  • The login endpoint URL and a set of test credentials stored as project secrets.
  • Knowledge of where the token appears in the login response (JSON field name or cookie name).

Step by step in MaxoPerf

Section titled “Step by step in MaxoPerf”

1. Write the Taurus scenario

Section titled “1. Write the Taurus scenario”
execution:
  - scenario: auth-flow
    concurrency: 20
    ramp-up: 1m
    hold-for: 5m


scenarios:
  auth-flow:
    variables:
      base_url: https://api.example.com
      access_token: ''
    requests:
      # Step 1: Login and capture the token
      - label: POST /auth/login
        url: ${base_url}/auth/login
        method: POST
        headers:
          Content-Type: application/json
        body: |
          {
            "email": "${LOGIN_EMAIL}",
            "password": "${LOGIN_PASSWORD}"
          }
        extract-jsonpath:
          access_token: '$.access_token'


      # Step 2: Use the captured token
      - label: GET /me
        url: ${base_url}/me
        method: GET
        headers:
          Authorization: Bearer ${access_token}


      # Step 3: Perform a protected action
      - label: POST /orders
        url: ${base_url}/orders
        method: POST
        headers:
          Authorization: Bearer ${access_token}
          Content-Type: application/json
        body: '{"product_id": "sku-001", "quantity": 1}'

LOGIN_EMAIL and LOGIN_PASSWORD are project secrets (see step 3 below). The extract-jsonpath directive copies the access_token field from the login response into a variable. Later requests reference it as ${access_token}.

2. Upload the file

Section titled “2. Upload the file”
  1. Open the test, switch to the Files tab, and drag the YAML file in.
  2. Mark it as the entrypoint and save.

3. Bind credentials as secrets

Section titled “3. Bind credentials as secrets”
  1. Switch to the Settings tab.
  2. Under Secrets, add two bindings:
    • LOGIN_EMAIL → the secret holding the test user’s email address.
    • LOGIN_PASSWORD → the secret holding the test user’s password.
  3. Save.

4. Configure and run

Section titled “4. Configure and run”
  1. Switch to the Configuration tab and set VUs, ramp-up, and location.
  2. Click Run now.
  3. Watch the POST /auth/login label in the run overview. It should show a 200 response and near-zero error rate.

Verify

Section titled “Verify”
  • The POST /auth/login label shows 2xx responses and an extracted variable. To confirm the token is not null, check that the GET /me and POST /orders labels also return 2xx.
  • If downstream labels return 401 Unauthorized, the extraction path is wrong. Check the JSON field name in the login response body and fix extract-jsonpath.
  • p95 latency for the login step should be lower than for the action steps, because login is a single round trip.

Variations

Section titled “Variations”
  • Cookie-based auth: if the login endpoint sets a Set-Cookie header, the Taurus HTTP session stores the cookie for you. You do not need an explicit extractor.
  • OAuth 2 client-credentials: put the token request in a separate pre-run setup section so it runs once, not once per VU.
  • Different tokens per VU: feed user credentials from a CSV data entity. See CSV data-driven test.
  • Token refresh mid-test: add a conditional request that refreshes the token after N requests. Use a Taurus if condition or a JMeter pre/post processor.

Where to go next

Section titled “Where to go next”