Bearer Token, OAuth2, API Keys: Welche Auth-Methode wann

Pexon Consulting | 10 Min. Lesezeit | 22.05.2026

TL;DR

Bearer Token, OAuth2, API Key, JWT, mTLS und HMAC lösen unterschiedliche Probleme. API Keys passen für Read-only-Quotas, OAuth2 Client Credentials für externe Service-APIs, mTLS für interne Hochlast-Microservices und Banking. JWT als Self-contained-Token nur signiert, kurzlebig und mit Audience-Check. Alles andere wird in der Praxis zur Lücke.

Worum geht es überhaupt — Definitionen

Auth-Diskussionen scheitern oft daran, dass alle dieselben Begriffe meinen, aber unterschiedliche Dinge davon verstehen. Bevor wir Empfehlungen geben, klären wir die Basis.

API Key ist ein statischer alphanumerischer String. Er identifiziert die App, nicht den User. Revocation läuft manuell. Wer den Key hat, darf alles, was der Key kann — bis jemand ihn rotiert.

Bearer Token ist ein opaker String im Authorization-Header. Das Prinzip: „Wer ihn hat, darf.“ Ausgegeben vom Auth-Server, kurzlebig, jederzeit widerrufbar. Der Token selbst weiß meistens nichts über sich — der Resource-Server fragt nach.

OAuth2 ist kein Token, sondern ein Framework mit verschiedenen Flows:

• Client Credentials: M2M ohne User. client_id plus client_secret direkt gegen Access Token tauschen.
• Authorization Code: User-Flow mit Browser-Redirect, Code-Exchange im Backend mit Secret.
• Authorization Code + PKCE: Für Public Clients (SPA, Mobile) ohne sicheren Secret-Storage. Code-Verifier und Code-Challenge ersetzen das Client-Secret.

JWT kommt in zwei Varianten. Als JWS ist es signiert, dreiteilig (Header.Payload.Signature), Payload lesbar, Signatur schützt vor Manipulation. RS256 ist der vernünftige Default. Als JWE ist es verschlüsselt — wenn sensible Claims im Token landen müssen, was idealerweise nicht passieren sollte.

mTLS verlangt Zertifikate auf beiden Seiten. Die Auth passiert auf dem Transport-Layer, also vor der HTTP-Anfrage. Kein Code-Pfad in der Applikation muss Token validieren.

HMAC signiert den kompletten Request — Body, Header, Timestamp — mit einem geteilten Secret. AWS SigV4 ist der bekannteste Vertreter. Replay-Schutz braucht Timestamp plus Nonce.

Decision Tree — welche Methode wann

Direkte Antwort vorweg: Es gibt nicht die eine richtige Methode. Sondern eine pro Use Case.

In unserer Erfahrung scheitern 80 Prozent der Auth-Diskussionen daran, dass eine Methode für alle Use Cases gepresst wird. Das geht selten gut aus.

Bearer Token mit OAuth2 Client Credentials — der Standard für M2M

Das häufigste Pattern in der B2B-API-Welt: Ein Backend-Service spricht eine fremde API. Keine User-Session, kein Browser, nur Maschine zu Maschine.

Der Aufruf gegen die geschützte Ressource sieht so aus:

curl -H "Authorization: Bearer eyJhbGc..." https://api.example.de/v1/users

Den Token holt sich der Client vorher vom Auth-Server:

import requests
r = requests.post("https://auth.example.de/oauth/token", data={
    "grant_type": "client_credentials",
    "client_id": CID, "client_secret": CSEC, "scope": "api:read"})
token = r.json()["access_token"]

Drei Dinge müssen in Produktion stimmen:

1. Token-Caching: Nicht für jeden Call ein neuer Token. Lebenszeit aus expires_in lesen, mit 30 Sekunden Sicherheitspuffer cachen.
2. Scope minimieren: api:read statt *. Wer mehr Scopes anfragt, als er braucht, baut sich seine eigene Privilege-Escalation.
3. Secret-Rotation: client_secret aus Vault oder Key Manager, niemals aus dem Repo.

Unsere Empfehlung: Bearer Token plus OAuth2 Client Credentials ist für externe Service-APIs der Default. Alles andere ist Begründungspflicht.

JWT verifizieren — die häufigste Fehlerquelle

Self-contained Tokens sind angenehm, weil der Resource-Server nicht bei jedem Call den Auth-Server fragen muss. Sie sind gefährlich, weil viele Implementierungen die Signatur entweder gar nicht oder falsch prüfen.

import jwt
claims = jwt.decode(token, public_key, algorithms=["RS256"],
    audience="api.example.de", issuer="https://auth.example.de")

