JWT-API Lasttest: Token-Handling Vorlage

Lasttest für eine API mit JWT-Bearer-Token

Die meisten API-Lasttests scheitern an der Tür: 401 bei jedem Request, weil das Token nie gesendet wurde, oder ein Login-Endpunkt, den der Test selbst überrollt. Diese Vorlage macht es wie echter Produktionstraffic: Token einmal holen, bei jedem gemessenen Request im Header Authorization: Bearer senden und den Token-Ablauf aus den bewerteten Zahlen heraushalten.

Konfiguration

Diese Vorlage ausführenÖffnet das Cloud-Test-Formular mit diesen Werten vorausgefüllt. Der kostenlose Plan läuft mit dem kostenlosen Nutzerlimit; melden Sie sich zuerst an oder erstellen Sie ein kostenloses Konto.

Der Button füllt Nutzer, Dauer und Ramp-up im Cloud-Test-Formular aus. Fügen Sie Ihre Endpunkte und den Authorization-Header hinzu (stellen Sie ein Test-Token mit einer Lebensdauer über die Laufzeit hinaus aus) und starten Sie den Test.

Das Token hineinbringen und aus den Kennzahlen heraushalten

• Langlebiges Test-Token. Stellen Sie ein Token für den Testnutzer mit Ablauf nach dem Lauf aus (eine Stunde reicht) und tragen Sie es in den Header ein. Das ist am einfachsten und misst die API, nicht den Identity-Provider.
• Einmal pro virtuellem Nutzer anmelden. Bei kurzlebigen Tokens holen Sie das Token in einem Setup-Schritt und verwenden es wieder; in der k6-Version unten ist das die Funktion setup(), die einmal läuft und das Token an jeden virtuellen Nutzer weitergibt.
• Abgelaufene oder widerrufene Tokens mit Absicht. Ein zweiter, kleiner Lauf mit einem ungültigen Token zeigt, was ein 401 unter Last kostet. Einen Request abzulehnen sollte billiger sein, als ihn zu bedienen; liegt p95 der 401er nahe am p95 der 200er, trifft die Token-Validierung die Datenbank.

Was Sie in den Ergebnissen lesen sollten

• 401 und 403 nach Endpunkt. Jeder davon im Hauptlauf heißt, dass das Token einen Request nicht erreicht hat oder mittendrin abgelaufen ist. Setup reparieren, nicht wegmitteln.
• p95 pro Endpunkt. Die Read-Endpunkte sollten deutlich unter dem Write liegen; ist GET /me so langsam wie POST, sind Token-Validierung oder eine Berechtigungsprüfung pro Request der Kostenfaktor.
• 429. Ein Rate-Limiter, der auf Token oder Nutzer schlüsselt, greift, wenn 200 virtuelle Nutzer eine Identität teilen. Das ist ein echter Befund über den Limiter, nicht über die Kapazität, und der Grund, in der zweiten Iteration jedem virtuellen Nutzer ein eigenes Token zu geben.

Pass/Fail-Schwellenwerte für diese Vorlage

Dasselbe Szenario als k6-Skript

Laden Sie dieses in einen k6-Cloud-Test hoch, wenn das Token zur Laufzeit geholt werden soll. Zugangsdaten gehören in Umgebungsvariablen, nie ins Skript.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 200 },
    { duration: '4m', target: 200 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<300'],
    http_req_failed: ['rate<0.005'],
  },
};

const BASE = 'https://api.example.com';

// Runs once; the returned token is shared by every virtual user.
export function setup() {
  const res = http.post(`${BASE}/auth/login`, JSON.stringify({
    username: __ENV.LF_USER,
    password: __ENV.LF_PASS,
  }), { headers: { 'Content-Type': 'application/json' } });
  check(res, { 'login ok': (r) => r.status === 200 });
  return { token: res.json('access_token') };
}

export default function (data) {
  const params = { headers: { Authorization: `Bearer ${data.token}` } };
  const me = http.get(`${BASE}/me`, params);
  check(me, { 'me 200': (r) => r.status === 200 });
  const orders = http.get(`${BASE}/orders?limit=20`, params);
  check(orders, { 'orders 200': (r) => r.status === 200 });
  sleep(0.5 + Math.random() * 0.5);
}

FAQ zu Lasttests für JWT-geschützte APIs

Wo trage ich das Token in einem LoadFocus-Cloud-Test ein?

In den Request-Headern jedes Requests: Name Authorization, Wert Bearer gefolgt vom Token. Als Header-Preset gespeichert steht es jedem Test des Teams zur Verfügung.

Sollte der Login-Endpunkt Teil des Lasttests sein?

Nicht im selben Lauf. 200 Logins pro Sekunde testen Ihren Identity-Provider und verzerren jede andere Zahl. Testen Sie den Login-Endpunkt separat mit einer kleinen, eigenen Konfiguration.

Der Test liefert bei jedem Request 401. Was ist falsch?

Entweder fehlt der Header bei einigen Requests, das Token ist während des Laufs abgelaufen (eines mit längerer Lebensdauer ausstellen), oder die API erwartet das Token woanders (ein Cookie oder ein X-Api-Key-Header). Prüfen Sie den Response-Body eines fehlgeschlagenen Requests im Errors-Tab.

Funktioniert das mit OAuth 2.0 Client Credentials?

Ja. Der Ablauf ist derselbe: Token einmal vom Token-Endpunkt holen, dann als Bearer-Header senden. Die k6-Version oben tauscht den Login-POST gegen den Aufruf des Token-Endpunkts.