Ein Bearer-Token wird im Authorization-Header als `Authorization: Bearer <token>` gesendet und autorisiert die Anfrage allein durch seine Vorlage. Die Anfrage enthält keine Signatur, keinen Nachweis, dass der Absender derjenige ist, dem das Token ausgestellt wurde: Das Token selbst ist die vollständige Anmeldeinformation, daher die Bezeichnung "bearer" .
Der Server validiert das Token – entweder durch Nachschlagen oder, falls es sich um ein eigenständiges Token wie ein JWT handelt, durch Überprüfung der Signatur – und leitet daraus die Identität und Berechtigungen des Aufrufers ab. Ein fehlendes oder ungültiges Token führt zu einem 401-Fehler. Ein gültiges Token, dessen Inhaber jedoch nicht berechtigt ist, diese spezielle Aktion auszuführen, führt zu einem 403-Fehler. Dieser Unterschied ist wichtig, da nur einer der beiden Fälle durch die Anforderung eines neuen Tokens behoben werden kann.
Ein Bearer-Token kann gefahrlos in einer URL verwendet werden, da er abläuft. Alles, was in einer URL enthalten ist, landet in Serverprotokollen, Browserverlauf, Referrer-Headern und Analysedaten. Bearer-Token gehören in einen Header, über TLS, mit kurzer Gültigkeitsdauer und einem Aktualisierungsmechanismus.
Jeder mit einer Sperre markierte Endpunkt benötigt `qa-admin-token` oder `qa-viewer-token` . Die Verwendung des Viewer-Tokens bei einer DELETE-Anfrage ist die einfachste Möglichkeit, den Unterschied zwischen den Statuscodes 401 und 403 zu verdeutlichen: Das Token ist gültig, die Antwort lautet aber trotzdem „Nein“.
Diese Seite auf Englisch lesen
Alle Glossarbegriffe · Testtechniken · Alle 39 Mock-REST-APIs
Zuletzt aktualisiert