Du kennst den Ablauf. Postman auf, Login-Request ausführen, das Token in der Antwort markieren, kopieren, den Request öffnen, den du eigentlich schicken wolltest, den Authorization-Header suchen, einfügen. Absenden. Zwanzig Minuten später einen 401 bekommen, weil das Token abgelaufen ist, und alles noch mal.
Das dauert fünfzehn Sekunden, und du machst es heute vierzigmal. So machst du es nie wieder.
Die Idee
Drei Teile:
- Der Login-Request speichert das Token bei Erfolg in einer Collection-Variable.
- Die Auth der Collection steht auf Bearer und nutzt diese Variable.
- Jeder Request erbt die Collection-Auth, keiner erwähnt also überhaupt ein Token.
Das war's. Neuen Request anlegen, und er ist authentifiziert. Nie wieder kopieren.
Schritt 1: das Token einsammeln
Öffne deinen Login-Request, geh auf den Tab Scripts (ältere Versionen nennen ihn Tests) und trag das hier ein:
const res = pm.response.json();
pm.collectionVariables.set("jwt", res.token);
pm.collectionVariables.set("jwt_captured_at", Date.now());
pm.test("login returned a token", function () {
pm.expect(res.token).to.be.a("string").and.not.empty;
});
Pass res.token an das an, was deine API tatsächlich zurückgibt — Symfony mit LexikJWT gibt dir token, viele andere nutzen access_token oder verschachteln es unter data.
Nimm pm.collectionVariables, nicht pm.environment. Das Token gehört zur Sitzung dieser Collection, nicht zur Definition der Umgebung — und wenn du es in die Umgebung legst, synchronisierst du irgendwann ein gültiges Produktions-Token in einen geteilten Workspace.
Schritt 2: die Collection-Auth setzen
Rechtsklick auf die Collection → Edit → Authorization. Typ auf Bearer Token stellen und als Token:
{{jwt}}
Dann sicherstellen, dass jeder Request darunter auf Inherit auth from parent steht, was der Standard ist, solange niemand es geändert hat. Ein Request, der noch seinen eigenen handgeschriebenen Authorization-Header trägt, ignoriert das alles stillschweigend — und das ist das Erste, was du prüfst, wenn es nicht funktioniert.
Der Login-Request selbst ist die Ausnahme — den stell auf No Auth. Ein abgestandenes Bearer-Token an deinen Login-Endpunkt zu schicken ist ein guter Weg zu einem verwirrenden 401.
Schritt 3: automatisch einloggen, wenn das Token alt ist
Zwei Schritte weiter, und du musst immer noch daran denken, zuerst den Login-Request auszuführen. Das behebst du mit einem Pre-Request-Script auf Collection-Ebene (Edit collection → Scripts → Pre-request):
const token = pm.collectionVariables.get("jwt");
const capturedAt = Number(pm.collectionVariables.get("jwt_captured_at") || 0);
const maxAgeMs = 50 * 60 * 1000; // kurz vor Ablauf erneuern
if (!token || Date.now() - capturedAt > maxAgeMs) {
pm.sendRequest({
url: pm.variables.replaceIn("{{host}}/api/login"),
method: "POST",
header: { "Content-Type": "application/json" },
body: {
mode: "raw",
raw: JSON.stringify({
email: pm.variables.replaceIn("{{email}}"),
password: pm.variables.replaceIn("{{password}}"),
}),
},
}, function (err, res) {
if (err) { console.error("autologin failed", err); return; }
pm.collectionVariables.set("jwt", res.json().token);
pm.collectionVariables.set("jwt_captured_at", Date.now());
});
}
Jetzt prüft jeder Request vor dem Absenden das Alter des Tokens und loggt sich neu ein, wenn es alt ist. Du machst nach dem Mittagessen Postman auf, schickst irgendeinen Request, und es funktioniert einfach.
Setz das Zeitfenster kürzer als die tatsächliche TTL deiner API. Wenn deine Tokens eine Stunde leben, erneuere nach fünfzig Minuten. Ein Token, das mitten in einem Collection-Lauf abläuft, produziert Fehler, die wie echte Bugs aussehen, und du jagst einen davon eine halbe Stunde, bevor es dir dämmert.
Zugangsdaten gehören in eine Umgebung, und die wird nicht geteilt
{{host}}, {{email}} und {{password}} kommen aus einer Postman-Umgebung, und genau das lässt dieselbe Collection per Dropdown-Wechsel gegen lokal, Staging und Produktion laufen.
Markier das Passwort als Secret-Variablentyp, damit es in der Oberfläche maskiert ist, und committe nie eine ausgefüllte Umgebung. Committe stattdessen ein Template mit leeren Werten — dasselbe Muster wie alles andere in wie du REST-Requests teilst, ohne deine Zugangsdaten mitzuliefern.
Wenn deine API stattdessen Firebase Auth nutzt
Nicht jede API stellt ihr eigenes JWT aus. Meine authentifizieren gegen Firebase, und das Bearer-Token ist ein Firebase-ID-Token — der Login-Schritt geht also zu Google, nicht zu meinem eigenen Backend:
pm.sendRequest({
url: "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key="
+ pm.environment.get("firebase_api_key"),
method: "POST",
header: { "Content-Type": "application/json" },
body: {
mode: "raw",
raw: JSON.stringify({
email: pm.environment.get("email"),
password: pm.environment.get("password"),
returnSecureToken: true,
}),
},
}, function (err, res) {
if (err) { console.error(err); return; }
pm.collectionVariables.set("jwt", res.json().idToken);
pm.collectionVariables.set("jwt_captured_at", Date.now());
});
Alles andere ist identisch. Zwei Dinge muss man wissen: Das Token steckt in idToken, nicht in token, und Firebase-ID-Tokens sind exakt eine Stunde gültig — das Erneuerungsfenster zählt hier also mehr, nicht weniger.
Dasselbe in einem IDE-Client
Wenn deine Requests in .http-Dateien statt in Postman leben, ist es sogar weniger Arbeit, weil das Format direkt auf eine frühere Antwort verweisen kann:
### login
# @name login
POST {{host}}/api/login
Content-Type: application/json
{ "email": "{{email}}", "password": "{{password}}" }
### alles andere
GET {{host}}/api/applications
Authorization: Bearer {{login.response.body.token}}
Gar kein Scripting — dafür musst du den Login-Request einmal pro Sitzung selbst ausführen. Welchen Kompromiss du bevorzugst, ist ungefähr dieselbe Entscheidung wie die, welchen REST-Client du überhaupt nutzt.
Die zehn Minuten wert
Das ist ein kleines Stück Einrichtung, das eine kleine Nervigkeit beseitigt, die du dutzendfach am Tag hast. Das sind die besten Automatisierungen — nicht weil sie einzeln viel Zeit sparen, sondern weil die Unterbrechung der teure Teil ist.