Authentifizierung und Autorisierung von API-Aufrufen

APIs sind weit verbreitet, und theoretisch kann jeder jede API aufrufen. Es ist jedoch die Aufgabe des API-Anbieters, sicherzustellen, dass jeder Benutzer die erforderlichen Rechte für den Zugriff auf dessen APIs hat und dem zugrunde liegenden System keinen Schaden zufügt oder die von der API bereitgestellten Daten missbraucht. Daher ist es wichtig zu wissen, wer aufruft und zu welchem Zweck. Spezifische Mechanismen für die Authentifizierung und Autorisierung von API-Aufrufen garantieren die Legitimität der Benutzer. Im Folgenden erfahren Sie, wie diese Mechanismen funktionieren.

Autorisierung vs. Authentifizierung

API-Authentifizierung und Autorisierung sind zwei Begriffe, die oft verwechselt und falsch verwendet werden. Die Abkürzung Auth (n/z) bezieht sich auf die Kombination von Authentifizierung und Autorisierung. Was genau der Unterschied zwischen Authentifizierung und Autorisierung ist, lässt sich mit folgenden zwei Fragen leicht nachvollziehen:

1. Wer ist die Person?
2. Welche Befugnisse hat die Person?

Die erste Frage bezieht sich auf die Authentifizierung des Benutzers. Dabei wird gefragt, wer die aufrufende Instanz ist und ob es sich wirklich um diese Instanz handelt.

Die Autorisierung befasst sich mit der zweiten Frage: Über welche Rechte verfügt der Aufrufer und hat er oder sie das spezielle Recht, die gewünschte Aktion durchzuführen?

Betrachtet man die obige Abbildung, könnte man sagen, dass es bei der Authentifizierung um die Frage geht, wer diese Menschen sind, damit sie sich, wenn sie durch eine Tür treten, identifizieren können, und nicht länger völlig anonym sind. Die Autorisierung von Personen gibt an, ob die betreffende Person diesen Eingang überhaupt benutzen darf.

Es gibt viele Methoden und Mechanismen zur Authentifizierung und Autorisierung. Eine davon ist das Zugriffstoken/acces token.

Autorisierungs-Framework OAuth 2.0

RFC 6749 ist das OAuth 2.0 Autorisierungs-Framework. Mit OAuth 2.0 wird einer Drittanbieter-Anwendung begrenzter Zugriff auf ausgewählte Benutzerressourcen gewährt. Das bedeutet, dass die Anwendung berechtigt ist, auf diese spezifischen Inhalte zuzugreifen.

Der logische Prozessablauf von OAuth 2.0 sieht wie folgt aus:

• Der Client bittet den Ressourceninhaber um die Erlaubnis, in seinem Namen auf die Ressourcen zuzugreifen. Der Client repräsentiert die aufrufende Anwendung. Der Ressourceninhaber erlaubt dem Client, die Anfrage zu stellen.
• Mit der Erlaubnis des Ressourceninhabers erhält der Client ein Zugriffstoken vom Autorisierungsserver. Der Autorisierungsserver kennt die Rechte und den tatsächlichen Benutzer und kann das Zugriffstoken mit den für die Anfrage erforderlichen spezifischen Rechten erstellen.
• Mit Hilfe des Zugriffstokens und den damit definierten Rechten hat der Client die Berechtigung, die eigentliche Ressource anzufordern und erhält Zugriff auf diese.

Detaillierte Informationen zu den Bedingungen und Verfahren von OAuth 2.0 finden Sie in RFC 6749.

Autorisierungs- und Zugriffstoken – JWT

JSON Web Tokens (JWTs) sind Zugriffstoken, die häufig im oben beschriebenen OAuth 2.0-Autorisierungsrahmen verwendet werden. Ein JWT ist standardisiert nach  RFC 7519. Der API-Aufrufer stellt das Zugriffstoken entweder als Zeichenfolge im Header oder als Anfrageparameter zur Verfügung. Ein API-Gateway, wie das BIS-API-Gateway, prüft den Autorisierungsteil des bereitgestellten JWT und gewährt oder verweigert den Zugriff.

Das Token stellt eine verschlüsselte Zeichenfolge dar, die aus drei Teilen (rot, violett und blau) besteht, die durch einen Punkt getrennt sind. Die Grundstruktur des Autorisierungstokens JWT ist immer die gleiche: Header.Payload.Signatur. JWTs bestehen aus mehreren Schlüssel-Werte-Paaren, die den eigentlichen Inhalt repräsentieren.

Sehen wir uns die drei JWT-Teile genauer an:

• Header: Der Header sollte mindestens die beiden Schlüssel-Wertepaare „alg“ und „typ“ enthalten. „alg“ zeigt den Verschlüsselungsmechanismus zum Signieren des Token, in diesem Fall HMAC SHA256. Andere Möglichkeiten sind RSA mit SHA256 oder ECDSA mit SHA256. Obwohl es theoretisch möglich ist, auf Verschlüsselung zu verzichten, wird davon dringend abgeraten. Ein unverschlüsseltes Token oder ein Token ohne „alg“ wird in der Regel strikt abgelehnt. „typ“ deklariert den Medientyp, der in der Regel JWT ist.
• Payload: Die Payload enthält die tatsächlich zu übertragenden Informationen, d. h. die Rechte, die für die eigentliche Berechtigung geprüft werden. Die Schlüssel-Werte-Paare der Payload werden als Claims bezeichnet. Es gibt drei Arten von Claims. Registrierte Claims sind im JSON Web Token Register hinterlegt und haben einen definierten Zweck. So steht „iss“ für den Aussteller (issuer) oder „exp“ für die Verfallszeit (expiration) des Token. Öffentliche Claims sind frei definierbar, aber um Konflikte zu vermeiden, sollten sie auch im JSON Web Token Claim Register angegeben werden. Häufig verwendete öffentliche Claims sind E-Mail oder Name. Private Claims enthalten Informationen, die speziell für den Austausch zwischen dem Anbieter der JWT und dem Benutzer der JWT ausgetauscht werden sollen.
• Signature: Die Signatur wird mit einem geheimen Schlüssel erstellt. Die Signatur zeigt, dass die JWT unterwegs nicht verändert wurde. Zu diesem Zweck werden Header und Payload mit HMAC oder RSA mit einem geheimen Schlüssel signiert.
  HMACSHA256(base64UrlEncode(header) + „.“ + base64UrlEncode(payload), secret)

Wenn das Token gültig ist und die notwendigen Ansprüche enthält, d. h. die Autorisierung des API-Aufrufs erfolgreich war, wird der API-Aufruf weitergeleitet.

Möchten Sie mehr über APIs erfahren? Lesen Sie unsere Blogs, Was ist API-Integration und Was ist API-Management sowie den nächsten Blog dieser Reihe „API-Gateway-Security“ oder unseren Leitfaden APIs – von API Management bis API Solution.