Was hier passiert und warum jeder Parameter zählt:

• algorithms=["RS256"] — explizite Allowlist. Ohne diese Angabe akzeptieren manche Libraries auch alg: none und der Token wird ohne Signatur valide.
• audience — sonst kann ein Token, der für api-internal ausgestellt wurde, gegen api-public verwendet werden.
• issuer — sonst akzeptiert die API Token von beliebigen Issuern, sobald der Public Key bekannt ist.

Dazu kommt: exp muss geprüft werden (passiert mit jwt.decode automatisch), nbf wenn gesetzt, und bei sensiblen Operationen ein zusätzlicher Blacklist-Check, weil JWTs vor exp nicht trivial revoked werden können.

Wir raten von langen Access-Token-Lifetimes ab. 5 bis 15 Minuten sind das, was wir bei produktiven Setups empfehlen. Refresh-Token mit Rotation übernehmen den Rest.

mTLS — wenn das Netzwerk die Auth macht

Wer in Banking, Insurance oder kritischer Infrastruktur arbeitet, kommt an mTLS nicht vorbei. Die Auth findet vor dem ersten HTTP-Byte statt. Code-Pfade, die Token-Parsing falsch machen können, fallen weg.

Eine minimale Nginx-Config:

ssl_certificate     /etc/ssl/server.crt;
ssl_certificate_key /etc/ssl/server.key;
ssl_client_certificate /etc/ssl/ca.crt;
ssl_verify_client on;
ssl_protocols TLSv1.2 TLSv1.3;

Drei Punkte, an denen mTLS-Setups in der Praxis scheitern:

• CRL oder OCSP fehlt. Wer ein Zertifikat ausstellt, muss es auch wieder widerrufen können. Wer das auslässt, hat eine offene Tür für 365 Tage.
• Self-signed CA ohne Rotation. Funktioniert bis das CA-Zertifikat abläuft. Dann fällt der ganze Cluster gleichzeitig um.
• Kein Subject-Mapping zur Identity. Das Zertifikat sagt nur, wer sich verbindet. Welche Rolle, welche Scopes — das muss zusätzlich gemappt werden.

mTLS ist Aufwand. Lohnt sich für interne Hochlast-Microservices, Service Meshes (Istio, Linkerd machen das transparent) und überall, wo eine Aufsichtsbehörde mitliest.

Compliance — was die Regulierung verlangt

Das Thema ist trocken, aber für unsere Kunden aus Finanzdienstleistung, Energie und Gesundheit der eigentliche Treiber.

Das Mapping in der Praxis: Wer PSD2-relevante Endpoints betreibt, kombiniert mTLS auf Transport-Ebene mit OAuth2 plus SCA auf User-Ebene und kurzlebigen JWTs für die internen Service-Calls. Defense in Depth ist kein Buzzword, sondern Voraussetzung.

DORA verlangt explizit Resilienz auch bei Auth-Ausfällen. Wenn der zentrale IdP ausfällt, darf die kritische API nicht komplett still stehen — das zwingt zu Designentscheidungen wie cachebaren JWTs und Fallback-mTLS.

Anti-Patterns — was wir regelmäßig sehen

Aus unserer Beratungspraxis die Top-Fehler, die uns bei Reviews durchgängig begegnen:

API Key in der URL. Landet in Webserver-Logs, Browser-History, Proxy-Caches und Monitoring-Tools. Wir haben Kunden gesehen, deren Production-Keys in Splunk indiziert waren. Authorization-Header ist Pflicht.

Secrets im Git. GitHub-Scanning fängt einiges ab, aber nicht alles. Pre-Commit-Hooks und ein vernünftiges Secret-Management (Vault, Azure Key Vault, AWS Secrets Manager) sind die Mindestausstattung.

JWT mit alg: none akzeptieren. Sound wie ein Witz, ist es aber nicht. Mehrere Libraries hatten genau diesen Bug. Allowlist für Algorithmen ist Pflicht.

JWT-Signatur gar nicht verifizieren. Wir haben Code gesehen, der das Payload base64-decoded und die Claims gelesen hat. Ohne Signatur-Check. Das ist Spoofing-by-Design.

Token in localStorage. XSS-anfällig. Wer einen Cross-Site-Scripting-Bug findet, hat den Token. HttpOnly-Cookie mit SameSite=Strict plus CSRF-Schutz ist sicherer.

Auth-Header über HTTP. Man-in-the-Middle macht den Bearer Token zum eigenen. Klingt trivial, ist in internen Netzwerken überraschend oft vorhanden.

