APIs und Authentifizierung im Jamstack

Der erste „A“-Buchstabe im Jamstack steht für „APIs“ und ist ein wichtiger Faktor dafür, was die Arbeit mit statischen Websites so leistungsfähig macht. APIs geben Entwicklern die Freiheit, Komplexität auszulagern und bieten Möglichkeiten, dynamische Funktionalität in eine ansonsten statische Website zu integrieren. Der Zugriff auf eine API erfordert oft die Überprüfung der Authentizität einer Anfrage. Dies äußert sich häufig in Form von Authentifizierung (Auth) und kann je nach verwendetem Dienst und der auszuführenden Aufgabe auf Client- oder Serverseite erfolgen. 

Angesichts des breiten Spektrums verfügbarer Protokolle unterscheiden sich APIs in ihren individuellen Auth-Implementierungen. Diese Auth-Protokolle und Implementierungsdetails stellen eine zusätzliche Herausforderung bei der Integration von APIs in eine Jamstack-Website dar. Glücklicherweise gibt es eine Methode hinter diesem Wahnsinn. Jedes Protokoll kann einem bestimmten Anwendungsfall zugeordnet werden und die Implementierung von Auth ist eine Frage des Verständnisses.

Um dies am besten zu veranschaulichen, tauchen wir in die verschiedenen Protokolle und die Szenarien ein, für die sie am besten geeignet sind.

Die Protokolle aufrufen

OAuth 2.0 ist der allgemeine Standard, dem heute die Authentifizierung folgt. OAuth ist ein recht flexibles Autorisierungsframework, das eine Reihe von Grants umfasst, die die Beziehung zwischen einem Client und einem API-Endpunkt definieren. In einem OAuth-Flow fordert eine Client-Anwendung ein Zugriffstoken von einem Autorisierungsendpunkt an und verwendet dieses, um eine Anfrage an einen API-Endpunkt zu signieren.

Es gibt vier Haupt-Grant-Typen – Authorization Code, Implicit Flow, Resource Owner Credential und Client Credentials. Wir werden jeden einzelnen betrachten.

Authorization Code Grant

Von allen OAuth-Grant-Typen ist der Authorization Code Grant wahrscheinlich der häufigste. Dieser Grant-Flow wird hauptsächlich verwendet, um ein Zugriffstoken für die Autorisierung von API-Anfragen zu erhalten, nachdem ein Benutzer explizit die Erlaubnis erteilt hat, und folgt einem zweistufigen Prozess.

• Zuerst wird der Benutzer zu einem Zustimmungsbildschirm, auch Autorisierungsserver genannt, weitergeleitet, wo er dem Dienst eingeschränkten Zugriff auf sein persönliches Konto und seine Daten gewährt.
• Sobald die Erlaubnis erteilt wurde, ist der nächste Schritt, ein Zugriffstoken vom Authentifizierungsserver abzurufen, das dann zur Authentifizierung der Anfrage an den API-Endpunkt verwendet werden kann.

Im Vergleich zu anderen Grant-Typen bietet der Authorization Code Grant eine zusätzliche Sicherheitsebene mit dem zusätzlichen Schritt der expliziten Benutzerautorisierung. Dieser mehrstufige Code-Austausch bedeutet, dass das Zugriffstoken niemals offengelegt wird und immer über einen sicheren Backchannel zwischen einer Anwendung und dem Auth-Server gesendet wird. Auf diese Weise können Angreifer ein Zugriffstoken nicht leicht durch Abfangen einer Anfrage stehlen. Google-eigene Dienste wie Gmail und Google Kalender nutzen diesen Authorization Code Flow, um auf persönliche Inhalte aus dem Konto eines Benutzers zuzugreifen. Wenn Sie diesen Workflow genauer untersuchen möchten, lesen Sie diesen Blogbeitrag, um mehr zu erfahren.

Implicit Grant

Der Implicit Grant ist dem Authorization Code Grant ähnlich, mit einem bemerkenswerten Unterschied: Anstatt dass ein Benutzer die Erlaubnis zur Abfrage eines Autorisierungscodes erteilt, der dann gegen ein Zugriffstoken ausgetauscht wird, *wird das Zugriffstoken sofort* über den Fragmentteil (Hash) der Weiterleitungs-URL (auch Front Channel genannt) zurückgegeben.

Durch den reduzierten Schritt des Autorisierungscodes birgt der Implicit Grant das Risiko, Token preiszugeben. Das Token ist aufgrund seiner direkten Einbettung in die URL (und Protokollierung im Browserverlauf) leicht zugänglich, wenn die Weiterleitung abgefangen wird.

