Fünf Strategien für die REST-API-Authentifizierung

Basisauthentifizierung

Die Basisauthentifizierung ist ein HTTP-basierter Authentifizierungsansatz und die einfachste Methode zur Sicherung von REST APIs. Sie verwendet ein Base64-Format zur Verschlüsselung von Benutzernamen und Kennwörtern, die beide im HTTP-Header gespeichert werden. Dies ist ein effektiver Ansatz, um verschiedene API-Zugangsdaten einzurichten, wenn eine Anwendung vor allem leicht und einfach bleiben soll. Allerdings bietet dieser Ansatz keine sofortige Unterstützung für die Multifaktor-Authentifizierung (MFA) oder dynamische, benutzerspezifische Anmeldeinformationen, die den Einsatz zusätzlicher browserbasierter Erweiterungen und Autorisierungs-Tools erfordern würden.

Dank ihrer Einfachheit erfreut sich die Basisauthentifizierung einer breiten Unterstützung durch Entwicklungs-Toolchains, Technologien und Plattformen. Eine der größten Herausforderungen bei diesem Authentifizierungsschema besteht jedoch darin, dass sensible Anmeldedaten oft unverschlüsselt zwischen Systemen übertragen werden.

Daher ist die Verwendung von Secure Sockets Layer (SSL) und Transport Layer Security (TLS) -Kanälen ein Muss, wenn sensible Daten zwischen mehreren Webanwendungen ausgetauscht werden – insbesondere zwischen Anwendungen von Drittanbietern –, da Bedrohungsakteure den über ungesicherte Kanäle laufenden Datenverkehr abfangen und Anmeldeinformationen stehlen können.

API-Schlüssel

Der Ansatz der API-Schlüssel ist eine Variante der HTTP-Basisauthentifizierungsstrategie. Bei diesem Ansatz werden maschinell generierte Zeichenfolgen verwendet, um eindeutige Paare von Identifizierungsdaten und API-Zugangs-Tokens zu erstellen. API-Schlüssel können als Teil des Payloads, der HTTP-Header oder des Query-Strings gesendet werden und eignen sich daher gut für Webanwendungen mit Kundenkontakt.

Der Vorteil von API-Schlüsseln besteht darin, dass sie den API-Zugang von den erforderlichen Anmeldeinformationen und Validierungstokens entkoppeln. Diese Berechtigungsnachweise und Token können bei Bedarf widerrufen und neu ausgestellt werden, zum Beispiel wenn sich die Berechtigungsstufe eines Benutzers ändert oder wenn Grund zu der Annahme besteht, dass die Informationen kompromittiert worden sind.

Leider sind API-Schlüssel mit den gleichen Risiken behaftet wie die Basisauthentifizierung, da Hacker die zugehörigen Anmeldedaten abfangen und ausnutzen könnten. Sie bieten zwar einen eindeutigen Identifizierungsmechanismus für Frontend-Benutzerinteraktionen, mit dem Berechtigungsnachweise bei Bedarf sowohl angewendet als auch widerrufen werden können, doch die Einfachheit des Designs verhindert, dass eine mehrschichtige Authentifizierung oder MFA unterstützt werden kann.

HMAC-Verschlüsselung

Eine andere Form der REST-API-Authentifizierung, bekannt als Hash-based Message Authentication Code (hashbasierter Nachrichtenauthentifizierungscode, HMAC), wird häufig verwendet, wenn die Integrität der Nutzdaten der REST API eine Priorität darstellt. HMAC verwendet symmetrische Verschlüsselung – manchmal auch als Ein-Schlüssel-Verschlüsselung bezeichnet -, um den Hash-Wert der Nutzdaten einer REST API zu bestimmen. Anschließend wird ein eindeutiger Code generiert, der mit diesem Hashing verbunden ist, und dieser Code wird an die entsprechenden Nachrichten angehängt. Der Aufrufer und der Empfänger teilen sich den Schlüssel und verwenden ihn, um die Integrität der Daten innerhalb der Nutzdaten zu gewährleisten.

Zur Veranschaulichung hier ein einfaches Beispiel für HMAC-Authentifizierung:

