API-Schlüssel oder OAuth für Drittanbieter-Integrationen

Worum es geht

Ein API-Schlüssel ist ein statisches Geheimnis, das einer Anwendung ausgestellt und bei jeder Anfrage mitgesendet wird. Das OWASP REST Security Cheat Sheet (zitiert) stellt Schlüssel als Kontrolle gegen Farming und Missbrauch und als Grundlage für Nutzungspläne dar, weist darauf hin, dass an Drittanbieter-Clients ausgestellte Schlüssel vergleichsweise leicht kompromittiert werden können, und rät davon ab, sich zum Schutz sensibler, kritischer oder hochwertiger Ressourcen ausschliesslich auf API-Schlüssel zu verlassen. OAuth 2.0 (RFC 6749, zitiert) adressiert ein anderes Problem: einer Drittanbieter-Anwendung Zugriff auf die Ressourcen einer Nutzerin oder eines Nutzers zu geben, ohne deren Passwort. Der RFC listet auf, was durch das Weitergeben von Passwörtern kaputtgeht, unter anderem dass Ressourcenbesitzende den Zugriff eines einzelnen Dritten nicht widerrufen können, ohne den Zugriff aller zu widerrufen. Sein Authorization-Code-Grant stellt abgegrenzte Access-Tokens und Refresh-Tokens aus; RFC 6750 (zitiert) legt fest, wie das resultierende Bearer-Token im Request-Header-Feld Authorization übermittelt wird.

Warum es wichtig ist

Wer sich für Schlüssel bei einem delegierten Anwendungsfall entscheidet, zwingt Nutzende dazu, ihre Zugangsdaten oder einen allmächtigen Schlüssel an Integratoren weiterzugeben. Wer sich für OAuth bei einer reinen Server-zu-Server-Integration entscheidet, fügt Weiterleitungen und Token-Handling hinzu, die niemand braucht.

So wird es angewendet

• Der Integrator handelt für sich selbst (eigene Daten, Abrechnung, Kontingente): ein API-Schlüssel, oder der OAuth-Client-Credentials-Grant, falls bereits ein Autorisierungsserver betrieben wird.
• Der Integrator handelt für die eigenen Nutzenden: OAuth Authorization Code mit Scopes; native Clients und Single-Page-Clients ergänzen PKCE.
• In jedem Fall: Zugangsdaten in einem Header senden, nie in der URL, da OWASP darauf hinweist, dass URLs in Logs landen; das Geheimnis bei der Erstellung nur einmal anzeigen und nur einen Hash speichern; Besitzende jede Zugangsdaten-Kennung benennen, rotieren und widerrufen lassen; bei fehlenden oder ungültigen Zugangsdaten mit 401 antworten, bei unzureichendem Scope mit 403.
• Schlüsseln ein erkennbares Präfix geben, das Typ und Umgebung kodiert, damit durchgesickerte Schlüssel von Scannern gefunden und widerrufen werden können.
• Rate-Limiting und Auditierung je Zugangsdaten-Kennung durchführen, nicht je Konto, damit sich eine kompromittierte Integration allein abschalten lässt.

Stolpersteine

Langlebige, nicht eingeschränkte Schlüssel, die in Browsercode eingebettet sind. OAuth-Ressourcenserver, die das Token validieren, aber die Scope-Prüfung auslassen. Einen Schlüssel als Authentifizierung einer Person behandeln; er identifiziert eine Anwendung. OAuth allein aus dem RFC implementieren, statt einen gepflegten Autorisierungsserver einzusetzen.