Langlebige Access Token. 24 Stunden, 7 Tage, manchmal „läuft nie ab“. Wer das macht, hat im Breach-Fall keine Reaktionsmöglichkeit. 5 bis 15 Minuten ist der Korridor, Refresh-Token mit Rotation darüber.

Kein aud/iss/exp-Check. Token, der für Service A ausgestellt wurde, funktioniert auch gegen Service B. Token, der vor zwei Jahren abgelaufen ist, wird trotzdem akzeptiert. Beides reale Audit-Findings aus 2025.

HMAC ohne Timestamp und Nonce. Replay-Attack: Angreifer fängt einen valid signed Request ab und spielt ihn beliebig oft ab. Timestamp im Signed-Payload plus Nonce-Tracking serverseitig ist der Fix.

mTLS ohne CRL/OCSP. Zertifikat-Diebstahl ist real. Wer keinen Revocation-Mechanismus hat, lebt mit der Tür offen, bis das Zertifikat von selbst abläuft.

Eine Zahl, die das einordnet: Laut IBM Cost of a Data Breach Report 2024 liegen die globalen durchschnittlichen Breach-Kosten bei 4,88 Mio. USD. Stolen Credentials sind mit 38 bis 49 Prozent der häufigste Initialvektor — und die Detection dauert im Schnitt 292 Tage. Die Methoden hier oben sind nicht akademisch.

Was wir in Reviews konkret prüfen

Wenn wir API-Security-Reviews machen, geht die Checkliste etwa so:

• Welcher Token-Type für welchen Endpoint? Begründung?
• Wo läuft Auth-Validation? Library, Custom-Code, Gateway?
• Token-Lifetime und Refresh-Strategie?
• Wo liegen Secrets? Wer rotiert sie?
• CORS-Konfiguration — zu freizügig oder restriktiv?
• Rate Limiting pro Identity oder pro IP?
• Audit-Logging der Auth-Events?
• Was passiert bei Auth-Server-Ausfall?

Die meisten Setups schneiden in 3 bis 4 dieser Punkte nicht gut ab. Das ist keine Katastrophe, aber meistens günstig zu fixen — wenn man es vor dem Pentest macht.

Häufig gestellte Fragen

Bearer Token vs API Key — was ist sicherer?

Ein Bearer Token ist sicherer, weil kurzlebig und widerrufbar. Ein gestohlener Token läuft nach Minuten ab. Ein gestohlener API Key bleibt gültig, bis jemand ihn manuell rotiert — meistens nachdem der Schaden längst entstanden ist. API Keys sind in Ordnung für Read-only-Public-APIs mit Quota-Tracking, nicht für sensible Operationen.

Brauche ich OAuth2 oder reicht ein API Key?

Faustregel: API Key wenn der Endpoint öffentlich oder semi-öffentlich ist, keine User-Daten involviert sind und Quota-Limitierung der Hauptzweck ist. OAuth2 sobald User-Daten, Scopes oder Multi-Tenant-Zugriff im Spiel sind. In B2B-Integrationen mit Geschäftsdaten reicht ein API Key fast nie.

Unterschied Bearer Token vs JWT?

Bearer Token ist das Transport-Pattern (Authorization: Bearer ...), JWT ist ein konkretes Token-Format. Ein solcher Token kann entweder opaque sein (Auth-Server kennt den Inhalt) oder ein JWT sein (Resource-Server kann selbst dekodieren). Opaque skaliert über Introspection-Endpoint, JWT ist stateless. Beides hat Daseinsberechtigung. Bearer Token

JWT signed vs encrypted — was nehmen?

In 95 Prozent der Fälle signed (JWS) mit RS256. Encrypted (JWE) nur wenn wirklich sensible Daten im Payload landen müssen — was wir grundsätzlich vermeiden, weil Tokens nichts enthalten sollten, was nicht im Client landen darf. Wenn ein Wert wirklich sensibel ist, gehört er nicht in den Token, sondern in einen serverseitigen Lookup.

Refresh Token Pflicht?

Wenn Access Token kurzlebig sind (5-15 Min) und der User nicht alle paar Minuten neu einloggen soll: ja. Refresh Token mit Rotation, lang gespeichert nur HttpOnly-Cookie oder im Backend. In reinen M2M-Flows (Client Credentials) braucht man keinen Refresh — der Client holt sich einfach einen neuen Access Token, wenn der alte abläuft.

Nächster Schritt

Wenn API-Auth bei Ihnen historisch gewachsen ist und Sie wissen wollen, wo die echten Lücken liegen, machen wir das in einem Review fest. Wir gehen Endpoint für Endpoint durch, mappen auf die Methoden hier oben und liefern eine priorisierte Fix-Liste.

API-Security-Review für Ihre Azure-Umgebung anfragen

Verwandte Themen