API-Authentifizierung: API-Keys, JWT und OAuth 2.0 erklärt

Sobald eine API mehr tut, als öffentliche Daten auszuliefern, brauchst du eine Antwort auf zwei Fragen: Wer bist du? (Authentifizierung) und was darfst du? (Autorisierung). Die Begriffe werden oft verwechselt, sind aber strikt zu trennen. Dieser Artikel führt dich durch die gängigen Verfahren der API-Authentifizierung – von simplen API-Keys über JSON Web Tokens bis zu OAuth 2.0 – und zeigt, wann welches Verfahren das richtige ist.

Authentifizierung ist nicht Autorisierung

Stell dir ein Bürogebäude vor: Die Authentifizierung ist der Ausweis am Empfang, der beweist, wer du bist. Die Autorisierung ist die Frage, welche Türen sich für dich öffnen. Eine API muss beides leisten. Du kannst korrekt authentifiziert sein (gültiger Token) und trotzdem keinen Zugriff auf eine bestimmte Ressource haben (fehlende Berechtigung) – das ist der Unterschied zwischen den HTTP-Codes 401 und 403.

API-Keys: Einfach, aber begrenzt

Der schlichteste Ansatz ist ein API-Key – eine lange, zufällige Zeichenkette, die der Client bei jeder Anfrage mitschickt, üblicherweise in einem Header wie Authorization: Bearer <key> oder X-API-Key. Der Server prüft den Schlüssel gegen eine Datenbank und ordnet ihn einem Konto zu.

API-Keys eignen sich gut für die Kommunikation zwischen Servern (Machine-to-Machine), etwa wenn dein Backend eine fremde API anspricht. Ihre Grenzen:

• Sie identifizieren eine Anwendung, nicht einen einzelnen Endnutzer.
• Wer den Schlüssel kennt, hat vollen Zugriff – er muss daher geheim bleiben und gehört niemals in Frontend-Code oder ein öffentliches Git-Repository.
• Es gibt keine eingebaute Ablaufzeit; bei Verlust musst du den Schlüssel manuell rotieren.

Generiere API-Keys mit ausreichender Entropie. Ein sicherer, langer Zufallswert lässt sich bequem mit dem Passwort-Generator aus unseren Webtools erzeugen.

Basic Authentication: Der Klassiker

HTTP Basic Auth überträgt Benutzername und Passwort, getrennt durch einen Doppelpunkt und Base64-kodiert, im Authorization-Header. Wichtig zu verstehen: Base64 ist keine Verschlüsselung, sondern nur eine Kodierung, die jeder rückgängig machen kann. Basic Auth ist deshalb ausschließlich über HTTPS vertretbar, wo der Transport verschlüsselt ist. Für moderne APIs ist es selten die erste Wahl, weil bei jeder Anfrage die echten Zugangsdaten mitfliegen.

JSON Web Tokens (JWT)

JWT ist das Arbeitspferd moderner APIs. Ein JWT ist ein signierter, in sich geschlossener Token, der die Identität und Berechtigungen eines Nutzers enthält. Der große Vorteil: Der Server muss nach dem Login keinen Sitzungszustand speichern – die Information steckt im Token selbst. Das passt perfekt zur zustandslosen Natur von REST.

Der dreiteilige Aufbau

Ein JWT besteht aus drei Base64URL-kodierten Teilen, getrennt durch Punkte:

• Header – nennt den Signaturalgorithmus, etwa HS256 oder RS256.
• Payload – die sogenannten Claims: Nutzer-ID, Rollen, Ablaufzeitpunkt (exp), Aussteller (iss) und mehr.
• Signatur – die kryptografische Prüfsumme über Header und Payload, mit der der Server die Echtheit verifiziert.

Der entscheidende Punkt: Die Signatur garantiert, dass niemand den Inhalt manipuliert hat. Aber der Payload ist nicht verschlüsselt – jeder kann den mittleren Teil dekodieren und lesen. Schreibe deshalb niemals Geheimnisse wie Passwörter in einen JWT.

Risiken und Stolperfallen bei JWT

• Setze immer eine kurze Ablaufzeit. Ein gestohlener Token ist gültig, bis er abläuft – und JWTs lassen sich nicht ohne Weiteres widerrufen, weil der Server sie ja nicht speichert.
• Lehne den Algorithmus none ab. Eine berüchtigte Schwachstelle entstand, weil manche Bibliotheken unsignierte Tokens akzeptierten. Erzwinge serverseitig einen festen Algorithmus.
• Speichere Tokens im Browser sicher. In localStorage sind sie anfällig für XSS-Angriffe. Ein HttpOnly-Cookie ist oft die sicherere Wahl.
• Halte den Payload klein. Der Token reist bei jeder Anfrage mit; ein überladener Token kostet Bandbreite.

Access Token und Refresh Token