• Ein Entwickler verwendet URL-Adressen, um den Zugriff auf die Daten einer REST API zu ermöglichen, möchte aber, dass diese URLs nach einer bestimmten Zeit ablaufen.
• Die Sitzungsdauer und der Ablaufzeitstempel werden in die URL eingefügt und mit einem HMAC-Schlüssel signiert.
• Der Client-Server, der die API aufruft, verwendet den in die URL-Adresse eingebetteten Verschlüsselungsschlüssel, um die Daten-Nutzdaten zu validieren. Sowohl der Client als auch der Server kennzeichnen die URL als abgelaufen, wenn die angegebene Zeitspanne verstrichen ist.
• Wenn der Client oder Server unerwartete Änderungen an der URL feststellt oder eine Nachricht empfängt, die eine zuvor abgelaufene URL verwendet, wird die API auf eine fehlende Schlüsselsignatur aufmerksam gemacht und aufgefordert, Zugriffsanfragen zu verweigern.
• Der HMAC-Ansatz für die REST-API-Authentifizierung erfordert nur einen geringen betrieblichen Aufwand in Bezug auf Verwaltung oder Tooling. Er ist in Szenarien nützlich, in denen Sie sowohl die beteiligten Client- als auch Serveranwendungen direkt kontrollieren können. Es kann jedoch schwierig werden, Verschlüsselungsschlüssel sicher zu speichern, wenn es um mobile und Webanwendungen geht, die sich Ihrer Kontrolle entziehen.

Eine mobile Anwendung, die URL-basierte HMAC-Verschlüsselungsschlüssel zur Erleichterung von Datenanfragen verwendet, ist beispielsweise ein anfälliges Ziel für Angriffe, insbesondere wenn diese Verschlüsselungsschlüssel keinen festen Zeitrahmen für den Ablauf enthalten. Wenn ein Bedrohungsakteur diesen eindeutigen Schlüssel erlangt, kann er die Anwendung leicht dazu zwingen, eine bösartige Datennutzlast zu akzeptieren, indem er den gestohlenen Verschlüsselungscode einfach in die URL einbettet.

OAuth 2.0

OAuth (insbesondere OAuth 2.0) gilt als Goldstandard für die REST-API-Authentifizierung, insbesondere in Unternehmensszenarien mit anspruchsvollen Web- und Mobilanwendungen. OAuth 2.0 kann dynamische Sammlungen von Benutzern, Berechtigungsstufen, Umfangsparametern und Datentypen unterstützen. Es ist ein bevorzugter Ansatz für Unternehmen, die eine große Anzahl von REST APIs mit sensiblen Daten sichern möchten.

OAuth 2.0 erstellt gesicherte Zugriffstoken, die in regelmäßigen Abständen mit einer Reihe von verfahrenstechnischen Überprüfungsprotokollen, den so genannten Grant Types, erneuert werden. Diese Grant Types fungieren als Proxy-Authentifizierungsmechanismen, die den Fluss der API-Zugriffsanfragen lenken, ohne die zugrunde liegenden Anmeldedaten, Token und andere Authentifizierungsinformationen, die mit diesen Anfragen verbunden sind, offenzulegen.

Die fünf wichtigsten Grant Types in OAuth 2.0 sind:

• Autorisierungscode
• Proof Key for Code Exchange (PKCE)
• Clientberechtigungsnachweise
• Gerätecode
• Token auffrischen

Neben der Wiederverwendung von Zugriffsschlüsseln unterstützt OAuth das Konzept der Geltungsbereiche (Scopes), eine Methode zur Einschränkung des Zugriffs einer Anwendung auf das Konto eines Benutzers und die zugehörigen Anmeldedaten. Auf diese Weise lässt sich steuern, in welchem Umfang Drittanbieteranwendungen auf die Kontodaten eines Benutzers zugreifen können. Ein weiterer Vorteil dieses Ansatzes ist die Möglichkeit, mehrere Bereiche zu definieren und eindeutige Token für verschiedene Arten von Anfragen und Berechtigungsstufen auszustellen.

OAuth kann ein JSON Web Token (JWT) verwenden, um die Integrität der Nutzdaten mit einem Verfahren zu prüfen, das dem im letzten Abschnitt beschriebenen HMAC-Authentifizierungsansatz ähnelt. JWT-Tokens speichern sicher verschlüsselte, benutzerspezifische Daten und übertragen diese Daten dann bei Bedarf zwischen Anwendungen. Da die Web Tokens signiert werden können, ist es möglich, dem Token neue Benutzerrollen und Berechtigungen zuzuweisen, sobald der Benutzer authentifiziert wurde. Token können nach Belieben ungültig gemacht oder recycelt werden.