Trotz seiner Schwachstellen kann der Implicit Grant für User-Agent-basierte Clients wie Single Page Applications nützlich sein. Da sowohl der Anwendungscode als auch der Speicher in clientseitig gerenderten Anwendungen leicht zugänglich sind, gibt es keine sichere Möglichkeit, Client-Secrets zu schützen. Der Implicit Flow ist die logische Umgehung dieses Problems, indem er Anwendungen eine schnelle und einfache Möglichkeit bietet, einen Benutzer clientseitig zu authentifizieren. Er ist auch ein valides Mittel zur Bewältigung von CORS-Problemen, insbesondere bei der Verwendung eines Drittanbieter-Auth-Servers, der keine Cross-Origin-Anfragen unterstützt. Aufgrund der inhärenten Risiken von offengelegten Token bei diesem Ansatz ist es wichtig zu beachten, dass Zugriffstoken im Implicit Flow tendenziell kurzlebig sind und keine Refresh-Token ausgestellt werden. Infolgedessen kann dieser Flow bei jeder Anfrage an eine privilegierte Ressource eine erneute Anmeldung erfordern.

Resource Owner Credential

Im Falle des Resource Owner Credential Grant senden die Ressourceneigentümer ihre Benutzername- und Passwort-Anmeldedaten an den Auth-Server, der dann ein Zugriffstoken mit einem optionalen Aktualisierungstoken zurücksendet. Da die Anmeldedaten des Ressourceneigentümers im Auth-Austausch zwischen Client-Anwendung und Autorisierungsserver sichtbar sind, muss eine Vertrauensbeziehung zwischen Ressourceneigentümer und Client-Anwendung bestehen. Obwohl offensichtlich weniger sicher als andere Grant-Typen, bietet der Resource Owner Credential Grant eine hervorragende Benutzererfahrung für First-Party-Clients. Dieser Grant-Flow ist am besten geeignet, wenn die Anwendung hochprivilegiert ist oder innerhalb des Betriebssystems eines Geräts arbeitet. Dieser Autorisierungsfluss wird oft verwendet, wenn andere Flows nicht praktikabel sind.

Client Credential

Der Client Credentials Grant-Typ wird hauptsächlich verwendet, wenn Clients ein Zugriffstoken außerhalb des Kontexts eines Benutzers abrufen müssen. Dies ist für die Machine-to-Machine-Authentifizierung geeignet, wenn die explizite Erlaubnis eines Benutzers für jeden Zugriff auf eine geschützte Ressource nicht garantiert werden kann. CLIs und im Backend laufende Dienste sind Beispiele, bei denen dieser Grant-Typ nützlich ist. Anstatt sich auf die Benutzeranmeldung zu verlassen, werden eine Client-ID und ein Secret übergeben, um ein Token zu erhalten, das dann zur Authentifizierung einer API-Anfrage verwendet werden kann.

Typischerweise wird beim Client Credential Grant ein Dienstkonto eingerichtet, über das die Anwendung läuft und API-Aufrufe tätigt. Auf diese Weise sind Benutzer nicht direkt beteiligt und Anwendungen können weiterhin Anfragen authentifizieren. Dieser Workflow ist häufig in Situationen anzutreffen, in denen Anwendungen Zugriff auf ihre eigenen Daten haben möchten, z. B. auf Analysedaten, und nicht auf spezifische Benutzerdaten.

Fazit

Angesichts der Abhängigkeit von Drittanbieterdiensten für komplexe Funktionalitäten ist eine gut durchdachte Authentifizierungslösung entscheidend für die Sicherheit von Jamstack-Websites. APIs, die die vorherrschende Methode zum Datenaustausch im Jamstack sind, sind ein wichtiger Teil davon. Wir haben vier verschiedene Methoden zur Authentifizierung von API-Anfragen untersucht, jede mit ihren Vorteilen und Auswirkungen auf die Benutzererfahrung.

Wir haben eingangs erwähnt, dass dies die vier Hauptformen der Authentifizierung sind, die für die Anforderung von Daten von einer API verwendet werden. Es gibt noch viele weitere Typen, die schön auf oauth.net beschrieben sind. Die Website als Ganzes ist ein hervorragendes Detail zu nicht nur den verfügbaren Auth-Typen, sondern zum OAuth-Framework als Ganzem.

Bevorzugen Sie eine Methode gegenüber einer anderen? Haben Sie ein Beispiel im Einsatz, auf das Sie verweisen können? Teilen Sie es in den Kommentaren!