Welche Authentifizierung für eine REST-API passt, hängt davon ab, wer sie aufruft, ob Zugriff delegiert werden muss und wie viel Aufwand für Schutz, Erneuerung und Widerruf von Credentials tragbar ist. Dieser Vergleich behandelt fünf verbreitete Muster: HTTP Basic, API-Schlüssel, OAuth 2.0 mit Bearer-Token, JWT-Validierung und gegenseitiges TLS (mTLS). Die Liste ist eine praktische Auswahl, keine feststehende oder kanonische Fünferliste. Wichtig für den Vergleich: OAuth 2.0 ist ein Autorisierungsframework; JWT ist ein Tokenformat. Sie liegen daher nicht auf derselben Ebene und können zusammen eingesetzt werden.
Authentifizierung und Autorisierung sind zwei verschiedene Aufgaben
Authentifizierung prüft ein Credential oder Token und damit einen Identitäts- oder Clientanspruch. Autorisierung entscheidet anschließend, ob der Aufrufer eine bestimmte Ressource lesen oder eine bestimmte Aktion ausführen darf. Ein gültiges Credential ist deshalb keine pauschale Erlaubnis für alle API-Funktionen. Bei nicht öffentlichen REST-Diensten muss die Zugriffskontrolle für jeden geschützten Endpunkt greifen; ein zentraler Identitätsanbieter kann Tokens ausgeben, während die API die Zugriffsentscheidung für ihre Ressourcen trifft. OWASP REST Security Cheat Sheet
Die fünf Strategien im Vergleich
| Muster | Passt vor allem zu | Stärke | Grenze und Betriebsaufwand |
|---|---|---|---|
| HTTP Basic | Begrenzten, kontrollierten Integrationen mit verwalteten Credentials | Einfaches, breit verstandenes HTTP-Schema | Ein passwortähnliches Geheimnis wird bei Requests verwendet. TLS, sichere Ausgabe und Speicherung, Rotation sowie Schutz vor Brute-Force-Angriffen sind nötig. |
| API-Schlüssel | Einfacher Identifizierung oder Begrenzung eines API-Clients bei klaren Zugriffsregeln | Geringe Implementierungshürde | Ein Schlüssel kann kopiert oder offengelegt werden. Er belegt für sich allein weder eine menschliche Identität noch eine fein abgestufte Berechtigung. |
| OAuth 2.0 mit Bearer-Token | Delegiertem Zugriff, mehreren Clients oder zentraler Tokenausgabe | Trennt Client, Autorisierungsserver und geschützte Ressource | Wer das Bearer-Token besitzt, kann es verwenden. TLS, geeignete Gültigkeit, sichere Aufbewahrung und Prüfung bleiben zentral. |
| JWT-Validierung | APIs, die signierte oder MAC-geschützte Claims lokal prüfen sollen | Strukturierte Claims lassen sich anhand des Tokens validieren | JWT ist keine eigenständige Autorisierungsstrategie. Integrität, Claims, Schlüsselwechsel und Widerruf müssen berücksichtigt werden. |
| Gegenseitiges TLS (mTLS) | Dienst-zu-Dienst-Verbindungen oder Umgebungen mit hohem Bedarf an Clientbindung | Der Client weist im TLS-Handshake den Besitz eines privaten Schlüssels nach | Erfordert Betrieb für Zertifikate und private Schlüssel. Es ersetzt weder API-seitige Berechtigungsregeln noch passt es automatisch zu jedem Browser- oder Endnutzerzugriff. |
Die Tabelle ist ein qualitativer Vergleich, keine Rangliste. OAuth beschreibt, wie Autorisierung und Tokenausgabe organisiert werden können; JWT beschreibt eine mögliche Form eines Tokens. Ein OAuth-Access-Token muss nicht automatisch ein JWT sein.
Welche der fünf Strategien passt zu welchem Aufrufer?
1. HTTP Basic: für überschaubare, kontrollierte Integrationen
HTTP Basic ist ein einfaches Credential-Muster, das sich für eine begrenzte Zahl verwalteter Integrationen eignen kann. Das Geheimnis hat passwortähnlichen Charakter und muss vertraulich bleiben. Übertrage es daher nicht ungeschützt: TLS ist Voraussetzung. Sichere Ausgabe, Speicherung und Rotation sowie Schutz vor Brute-Force-Angriffen gehören ebenfalls zum Betrieb. RFC 6749 beschreibt HTTP Basic zudem als eine mögliche Methode zur Clientauthentifizierung am OAuth-Token-Endpunkt; das macht Basic allein aber nicht zu einem Delegations- oder Berechtigungsmodell. RFC 6749
#1 Best Overall
2. API-Schlüssel: für einfache Clientkennung, nicht als vollständiges Berechtigungsmodell
Ein API-Schlüssel kann einen API-Client identifizieren oder als Grundlage für einfache Begrenzungen dienen, wenn der Anbieter eindeutig festlegt, wofür der Schlüssel steht und welche Zugriffe damit erlaubt sind. Behandle ihn als Geheimnis: Wer ihn kopiert oder aus einem unsicheren Speicherort erlangt, kann ihn missbrauchen. Ein Schlüssel allein beweist nicht, welcher Mensch handelt, und sagt nicht automatisch aus, welche einzelnen Ressourcen oder Aktionen erlaubt sind. Die API muss diese Regeln selbst durchsetzen. OWASP REST Security Cheat Sheet
3. OAuth 2.0 mit Bearer-Token: wenn Zugriff delegiert und zentral gesteuert werden soll
OAuth 2.0 trennt den Client, der Zugriff anfragt, den Autorisierungsserver, der Tokens ausgibt, und den Resource Server, der die geschützte API bereitstellt. Der Client verwendet ein Access-Token gegenüber der geschützten Ressource. Welche Clientauthentifizierung eingesetzt wird, welches Format das Token hat und wie die API Berechtigungen prüft, sind dabei getrennte Designentscheidungen. Die grundlegenden Rollen und Abläufe beschreibt RFC 6749; die aktuelle recherchierte Best-Current-Practice-Empfehlung zur OAuth-Sicherheit ist RFC 9700 (2025).
Ein Bearer-Token ist praktisch, weil der API-Client es als Zugangsberechtigung vorlegen kann. Der entscheidende Nachteil: Es ist keine zusätzliche kryptografische Besitzprüfung nötig. RFC 6750 fasst das so: “Any party in possession of a bearer token (a “bearer”) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).” Deshalb müssen Access Tokens ausschließlich über TLS übertragen und vor Offenlegung geschützt werden. RFC 6750
4. JWT-Validierung: ein Token prüfen, nicht bloß decodieren
JWT ist ein Tokenformat, keine automatische Sicherheitsgarantie und keine eigenständige Authentifizierungsmethode. Ein JWT kann als Access-Token-Format in einem OAuth-System dienen, muss es aber nicht. Die API darf sich nicht darauf beschränken, den Inhalt zu decodieren: Sie muss den Integritätsschutz prüfen und die enthaltenen Claims validieren. Auch ein korrekt geschütztes Token entscheidet nicht von selbst, ob die angefragte Aktion erlaubt ist; diese Autorisierung bleibt Aufgabe der API. Schlüsselwechsel und der Umgang mit widerrufenen Tokens gehören ebenfalls in die Planung. OWASP REST Security Cheat Sheet
5. Gegenseitiges TLS (mTLS): für starke Bindung an einen Dienst-Client
Bei mTLS authentifizieren sich beide Seiten der TLS-Verbindung: Der Client weist mit einem Zertifikat und dem zugehörigen privaten Schlüssel seine Identität nach. Das eignet sich besonders für Dienst-zu-Dienst-Verbindungen, wenn die Organisation Zertifikate und private Schlüssel zuverlässig verwalten kann. RFC 8705 beschreibt außerdem, wie OAuth-Access-Tokens an ein Clientzertifikat gebunden werden können. So wird es schwieriger, ein abgegriffenes Token einfach durch einen anderen Akteur verwenden zu lassen, der den gebundenen privaten Schlüssel nicht besitzt. RFC 8705
mTLS ersetzt keine Autorisierung: Die API braucht weiterhin Regeln, die den authentifizierten Client den zulässigen Rollen, Scopes oder Ressourcen zuordnen. Der zusätzliche Schutz bringt Aufwand für Zertifikatsausgabe, Erneuerung und Schlüsselbetrieb mit sich. Die OAuth-Sicherheitsempfehlungen nennen mTLS und signierte JWTs als Beispiele asymmetrischer Clientauthentifizierung, nicht als Pflicht für jedes API-System. RFC 9700 (2025)
Quick Recap
Best Value
So treffen Sie die Auswahl
- Bestimmen Sie den Aufrufer. Handelt es sich um einen Menschen, eine Anwendung oder einen anderen Dienst? Ein Credential, das für einen verwalteten Server-zu-Server-Client vertretbar ist, passt nicht automatisch zu einer Anwendung im Browser oder auf einem Endgerät.
- Klären Sie, ob Zugriff delegiert wird. Wenn ein Client im Namen eines Nutzers oder mit zentral verwalteten Berechtigungen auf Ressourcen zugreifen soll, prüfen Sie OAuth 2.0. Für eine einfache Clientkennung ohne solche Delegation kann ein API-Schlüssel genügen, sofern die API die Zugriffsregeln separat durchsetzt.
- Bewerten Sie den möglichen Schaden eines Diebstahls. Fragen Sie, welche Ressourcen ein gestohlenes Passwort, ein Schlüssel oder ein Token erreichbar macht. Bei Bearer-Tokens reicht der Besitz zur Verwendung; bei höherem Schutzbedarf kommen sendergebundene Verfahren wie DPoP oder mTLS-gebundene Tokens infrage. OWASP OAuth2 Protocol Cheat Sheet
- Legen Sie Erneuerung und Widerruf fest. Entscheiden Sie vor dem Einsatz, wie Credentials ausgegeben, rotiert, gesperrt und bei Verdacht auf Offenlegung ersetzt werden. Bei JWT gehört dazu auch, wie Schlüsselwechsel und widerrufene Tokens behandelt werden.
- Prüfen Sie den Betriebsaufwand. Wählen Sie mTLS oder andere kryptografisch gebundene Verfahren nur, wenn Ihr Team Zertifikate, Schlüssel und die nötigen Richtlinien zuverlässig betreiben kann.
Sicherheitsregeln für jede Variante
- Übertragen Sie Passwörter, Client-Credentials sowie Access- und Refresh-Tokens nicht im Klartext. RFC 6749 verlangt TLS für die Übermittlung von Tokens und Credentials sowie TLS mit Serverauthentifizierung für OAuth-Endpunkte. RFC 6749
- Verwenden Sie Bearer-Tokens ausschließlich über TLS und behandeln Sie Logs, Fehlerberichte, Speicherorte und Ausgabekanäle als mögliche Stellen, an denen Geheimnisse offengelegt werden können. RFC 6750
- Prüfen Sie bei JWT die Integrität und Claims, statt Token-Inhalte lediglich zu decodieren; setzen Sie die Autorisierung für die angefragte Ressource und Aktion anschließend unabhängig davon durch. OWASP REST Security Cheat Sheet
- Erwägen Sie sendergebundene Tokens oder asymmetrische Clientauthentifizierung, wenn der Schutz vor Token-Diebstahl den zusätzlichen Betrieb rechtfertigt. OWASP beschreibt DPoP und mTLS-gebundene Tokens; RFC 9700 empfiehlt asymmetrische Clientauthentifizierung für geeignete Deployments. OWASP OAuth2 Protocol Cheat Sheet · RFC 9700 (2025)
- Verlassen Sie sich nicht allein auf erfolgreiche Authentifizierung: Jede geschützte Route muss die erforderliche Berechtigung für die angefragte Aktion prüfen. OWASP REST Security Cheat Sheet
Häufige Fehlentscheidungen
- OAuth und JWT als gleichartige Alternativen behandeln: OAuth organisiert Autorisierung und Tokenausgabe; JWT ist ein mögliches Tokenformat. Die API kann ein OAuth-Token im JWT-Format validieren.
- Ein gültiges Token mit ausreichender Berechtigung gleichsetzen: Authentifizierung belegt einen Anspruch; die API muss die konkrete Aktion weiterhin autorisieren.
- Ein Bearer-Token wie ein ungefährliches Kennzeichen behandeln: Jeder, der es besitzt, kann es grundsätzlich verwenden. Schutz und Transport sind daher Teil des Sicherheitsmodells.
- mTLS als Ende-zu-Ende-Autorisierung verstehen: Es authentifiziert den Client auf der TLS-Verbindung, legt aber nicht fest, welche API-Ressourcen dieser Client nutzen darf.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
