Testen von OAuth 2.0, JWTs und Token-Ablauf

Die meisten Authentifizierungstests beschränken sich auf die "a valid token works, an invalid one does not" . Dadurch bleibt der interessante Teil ungetestet: das Token, das zu Beginn der Anfrage gültig war und vor deren Abschluss ablief. Die unten aufgeführten APIs stellen signierte und kurzlebige Token aus, sodass Aktualisierung und Ablauf tatsächlich stattfinden.

Wie man es übt

1. Schließen Sie den Client-Credentials-Ablauf ab und rufen Sie mit dem ausgestellten Token einen geschützten Endpunkt auf.
2. Warten Sie auf den Ablauf eines kurzlebigen Tokens und prüfen Sie, dass der Client es erneuert, ohne die Benutzeranfrage fehlschlagen zu lassen.
3. Tauschen Sie einen Refresh-Token aus und prüfen Sie anschließend die Ablehnung bei erneuter Verwendung des alten Tokens.
4. Führen Sie den Authorization-Code-Ablauf mit PKCE aus und wiederholen Sie ihn mit einem falschen code_verifier.
5. Führen Sie den Device-Code-Ablauf für CLIs und Fernsehgeräte vollständig durch.
6. Senden Sie ein formal korrektes JWT mit falscher Signatur und prüfen Sie, dass es ebenso wie ein fehlendes Token abgelehnt wird.

APIs, um es auszuprobieren

• Auth Playground API— OAuth 2.0 flows — client credentials, auth code, refresh & expiry. (6 endpoints)
• Webhooks-API — Register callbacks, trigger events, inspect & replay deliveries. (7 endpoints)
• Moderne Identitäts-API — OIDC discovery, PKCE, device codes & token lifecycle. (6 endpoints)

Betroffene Statuscodes

• 200 OK
• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden

Andere Techniken

• API-Paginierung testen — Practise page-number and cursor pagination, and the edge cases that break clients: the last partial page, an out-of-range page, and a total count that disagrees with what you collected.
• API-Ratenbegrenzung testen — Trigger a real 429 with Retry-After and X-RateLimit headers, and verify your client backs off instead of retrying straight into the limit.
• Idempotenz-Schlüsseltest— Send the same write twice with an Idempotency-Key and confirm the operation happens once — the mechanism that stops a network retry becoming a duplicate charge.
• ETag- und If-Match-Test— Provoke a 412 Precondition Failed by writing with a stale ETag — the check that stops two clients silently overwriting each other.
• Webhook-Signaturprüfung — Register a callback, trigger a delivery, verify its HMAC signature, and confirm a tampered payload is rejected.
• Negativer Test — Provoke 400, 401, 403, 404, 409, 418, 422, 429, 500 and 503 deliberately, and check your client handles each one differently.
• Asynchrone Jobtests— Start a long-running job, follow the 202 and its Location header, and poll to completion — including the failure and timeout paths.

Einstiegsanleitung · Alle 39 Mock-REST-APIs

Zuletzt aktualisiert 16. Oktober 2026