Das Dilemma kurzer Ablaufzeiten löst ein Zwei-Token-Modell. Der kurzlebige Access Token (etwa 15 Minuten gültig) wird bei jeder Anfrage mitgeschickt. Läuft er ab, holt der Client mit einem langlebigen, sicher gespeicherten Refresh Token einen neuen Access Token, ohne dass sich der Nutzer erneut anmelden muss. Den Refresh Token kannst du serverseitig führen und damit gezielt widerrufen – das schließt die Lücke der Nicht-Widerrufbarkeit.

OAuth 2.0: Zugriff ohne Passwortweitergabe

OAuth 2.0 löst ein anderes Problem: Wie kann eine App im Namen eines Nutzers auf einen fremden Dienst zugreifen, ohne dessen Passwort zu kennen? Genau das passiert beim „Mit Google anmelden"-Button. Du tippst dein Google-Passwort nur bei Google ein; die App bekommt lediglich einen begrenzten Zugriffstoken.

OAuth definiert vier Rollen: den Resource Owner (der Nutzer), den Client (die anfragende App), den Authorization Server (der Token ausstellt) und den Resource Server (der die Daten hält). Der wichtigste Ablauf ist der Authorization Code Flow:

1. Die App leitet den Nutzer zum Authorization Server (z. B. Google) weiter.
2. Der Nutzer meldet sich dort an und stimmt dem Zugriff zu.
3. Der Server schickt einen kurzlebigen Authorization Code an die App zurück.
4. Die App tauscht diesen Code serverseitig gegen einen Access Token ein.
5. Mit dem Token greift die App auf die freigegebenen Daten zu.

Für öffentliche Clients wie Single-Page-Apps und Mobile-Apps ist die Erweiterung PKCE (Proof Key for Code Exchange) heute Pflicht – sie verhindert das Abfangen des Codes. Der frühere „Implicit Flow" gilt als veraltet und sollte nicht mehr verwendet werden.

OpenID Connect: Login auf OAuth-Basis

OAuth 2.0 regelt nur die Autorisierung – es sagt nichts darüber, wer der Nutzer ist. OpenID Connect (OIDC) ist eine dünne Schicht obendrauf, die genau das ergänzt: Sie liefert ein zusätzliches ID Token (selbst ein JWT) mit verifizierten Identitätsinformationen. Wenn du „Single Sign-On" oder „Login mit Microsoft/Google/Apple" umsetzt, ist OIDC das passende Werkzeug.

Schutzmaßnahmen, die immer gelten

• Ausschließlich HTTPS. Über unverschlüsselte Verbindungen lässt sich jeder Token mitlesen.
• Rate Limiting gegen Brute-Force-Angriffe auf Login-Endpunkte.
• Secrets niemals im Code. API-Keys und Signaturschlüssel gehören in Umgebungsvariablen oder einen Secret-Manager, nicht ins Repository.
• Tokens und Schlüssel rotieren und kompromittierte Werte sofort widerrufen.
• Das Prinzip der minimalen Rechte: Jeder Token sollte nur die Berechtigungen tragen, die er wirklich braucht.

Wer Logins mit Passwörtern speichert, sollte zudem unseren Hinweis beherzigen: Passwörter gehören nie im Klartext in die Datenbank, sondern als Hash mit einem modernen Verfahren wie bcrypt oder Argon2. Für sichere Test-Passwörter während der Entwicklung hilft erneut der Passwort-Generator.

Welches Verfahren wann?

• API-Key: Server-zu-Server, einfache Integrationen, interne Dienste.
• JWT: eigene Single-Page- oder Mobile-App mit eigenem Login.
• OAuth 2.0 / OIDC: Zugriff auf Drittanbieter-Daten oder „Login mit"-Funktionen.

Wie diese Mechanismen in das größere Bild einer sauberen Schnittstelle passen, zeigt unser Leitfaden zu REST-API-Design.

Häufige Fragen

Ist ein JWT verschlüsselt?

Nein, standardmäßig nicht. Ein JWT ist nur signiert – das schützt vor Manipulation, nicht vor dem Mitlesen. Jeder kann den Payload dekodieren. Schreibe deshalb keine Geheimnisse hinein und nutze immer HTTPS.

Wie widerrufe ich einen JWT vor seinem Ablauf?

Direkt geht das nicht, weil der Server keinen Zustand führt. Übliche Lösungen sind sehr kurze Ablaufzeiten kombiniert mit widerrufbaren Refresh Tokens oder eine serverseitige Sperrliste (Denylist) für ungültig gemachte Tokens.

Brauche ich für „Login mit Google" eigenes OAuth?

Du musst OAuth nicht selbst implementieren, aber du integrierst es. In der Praxis nutzt man fertige Bibliotheken oder Identity-Provider, die den Authorization Code Flow mit PKCE korrekt umsetzen – das selbst zu bauen ist fehleranfällig.

Wo speichere ich Tokens im Frontend am besten?

Für Web-Apps gelten HttpOnly-Cookies als sicherer gegenüber XSS als localStorage, erfordern dafür aber CSRF-Schutz. Es gibt keine perfekte Lösung; wichtig ist, die Risiken zu kennen und Tokens kurzlebig zu halten.