Test de Charge API JWT : Modèle de Tokens

Tester en charge une API protégée par des jetons JWT

La plupart des tests de charge d'API échouent à la porte : 401 sur chaque requête parce que le jeton n'a jamais été envoyé, ou un point d'accès de connexion martelé par le test lui-même. Ce modèle fait comme le trafic de production : obtenir un jeton une fois, l'envoyer dans l'en-tête Authorization: Bearer à chaque requête mesurée, et garder le flux du jeton hors des chiffres que vous évaluez.

Configuration

Lancer ce modèleOuvre le formulaire de test cloud avec ces valeurs préremplies. Le plan gratuit l'exécute à la limite d'utilisateurs gratuite ; connectez-vous ou créez d'abord un compte gratuit.

Le bouton préremplit utilisateurs, durée et montée en charge dans le formulaire de test cloud. Ajoutez vos points d'accès et l'en-tête Authorization (émettez un jeton de test dont la durée de vie dépasse celle du test), puis lancez le test.

Faire entrer le jeton et le garder hors des métriques

• Jeton de test longue durée. Émettez un jeton pour l'utilisateur de test avec une expiration au-delà du test (une heure suffit) et collez-le dans l'en-tête. C'est le plus simple et cela mesure l'API, pas le fournisseur d'identité.
• Une connexion par utilisateur virtuel. Quand les jetons sont de courte durée, récupérez le jeton dans une étape de préparation et réutilisez-le ; dans la version k6 ci-dessous, c'est la fonction setup(), exécutée une fois, qui transmet le jeton à chaque utilisateur virtuel.
• Jetons expirés ou révoqués, exprès. Un second petit test avec un mauvais jeton vous dit ce que coûte un 401 sous charge. Rejeter une requête devrait coûter moins cher que la servir ; si le p95 des 401 se rapproche du p95 des 200, la validation du jeton touche la base de données.

Ce qu'il faut lire dans les résultats

• 401 et 403 par point d'accès. Le moindre dans le test principal signifie que le jeton n'a pas atteint une requête ou a expiré en cours de route. Corrigez la préparation, ne lissez pas dans la moyenne.
• p95 par point d'accès. Les lectures doivent rester bien sous l'écriture ; si GET /me est aussi lent que POST, le coût est dans la validation du jeton ou une vérification de permission par requête.
• 429. Un limiteur de débit indexé sur le jeton ou l'utilisateur se déclenchera quand 200 utilisateurs virtuels partagent une identité. C'est un vrai constat sur le limiteur, pas sur la capacité, et la raison de donner à chaque utilisateur virtuel son propre jeton dans la seconde itération de ce test.

Seuils de réussite/échec pour ce modèle

Le même scénario en script k6

Importez celui-ci dans un test k6 cloud quand le jeton doit être récupéré à l'exécution. Les identifiants vont dans des variables d'environnement, jamais dans le script.

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 sur les tests de charge des API protégées par JWT

Où mettre le jeton dans un test cloud LoadFocus ?

Dans les en-têtes de chaque requête : nom Authorization, valeur Bearer suivi du jeton. Enregistrez-le comme preset d'en-têtes et il est disponible pour tous les tests de l'équipe.

Le point d'accès de connexion doit-il faire partie du test de charge ?

Pas dans le même test. Se connecter 200 fois par seconde teste votre fournisseur d'identité et fausse tous les autres chiffres. Testez le point d'accès de connexion à part, avec une petite configuration dédiée.

Le test renvoie 401 sur chaque requête. Qu'est-ce qui cloche ?

Soit l'en-tête manque sur certaines requêtes, soit le jeton a expiré pendant le test (émettez-en un plus long), soit l'API attend le jeton ailleurs (un cookie ou un en-tête X-Api-Key). Regardez le corps de réponse d'une requête en échec dans l'onglet Errors.

Cela fonctionne-t-il avec OAuth 2.0 client credentials ?

Oui. Le flux est le même : demander un jeton au point d'accès de jetons une fois, puis l'envoyer en en-tête bearer. La version k6 ci-dessus remplace le POST de connexion par l'appel au point d'accès de jetons.