Durch Hinzufügen eines gemeinsamen symmetrischen Schlüssels für alle Anwendungsdienste kann die Integrität des Tokens von allen beteiligten Diensten gleichzeitig überprüft werden, anstatt durch eine Reihe von Validierungsprüfungen. Dies mindert das Risiko, dass ein einzelner Fehler im Validierungsprozess entsteht. Wie in den vorangegangenen Abschnitten beschrieben, ist die Verwaltung der Verteilung von symmetrischen Schlüsseln, die für die Integritätsprüfung der Nutzdaten erforderlich sind, in dynamischen, hoch skalierbaren Anwendungsumgebungen jedoch eine große Sicherheitsherausforderung.

OpenID Connect

OpenID Connect ist ein offenes Standard-Authentifizierungsprotokoll, das auf OAuth 2.0 aufsetzt. Es bietet eine einfache Möglichkeit für eine Client-Anwendung, die als Relying Party (RP) bezeichnet wird, die Identität eines Benutzers zu überprüfen. Dieser einheitliche Standard erleichtert den Informationsaustausch, ohne dass eine explizite Verwaltung von Anmeldeinformationen für Anwendungen von Drittanbietern erforderlich ist.

REST APIs, die von OpenID Connect abgedeckt werden, sind nutzbar, sobald die Benutzer durch den RP authentifiziert wurden. Schließlich kann die API, die mit diesem RP verbunden ist, eine Validierung unter Verwendung ihrer eigenen Variation der oben erwähnten OAuth-Grant-Types durchführen. Diese Grant Types sind:

• Berechtigungscode
• Implizit
• Hybrid

Während OpenID Connect immer unter der Kontrolle des API-Anbieters steht, können mehrere RP diese Grant Types je nach Bedarf selbst verwenden. Dieser Ansatz ist ideal für REST-API-Anbieter, die die Komplexität dynamischer Tools für die Verwaltung von Anmeldeinformationen auf Unternehmensebene nicht unterstützen können, aber Benutzerdaten sicher für eine Vielzahl von Webanwendungen von Drittanbietern freigeben müssen.

Auswahl eines REST-API-Authentifizierungsansatzes

Angesichts der Vielzahl von REST-API-Authentifizierungsansätzen sollten Sie die Vor- und Nachteile jedes Ansatzes im Hinblick auf Ihre individuellen Anwendungsanforderungen sorgfältig abwägen, bevor Sie ihn übernehmen. Der auf HTTP ausgerichtete Ansatz der Basisauthentifizierung eignet sich hervorragend für die Einschränkung des öffentlichen Zugriffs auf Daten und Ressourcen mit geringem Risiko, erfordert aber dennoch zumindest ein gewisses Maß an Sicherheitskontrollen. API-Schlüssel eignen sich hingegen für Szenarien, in denen API-Anbieter einzelne Verbraucher identifizieren und deren Berechtigungen nach Bedarf regeln müssen.

Die Sensibilität der Daten ist ein wichtiger Bestandteil der Entscheidung. Während HMAC ein angemessenes Maß an Datenintegrität für einfache Vorgänge bietet, eignet sich OAuth besser für komplexe Anwendungsfälle, die rotierende Zugriffstoken und anpassbare Berechtigungsstufen umfassen. Für diejenigen, die sich in der Mitte befinden, bietet OpenID ein gutes Gleichgewicht zwischen der dynamischen Zugriffsverwaltung von OAuth und der Einfachheit von HMAC.

Unabhängig vom Ansatz ist es immer eine gute Idee, die REST-API-Exposition auf gesicherte SSL- und TLS-Kanäle zu beschränken. Vermeiden Sie die Übertragung sensibler Anmeldeinformationen als eingebettete Teile von API-Nutzdaten, URLs oder Query-Strings, da Anwendungen durch automatische Protokollierungsverfahren versehentlich Kopien dieser Anmeldeinformationen speichern können. Schließlich sollten Sie Verfahren wie die Rotation von Verschlüsselungsschlüsseln automatisieren, da ein manueller Ansatz zu wiederholten Versäumnissen und Fehlern führen kann.