Was ist API-Zugriff? Keys, OAuth und Tokens

Was ist API-Zugriff?

API-Zugriff regelt, wer eine API aufrufen darf und was jeder Aufrufer tun darf. Ein Client weist seine Identität mit einem Zugangsdatum wie einem API-Key oder Access Token nach (Authentifizierung), und die API prüft die Rechte dieser Identität für die angefragte Aktion (Autorisierung). Dadurch sind auch Rate Limits, Abrechnung und Audit-Logs pro Nutzer möglich.

Authentifizierung und Autorisierung

• Authentifizierung (AuthN): Wer ruft auf? Ein gültiger Key oder ein gültiges Token beantwortet das.
• Autorisierung (AuthZ): Darf dieser Aufrufer das tun? Ein gültiger Key kann bei DELETE /orders/42 trotzdem abgelehnt werden, weil er nur Leserechte hat.

Sie brauchen beides. Viele echte Vorfälle sind keine gestohlenen Passwörter, sondern fehlende Autorisierungsprüfungen an einem Endpunkt, der jedem gültigen Zugangsdatum vertraut. Zur Sicherheitsseite siehe API-Sicherheit.

Gängige Wege, den API-Zugriff zu steuern

API-Keys

Eine lange Zufallszeichenfolge, die jedem Nutzer zugewiesen und in einem Header wie X-API-Key gesendet wird. Einfach zu bauen und für Server-zu-Server-Aufrufe in Ordnung, aber wer den Key besitzt, hat alles, was der Key erlaubt, und ein geleakter Key funktioniert, bis Sie ihn rotieren. Details unter Was ist ein API-Key.

OAuth-2.0-Access-Tokens

OAuth 2.0 (RFC 6749, auf Englisch) lässt einen Client begrenzten Zugriff auf eine API erhalten. Das Access Token ist ein Zugangsdatum für geschützte Ressourcen und hat einen bestimmten Scope und eine bestimmte Lebensdauer. Beim Authorization-Code-Flow erteilt ein Nutzer den Zugriff, beim Client-Credentials-Flow bekommt ein vertraulicher Client wie ein Backend-Dienst mit eigenen Zugangsdaten ein Token.

JWTs

Ein JSON Web Token ist ein signiertes Token-Format, das oft für OAuth-Access-Tokens genutzt wird und Claims wie Subjekt, Scopes und Ablaufzeit enthält. Die API kann die Signatur ohne Datenbankabfrage prüfen. Die Kehrseite: Ein JWT bleibt bis zum Ablauf gültig, ein früher Widerruf erfordert also zusätzliche Infrastruktur, und der Inhalt ist für jeden lesbar, der das Token besitzt, legen Sie also nie Geheimnisse hinein. Header und Payload eines Tokens können Sie mit dem kostenlosen JWT-Decoder ansehen.

Bearer Tokens

Kein eigener Mechanismus, sondern die Art, wie die meisten Tokens gesendet werden: Authorization: Bearer <token>. Wer das Token trägt, bekommt Zugriff, es darf also nur über HTTPS übertragen werden. Siehe Bearer Token.

Mutual TLS (mTLS)

Client und Server legen beim TLS-Handshake beide X.509-Zertifikate vor, das Zertifikat ist die Identität. Das ist stark für Dienst-zu-Dienst-Verkehr, aber aufwendig im Betrieb und unpraktisch für Browser. RFC 8705 (auf Englisch) beschreibt, wie OAuth-Clients es nutzen und wie Access Tokens an ein Client-Zertifikat gebunden werden können.

Eine Beispielanfrage

GET /v1/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...

HTTP/1.1 200 OK        (gültiges Token, Scope orders:read)
HTTP/1.1 401 Unauthorized  (Token fehlt oder abgelaufen)
HTTP/1.1 403 Forbidden     (gültiges Token, Scope fehlt)

401 heißt, die API weiß nicht, wer Sie sind, 403 heißt, sie weiß es und sagt nein. Wer beides unterscheidet, spart viel Fehlersuche.

Best Practices

