Skip to content
MaxoPerf MaxoPerf docs

Auth login + token capture flow

Problem: Your API requires a login step to obtain a session token (JWT, cookie, or API key), and every subsequent request must present that token. You need the load test to perform the full authenticate → act lifecycle so the results reflect real user behaviour.

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 captures the access_token field from the login response into a variable; subsequent 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 (the token is not null — verify by checking the GET /me and POST /orders labels also succeed with 2xx).
  • If you see 401 Unauthorized on downstream labels, the extraction path is wrong. Check the JSON field name in the login response body and update extract-jsonpath accordingly.
  • p95 latency for the login step should be lower than the action steps — it is a single round trip.

Variations

Section titled “Variations”
  • Cookie-based auth: if the login endpoint sets a Set-Cookie header, Taurus’ HTTP session handles cookies automatically — you do not need an explicit extractor.
  • OAuth 2 client-credentials: make the token request in a separate pre-run setup section so it is fetched once rather than 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; handle this with a Taurus if condition or a JMeter pre/post processor.

Where to go next

Section titled “Where to go next”