TL;DR
Dieser Guide vergleicht die wichtigsten HTTP-Authentifizierungsverfahren: Basic, Digest, Bearer Token, OAuth 2.0, OpenID Connect, JWT und SAML. Der Bearer Token ist in der Praxis das dominierende Verfahren für API-Zugriffe: Ein Client sendet ihn im Authorization-Header und erhält damit Zugriff auf geschützte Ressourcen, ohne bei jeder Anfrage erneut Zugangsdaten zu übertragen. Der Guide zeigt den Unterschied zu API Key und Access Token, ein konkretes curl-Beispiel sowie die wichtigsten Regeln für Token-Validierung und Token-Ablauf.
HTTP authentication schemes
Im Allgemeinen erfolgt die Authentifizierung und Autorisierung über einen Autorisierungs-Header in der Anfrage:
Authorization: <type> <credentials>Die Art und die Berechtigungsnachweise sind je nach Regelung unterschiedlich, die häufigsten sind die folgenden:
Basic
Dies ist die einfachste und, wie der Name schon sagt, die grundlegendste Variante. Die Authentifizierung erfolgt durch Angabe des Passworts für jede Client-Anfrage. Die Anmeldedaten werden als Base64-kodierte Paare aus User und Kennwort übertragen. Der Autorisierungs-Header sieht wie folgt aus
Authorization: Basic Base64(user:password)Dabei steht Base64(user:password) für die Base64-kodierte Zeichenkette user:password.
Da Base64 keine Verschlüsselung bietet, wird das Kennwort im Klartext übertragen, und dieses Verfahren muss zusammen mit TLS verwendet werden.
Die technische Dokumentation finden Sie unter RFC 7617.
Digest
Im Gegensatz zur Basic-Authentifizierung muss bei der Digest-Authentifizierung das Kennwort nicht im Klartext übertragen werden. Stattdessen wird clientseitig aus Usernamen und Passwort ein Hash-Wert berechnet und an den Server gesendet.
Die Berechnung des Hashwerts ist recht komplex. Im Kern verwendet er eine Verkettung von Benutzername, Passwort und einem vom Server bereitgestellten Nonce-Wert und wendet darauf einen Hash-Algorithmus wie z. B. SHA-256 an.
Der Nonce-Wert ist obligatorisch, da er Wiederholungsangriffe verhindert, bei denen derselbe Hash mehrfach zur Authentifizierung eines Kunden verwendet wird, weshalb bei jeder nachfolgenden Anfrage ein neuer Nonce-Wert an den Kunden gesendet werden muss.
Es ist wichtig zu erwähnen, dass diese Authentifizierungsmethode als unsicher angesehen wird, da das Passwort im Klartext auf der Serverseite gespeichert werden muss, um die Hashes zu berechnen.Die technische Dokumentation finden Sie unter RFC 7616
Bearer
Ein Bearer Token ist eine verschlüsselte Zeichenkette, die ein Client im Authorization-Header mitschickt und damit ohne erneute Anmeldedaten auf geschützte Ressourcen zugreift. Wer den Token besitzt (englisch „bearer“ = Inhaber), gilt gegenüber dem Server als autorisiert.
Bei der Bearer-Authentifizierung handelt es sich um eine Token-basierte Authentifizierung, bei der die Benutzer ihre Anmeldedaten einmal eingeben und im Gegenzug einen Bearer Token erhalten. Mit diesem Access Token können Sie dann auf geschützte Systeme zugreifen, ohne Ihre Anmeldedaten erneut eingeben zu müssen. Der Autorisierungs-Header sieht wie folgt aus:
Authorization: Bearer <token>Da das Token im Klartext übertragen wird, muss dieses Verfahren zusammen mit TLS verwendet werden. Ein API Key unterscheidet sich vom Bearer Token vor allem in der Lebensdauer: Ein API Key bleibt meist über Monate oder Jahre gültig, ein Access Token läuft dagegen nach kurzer Zeit ab und muss über einen Refresh Token erneuert werden.
In der Praxis sieht ein Aufruf mit curl gegen eine geschützte Route so aus:
curl -H "Authorization: Bearer eyJhbGciOi..." https://api.example.com/v1/resourceBei gängigen APIs liegt die typische Lebensdauer eines Access Token zwischen 15 Minuten und einer Stunde. Der Server prüft bei jeder Anfrage per Token-Validierung, ob der Token noch gültig, nicht abgelaufen und nicht widerrufen ist, je nach Format entweder über einen Introspection-Endpoint (Identifier-based) oder direkt anhand der Signatur (Self-contained, siehe JWT weiter unten).
Es ist erwähnenswert, dass Zugangstoken nicht unbedingt über einen Request-Header übertragen werden müssen, sondern auch über einen Body oder einen Query-Parameter, aus Sicherheitsgründen ist der Header aber die empfohlene Variante, da Query-Parameter häufig in Server-Logs landen.
Die technische Dokumentation finden Sie unter RFC 6749. Wann sich ein Bearer Token gegenüber einem API Key oder einem klassischen Access Token eignet, zeigt die Bearer Token, OAuth2 oder API Keys: Entscheidungshilfe.
Bearer Token vs. andere Authentifizierungsmethoden
Bearer Token, API Key und Access Token werden in der Praxis oft synonym verwendet, unterscheiden sich aber in Zweck und Lebensdauer deutlich. Die folgende Tabelle zeigt die wichtigsten Unterschiede:
| Kriterium | Bearer Token | API Key | Access Token (OAuth) |
| Verwendung | Trägt die Autorisierung selbst, wird im Authorization-Header übertragen | Identifiziert die aufrufende Anwendung, meist statisch pro Projekt | Spezialfall des Bearer Token, ausgegeben nach einem OAuth-Autorisierungsablauf |
| Lebensdauer | Kurz (Minuten bis Stunden), erneuerbar über Refresh Token | Lang (Monate bis Jahre), manuelles Rotieren nötig | Kurz, an Scope und Resource-Owner-Zustimmung gebunden |
| Sicherheit | Muss mit TLS übertragen werden, bei Diebstahl bis zum Ablauf gültig | Bei Diebstahl dauerhaft gültig, bis manuell widerrufen | Feingranular über Scopes einschränkbar, kurze Gültigkeit begrenzt Schaden |
| Typischer Einsatz | API-Zugriff nach Login, Machine-to-Machine-Kommunikation | Server-zu-Server-Integrationen, öffentliche APIs mit Rate-Limiting | Anwendungen, die im Namen eines Nutzers auf Drittanbieter-APIs zugreifen |
Für neue Integrationen ist ein Bearer Token über OAuth in der Regel die sicherere Wahl gegenüber einem statischen API Key, da die kurze Lebensdauer das Risiko bei einem Leak deutlich reduziert. Ein API Key bleibt dort sinnvoll, wo Einfachheit wichtiger ist als Feingranularität, etwa bei internen Batch-Jobs mit begrenztem Zugriff.
Token-Validierung und Token-Ablauf
Jeder Ressourcenserver muss einen eingehenden Bearer Token vor der Verarbeitung prüfen. Bei Identifier-based Token erfolgt die Token-Validierung über einen Aufruf des Introspection-Endpoints beim Autorisierungsserver, bei Self-contained Token wie JWT direkt anhand der Signatur, ohne zusätzlichen Netzwerk-Aufruf. Wichtig ist in beiden Fällen: Die Validierung muss serverseitig erfolgen, eine reine Prüfung im Client (z. B. im Frontend) bietet keinerlei Sicherheit, da ein Angreifer diese Prüfung einfach umgeht.
Für Token-Ablauf und Refresh Token gelten folgende Best Practices:
- Kurze Token-Lebensdauer wählen (typisch 15 Minuten bis 1 Stunde), damit ein gestohlener Token nur begrenzt nutzbar ist.
- Refresh Token mit Rotation einsetzen: Bei jeder Erneuerung wird ein neuer Refresh Token ausgegeben, der alte wird ungültig.
- Abgelaufene oder widerrufene Token serverseitig konsequent ablehnen, nicht nur clientseitig ignorieren.
- Refresh Token sicher speichern (z. B. httpOnly-Cookie), niemals im lokalen Speicher des Browsers.
OAuth
Lassen Sie uns nun näher auf die Verwendung von tokenbasierten Authentifizierungsverfahren mit Bearer-Tokens eingehen. Wie oben beschrieben, wird ein Token verwendet, um Nutzer zu authentifizieren. Im Gegensatz zur Basic Authentifizierung, wo ein einfaches Passwort verwendet wird, ist aber noch nicht klar, wie man dieses Token erhält.
Es gibt verschiedene Arten von Protokollen, die auf HTTP aufbauen und eine tokenbasierte Authentifizierung verwenden. Eines der am weitesten verbreiteten ist OAuth. OAuth ermöglicht es Clients, auf geschützte Ressourcen zuzugreifen, indem sie einen Access-Token in Form einer Zeichenkette erhalten, anstatt die Benutzeranmeldeinformationen direkt zu verwenden.
Token werden von einem Autorisierungsserver mit Genehmigung des Resource-Owners an Clients ausgegeben. Der Client verwendet das Access-Token, um auf die geschützten Ressourcen zuzugreifen, die von dem Ressourcen-Server gehostet werden.
Im Allgemeinen muss ein Client, bevor er auf eine geschützte Ressource zugreifen kann, zunächst einen Authorization-Grant vom Resource-Owner einholen und diese Berechtigung dann gegen ein Access-Token austauschen. Das Access-Token repräsentiert den Geltungsbereich, die Dauer und andere Attribute, die durch den Authorization-Grant gewährt werden. In einigen Fällen kann ein Client seine eigenen Anmeldeinformationen direkt an einen Autorisierungsserver übermitteln, um ein Access-Token zu erhalten, ohne zuvor eine Authorization-Grant vom Eigentümer der Ressource einholen zu müssen.
Die nachfolgende Illustration bildet diesen Ablauf ab.
Die technische Dokumentation finden Sie unter RFC 6749.
Beispiel
Angenommen, wir verwenden eine Webanwendung zur Bearbeitung einiger Dateien und möchten diese Dateien in unserer Dropbox speichern. Außerdem möchten wir unsere Webanwendung zur Bearbeitung von Dateien authentifizieren und ihr mit unseren Google Mail-Anmeldedaten Zugriff auf unsere Dropbox-API geben.
In diesem Szenario haben wir:
Client = editing web application
Authorization grant server = web-browser (e.g chrome)
Authorization server = google mail
Resource server = Dropbox
- Der Client fordert die Autorisierung über den Webbrowser an, indem er einen Redirect-URI, eine Client-ID und einen Anfragebereich sendet.
- Der Webbrowser verwendet die Redirect-URI, um Client-Identifier und Scope an den Autorisierungsserver zu senden.
- Der Resource-Owner, der die Datei bearbeitet, muss die Google-Mail Anmeldedaten angeben, um sich beim Autorisierungsserver zu authentifizieren.
- Der Autorisierungsserver sendet eine Authorization-Grant an den Webbrowser zurück.
- Die Authorization-Grant wird an den Client weitergeleitet.
- Der Client sendet die Authorization-Grant an den Autorisierungsserver.
- Der Autorisierungsserver sendet einen Access-Token an den Client in der Annahme, dass der Authorization-Grant gültig ist.
- Der Client sendet das Access-Token an den Ressourcenserver.
- Der Ressourcenserver sendet die Ressource an den Client in der Annahme, dass das Token gültig ist.
Beachte:
- Es gibt verschiedene Grant-Typen. Je nach Anwendungsfall wird ein bestimmter Grant-Typ für die Autorisierung verwendet. Siehe grant-types.
- Am Ende eines OAuth-Autorisierungsablaufs muss der Ressourcenserver das vom Autorisierungsserver vergebene Access-Token validieren. Je nach Art des Access-Tokens kann es verschiedene Bewertungsmethoden geben.
- Bei allen Anfragen handelt es sich in der Regel um HTTP-Anfragen, sodass die Autorisierung im Allgemeinen über den oben beschriebenen HTTP-Header erfolgt.
Access-Token
Ein OAuth Access-Token ist eine Zeichenkette, die der OAuth-Client verwendet, um Anfragen an den Ressourcenserver zu stellen. Access-Token müssen nicht in einem bestimmten Format vorliegen, und in der Praxis haben verschiedene OAuth-Server viele verschiedene Formate für ihre Access-Token gewählt.
Es gibt eine Reihe von Eigenschaften von Access-Token, die für das Sicherheitsmodell von OAuth von grundlegender Bedeutung sind:
- Access-Token dürfen nicht vom OAuth-Client gelesen oder interpretiert werden. Der OAuth-Client ist nicht der Adressat des Tokens.
- Access-Token übermitteln dem OAuth-Client weder die Benutzeridentität noch andere Informationen über den Benutzer.
- Access-Token sollten nur für Anfragen an den Ressourcenserver verwendet werden. Außerdem dürfen ID-Token nicht für Anfragen an den Ressourcenserver verwendet werden.
In den meisten Fällen handelt es sich bei dem Access-Token um einen Bearer-Token. Es gibt hauptsächlich zwei verschiedene Arten von Bearer-Token. Je nach Art des Access-Tokens wertet der Ressourcenserver das Token unterschiedlich aus.
Identifier-based
Das Token stellt eine schwer zu erratende Zeichenfolge dar, die ein Schlüssel zu einem Datensatz in der Datenbank des Autorisierungsservers ist. Ein Ressourcenserver validiert ein solches Token durch einen Aufruf an den Introspection-Endpoint des Autorisierungsservers.
Self-contained
Das Token kodiert die gesamte Autorisierung in sich selbst und ist kryptografisch gegen Manipulationen geschützt. JSON Web Token (JWT) hat sich zum De-facto-Standard für in sich geschlossene Token entwickelt.
Beachte: JWT-Token können sowohl als Access-Token als auch als ID-Token verwendet werden.
OpenID Connect (OIDC)
OAuth wurde ursprünglich für die Autorisierung und nicht für die Authentifizierung entwickelt. Daher ist es für den Client nicht möglich, beim Zugriff auf geschützte Ressourcen Benutzerinformationen des Resource-Owners zu erhalten.
OpenID Connect wurde entwickelt, um dieses Problem zu lösen, indem diese Authentifizierung-Layer zusätzlich zu OAuth bereitgestellt wird.
Der Autorisierungsverlauf ist mehr oder weniger derselbe wie im obigen OAuth-Fall, bei dem ein Client auf die geschützte Ressource zugreift, indem er einen Autorisierungsserver verwendet, der ihm den Zugriff über ein Zugriffstoken gewährt. Der Hauptunterschied besteht jedoch darin, dass der Autorisierungsserver dem Client mit einem ID-Token in Form eines JWT-Tokens zusätzliche Informationen, wie zum Beispiel Benutzerinformationen liefert. Siehe OpenID Intro.
Die technische Dokumentation finden Sie unter OpenID.
JWT
JSON Web Token (JWT) ist ein offener Standard, der eine kompakte und in sich geschlossene Methode zur sicheren Übertragung von Informationen zwischen Parteien in Form eines JSON-Objekts definiert. Diese Informationen können überprüft und als vertrauenswürdig eingestuft werden, da sie digital signiert sind. JWTs können mit einem geheimen (mit dem HMAC-Algorithmus) oder einem öffentlichen/privaten Schlüsselpaar (mit RSA oder ECDSA) signiert werden.
Wenn Token mit öffentlichen/privaten Schlüsselpaaren signiert werden, bestätigt die Signatur auch, dass nur die Partei, die den privaten Schlüssel besitzt, diejenige ist, die sie signiert hat.
Die JWT-Struktur ist folgende
- Header
- Type
- Signing Algorithm (SN)
- Payload
- Registered claims
- Public claims
- Private claims
- Signature
Wobei sich Signature folgendermaßen zusammensetzt.
SN(base64(header) + "." + base64(payload), secret)Beim Senden eines JWT-Tokens mit HTTP werden alle drei Teile Base64-kodiert und zu einer Zeichenkette zusammengefügt. Z.B.
Authorization: Bearer xxxx.yyyy.zzzz
where xxxx = base64(Header)
yyyy = base64(payload)
zzzz = base64(Signature)Die technische Dokumentation finden Sie unter JWT.
SAML
Die Security Assertion Markup Language (SAML) ist ein offener Federated-Identity Standard für den Austausch von Autorisierungs- und Authentifizierungsdaten zwischen einem Service-Provider (SP) und einem Identity-Provider (IDP). SAML ist ein XML-basiertes Framework und bietet wie OIDC einen einzigen Authentifizierungspunkt unter Verwendung eines Autorisierungsservers oder IDP. Daher liegt ihr Zweck wie auch bei OIDC in SSO (Single Sign On) oder allgemeiner in der Identifizierung von Benutzern.
Es gibt hauptsächlich zwei Arten von SAML-Authentifizierungsabläufen, einen vom IDP initiierten und einen vom SP initiierten Ablauf. Z.B.
Diese Illustration zeigt einen vom SP initiierten Ablauf, bei dem der Client versucht, auf eine geschützte Ressource zuzugreifen.
Dieser Fluss sieht dem oben gezeigten OIDC- oder OAuth-Fluss sehr ähnlich. Der Hauptunterschied besteht darin, dass der Zugriff auf die Ressource nicht über einen Token, sondern über eine SAML-Assertion gewährt wird. Darüber hinaus ist es im Allgemeinen bei der Verwendung von SAML der Benutzer selbst, der versucht, auf eine Ressource zuzugreifen, und daher als Client agiert. Im Falle von OIDC handelt es sich stattdessen um eine Mobile- oder Web-Anwendung.
Die technische Dokumentation finden Sie unter SAML.
SAML Assertion
SAML-Assertions sind im Vergleich zu JWT-Tokens recht komplexe XML-Dateien und werden daher hier nicht ausführlich behandelt.
Wir wollen nur erwähnen, dass SAML es einer Partei ermöglicht, Sicherheitsinformationen in Form von Aussagen über ein Subjekt zu behaupten. Die grobe Struktur sieht wie folgt aus:
<saml:Assertion>
<saml:Subject>
<saml:NameID>
...
</saml:NameID>
</saml:Subject>
<saml:AuthnStatement>
...
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute>
...
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>Das Feld Subject enthält Benutzerinformationen wie Name, E-Mail usw. Das Feld AuthnStatement kann authentifizierungsbezogene Informationen wie die Authentifizierungszeit oder die Sitzungs-ID enthalten. Das Feld AttributeStatement enthält themenbezogene Attribute wie Statusinformationen des Benutzers usw.
Fazit
Ein Bearer Token eignet sich immer dann am besten, wenn eine Anwendung im Namen eines Nutzers auf eine API zugreift und dabei Security durch kurze Token-Lebensdauer statt durch ein dauerhaft gültiges Passwort oder einen statischen API Key gewährleistet werden soll – typischerweise in Kombination mit OAuth 2.0 für die Ausgabe und Rotation der Token. Für einfache, interne Machine-to-Machine-Aufrufe ohne Nutzerkontext reicht dagegen oft ein API Key, für Single Sign-On über Unternehmensgrenzen hinweg sind OpenID Connect oder SAML die richtige Wahl.
Bisher haben wir die verschiedenen Schemata für die Authentifizierung über HTTP und die gebräuchlichsten Protokolle, die auf HTTP aufbauen, wie OAuth, OpenID Connect, welches eine Erweiterung von OAuth und SAML ist, diskutiert.
Da OpenID Connect im Grunde genommen OAuth mit einem zusätzlichen Authentifizierung-Layer ist, reicht es am Ende aus, die Unterschiede zwischen OpenID Connect und SAML zu vergleichen.
| OpenID Connect | SAML |
| Die Authentifizierung erfolgt über ein ID-Token. Dies ist ein signiertes JSON-Dokument, das den Betreff, den Aussteller und die Authentifizierungsinformationen enthält | Die Authentifizierung erfolgt über eine „Assertion“ eines signierten XML-Dokuments mit den Informationen zum Thema (wer authentifiziert wurde) |
| Im Allgemeinen wird der Benutzer vom Client zum OpenID-Provider umgeleitet, um sich anzumelden | Im Allgemeinen wird der Benutzer vom SP zum IDP umgeleitet, um sich anzumelden. |
| Wird bei Web- und mobilen Anwendungen verwendet | Wird nur für Webanwendungen verwendet |
| JWT hat eine einfachere Struktur und ist leichter als XML |
Wer unsicher ist, ob im eigenen Anwendungsfall eher ein Bearer Token, ein API Key oder OAuth insgesamt passt, findet in der oben verlinkten Entscheidungshilfe eine konkrete Schritt-für-Schritt-Einordnung.