• Minimale Rechte. Vergeben Sie enge Scopes statt Zugangsdaten für alles.
• Kurzlebige Tokens. Kurze Access Tokens mit widerrufbaren Refresh Tokens.
• Rotieren und trennen. Keys planmäßig rotieren und pro Umgebung eigene Zugangsdaten nutzen.
• Header statt URL. Keys in Query-Strings landen in Logs, Browser-Verlauf und Proxys.
• Rate Limits pro Nutzer. Der Fehler eines Clients sollte nicht zum Ausfall für alle werden.
• Identität protokollieren. Sonst wissen Sie nicht, worauf ein geleakter Key zugegriffen hat.
• Authentifizierung gut dokumentieren. Zeigen Sie vollständige Beispielanfragen und was jedes 401 und 403 bedeutet.

Häufige Fehler

• Authentifizieren, aber nicht autorisieren, weder pro Endpunkt noch pro Objekt.
• Langlebige Tokens ohne Möglichkeit zum Widerruf.
• Ein Key für Entwicklung und Produktion.
• Geheimnisse in Client-Code, Repositories oder Support-Mails.
• Kein Umgang mit Ablauf im Client, sodass ein normaler Ablauf wie ein Ausfall aussieht.

Authentifizierte APIs testen und überwachen

Eine API, die ohne Token funktioniert, beweist nichts, Tests und Prüfungen müssen also echte Zugangsdaten nutzen. Im API-Monitoring von LoadFocus kann eine Prüfung Header und OAuth-Bearer-Tokens senden und Anfragen verketten, zum Beispiel anmelden, das Token an den nächsten Aufruf weitergeben und jeden Schritt prüfen. Ein Lasttest ohne Authentifizierung misst einen Pfad, den echte Nutzer nie gehen, und die Token-Ausgabe selbst wird oft zum Engpass. Zwei Leitfäden gehen darauf ein: API-Performance-Tests mit OAuth2 und OAuth2-Lasttests (beide auf Englisch). Siehe auch API-Monitoring.

Häufige Fragen: API-Zugriff

Was ist der Unterschied zwischen API-Key und OAuth-Access-Token?

Ein API-Key ist meist ein statisches Geheimnis, das an ein Nutzerkonto gebunden ist. Ein OAuth-Access-Token wird von einem Autorisierungsserver ausgestellt, ist kurzlebig und enthält Scopes. Nutzen Sie Keys für eigene Server-zu-Server-Integrationen und OAuth, wenn Nutzer einer Drittanbieter-App Zugriff auf ihre Daten geben.

Sind JWTs sicherer als API-Keys?

Sie haben andere Eigenschaften, sind aber nicht automatisch besser. Ein JWT trägt Ablaufzeit und Scopes und lässt sich ohne Abfrage prüfen, ist aber vor Ablauf schwer zu widerrufen. Ein Key lässt sich leicht widerrufen, läuft aber nie von selbst ab. Die Sicherheit hängt vor allem davon ab, wie Sie beides speichern, begrenzen und rotieren.

Wie widerrufe ich ein geleaktes JWT?

Entweder führen Sie serverseitig eine Sperrliste und prüfen sie bei jeder Anfrage, wodurch der zustandslose Vorteil entfällt, oder Sie halten Access Tokens kurzlebig, damit ein geleaktes schnell abläuft, und widerrufen stattdessen das Refresh Token.

Was bedeutet 401 im Vergleich zu 403?

401 Unauthorized heißt, die Anfrage hat keine gültige Authentifizierung. 403 Forbidden heißt, der Aufrufer ist authentifiziert, darf die Aktion aber nicht ausführen.

Wann sollte ich mTLS einsetzen?

Wenn beide Seiten Dienste sind, die Sie kontrollieren, und Sie eine zertifikatsbasierte Identität wollen, oder wenn eine Compliance-Vorgabe es verlangt. Vermeiden Sie es für Browser-Clients, bei denen Zertifikatsverwaltung unpraktisch ist.

Wie führe ich einen Lasttest für eine API mit Authentifizierung durch?

Nutzen Sie ein eigenes Testkonto oder einen OAuth-Client, holen Sie das Token als Teil des Tests und verwenden Sie es für mehrere Anfragen wieder, und bleiben Sie innerhalb der Grenzen dieses Kontos. Verwenden Sie nie Zugangsdaten echter Produktionsnutzer.