Sichere cloudbasierte Anwendungen mit OAuth 2.0 und OpenID Connect

Einleitung#

Cloudbasierte Anwendungen sind heutzutage im Trend. Obwohl der Anwendungstyp variieren kann (Web, Mobil, Desktop usw.), haben sie alle ein Cloud-Backend, das Dienste wie Speicher, Rechenleistung und Datenbanken bereitstellt. Meistens benötigen diese Anwendungen, dass Benutzer authentifiziert und autorisiert werden, um auf bestimmte Ressourcen zuzugreifen.

Während selbstentwickelte Authentifizierungs- und Autorisierungsmechanismen möglich sind, ist Sicherheit zu einem der Hauptanliegen bei der Entwicklung von Cloud-Anwendungen geworden. Zum Glück hat unsere Branche erprobte Standards wie OAuth 2.0 und OpenID Connect, die uns helfen, sichere Authentifizierungs- und Autorisierungslösungen zu implementieren.

Dieser Beitrag geht von folgenden Annahmen aus:

1. Du hast ein grundlegendes Verständnis der Anwendungsentwicklung (Web, Mobil oder einer anderen Art).
2. Du hast von den Konzepten Authentifizierung und Autorisierung gehört.
3. Du hast von OAuth 2.0 und OpenID Connect gehört.

Ja, "gehört" reicht für Punkte 2 und 3 aus. Dieser Beitrag wird reale Beispiele verwenden, um Konzepte zu erklären und den Prozess mit Diagrammen zu veranschaulichen. Lass uns anfangen!

OAuth 2.0 vs. OpenID Connect#

Wenn du mit OAuth 2.0 und OpenID Connect vertraut bist, kannst du auch weiterlesen, da wir in diesem Abschnitt einige reale Beispiele behandeln werden. Wenn du neu in diesen Standards bist, kannst du ebenfalls weiterlesen, da wir sie auf einfache Weise einführen werden.

OAuth 2.0#

OAuth 2.0 ist ein Autorisierungs-Framework, das es einer Anwendung ermöglicht, im Namen eines Benutzers oder der Anwendung selbst begrenzten Zugriff auf geschützte Ressourcen in einer anderen Anwendung zu erhalten. Die meisten beliebten Dienste wie Google, Facebook und GitHub verwenden OAuth 2.0 für soziale Logins (z.B. „Mit Google einloggen“).

Zum Beispiel habt du eine Webanwendung namens MyApp, die auf den Google Drive eines Benutzers zugreifen möchte. Anstatt den Benutzer zu bitten, seine Google Drive-Anmeldedaten zu teilen, kann MyApp OAuth 2.0 verwenden, um im Namen des Benutzers Zugriff auf Google Drive anzufordern. Hier ist ein vereinfachter Ablauf:

In diesem Ablauf sieht MyApp niemals die Google Drive-Anmeldedaten des Benutzers. Stattdessen erhält es ein Zugangstoken von Google, das es ermöglicht, im Namen des Benutzers auf Google Drive zuzugreifen.

In OAuth 2.0-Begriffen ist MyApp der Client, Google ist sowohl der Autorisierungsserver als auch der Ressourcenserver der Einfachheit halber. In der realen Welt haben wir oft separate Autorisierungs- und Ressourcenserver, um eine Single Sign-On (SSO)-Erfahrung zu bieten. Zum Beispiel ist Google der Autorisierungsserver und hat möglicherweise mehrere Ressourcenserver wie Google Drive, Gmail und YouTube.

Beachte, dass der tatsächliche Autorisierungsablauf komplexer ist als dies. OAuth 2.0 hat verschiedene Grant-Typen, Scopes und andere Konzepte, die beachtet werden sollten. Lassen uns das für den Moment beiseite legen und mit OpenID Connect weitermachen.

OpenID Connect (OIDC)#

OAuth 2.0 ist großartig für die Autorisierung, aber du hast vielleicht bemerkt, dass es keine Möglichkeit bietet, den Benutzer zu identifizieren (d.h. Authentifizierung). OpenID Connect ist eine Identitätsschicht auf OAuth 2.0, die Authentifizierungsfunktionen hinzufügt.

Im obigen Beispiel muss MyApp wissen, wer der Benutzer ist, bevor das Autorisierungsverfahren gestartet wird. Beachte, dass hier zwei Benutzer beteiligt sind: der Benutzer von MyApp und der Benutzer von Google Drive. In diesem Fall muss MyApp den Benutzer der eigenen Anwendung kennen.

Lass uns ein einfaches Beispiel ansehen, bei dem Benutzer sich mit Benutzernamen und Passwort bei MyApp anmelden können:

Da wir den Benutzer unserer eigenen Anwendung authentifizieren, ist es normalerweise nicht erforderlich, um Erlaubnis zu bitten, wie es Google im OAuth 2.0-Ablauf tat. Gleichzeitig brauchen wir etwas, das den Benutzer identifizieren kann. OpenID Connect führt Konzepte wie ID-Token und Benutzerinfo-Endpunkt ein, die uns dabei helfen.

Du hast vielleicht bemerkt, dass der Identitätsanbieter (IdP) ein neuer eigenständiger Teilnehmer im Ablauf ist. Er ist derselbe wie der Autorisierungsserver in OAuth 2.0, aber um mehr Klarheit zu schaffen, verwenden wir den Begriff IdP, um zu zeigen, dass er für die Benutzerauthentifizierung und Identitätsmanagement verantwortlich ist.

Wenn dein Geschäft wächst, kannst du mehrere Anwendungen haben, die dieselbe Benutzerdatenbank teilen. So wie bei OAuth 2.0 ermöglicht dir OpenID Connect, einen einzigen Autorisierungsserver zu haben, der Benutzer für mehrere Anwendungen authentifizieren kann. Wenn der Benutzer bereits bei einer Anwendung angemeldet ist, muss er seine Anmeldedaten nicht erneut eingeben, wenn eine andere Anwendung ihn zu IdP weiterleitet. Der Ablauf kann automatisch ohne Benutzereingriff erfolgen. Dies wird als Single Sign-On (SSO) bezeichnet.

Nochmals, dies ist ein stark vereinfachter Ablauf und es gibt mehr Details unter der Haube. Lass uns vorläufig zum nächsten Abschnitt übergehen, um eine Informationsüberflutung zu vermeiden.

Anwendungstypen#

Im vorherigen Abschnitt haben wir Webanwendungen als Beispiele verwendet, während die Welt vielfältiger ist als das. Für einen Identitätsanbieter spielt die genaue Programmiersprache, das Framework oder die Plattform, die du verwendest, keine Rolle. In der Praxis gibt es einen bemerkenswerten Unterschied, ob die Anwendung ein öffentlicher Client oder ein privater (vertrauenswürdiger) Client ist:

• Öffentlicher Client: Ein Client, der seine Anmeldeinformationen nicht vertraulich halten kann, was bedeutet, dass der Ressourceneigentümer (Benutzer) darauf zugreifen kann. Zum Beispiel eine Webanwendung, die im Browser ausgeführt wird (z.B. Single-Page-Anwendung).
• Privater Client: Ein Client, der in der Lage ist, seine Anmeldeinformationen vertraulich zu halten, ohne sie gegenüber (Ressourceneigentümern) Benutzern preiszugeben. Zum Beispiel eine Webanwendung, die auf einem Server ausgeführt wird (z.B. Server-seitige Webanwendung) oder ein API-Dienst.

Mit diesem Wissen wollen wir sehen, wie OAuth 2.0 und OpenID Connect in verschiedenen Anwendungstypen verwendet werden können.

"Anwendung" und "Client" können im Kontext dieses Beitrags austauschbar verwendet werden.

Webanwendungen, die auf einem Server laufen#

Die Anwendung läuft auf einem Server und liefert HTML-Seiten an Benutzer. Viele beliebte Webframeworks wie Express.js, Django und Ruby on Rails fallen in diese Kategorie; und Backend-for-Frontend (BFF)-Frameworks wie Next.js und Nuxt.js sind ebenfalls enthalten. Diese Anwendungen haben folgende Merkmale:

1. Da ein Server nur privaten Zugriff zulässt (es gibt keine Möglichkeit für öffentliche Benutzer, den Code oder die Anmeldeinformationen des Servers zu sehen), wird er als privater Client betrachtet.
2. Der allgemeine Benutzerauthentifizierungsablauf ist derselbe wie der, den wir im Abschnitt "OpenID Connect" besprochen haben.
3. Die Anwendung kann das vom Identitätsanbieter (d.h. dem OpenID Connect-Anbieter) ausgestellte ID-Token verwenden, um den Benutzer zu identifizieren und benutzerspezifische Inhalte anzuzeigen.
4. Um die Anwendung sicher zu halten, verwendet die Anwendung in der Regel den Autorisierungscode-Ablauf, um die Benutzerauthentifizierung durchzuführen und Token zu erhalten.

Gleichzeitig kann die Anwendung möglicherweise auf andere interne API-Dienste in einer Mikroservices-Architektur zugreifen; oder es ist eine monolithische Anwendung, die Zugriffssteuerung für verschiedene Teile der Anwendung benötigt. Wir werden dies im Abschnitt "Schütze deine API" besprechen.

Single-Page-Anwendungen (SPAs)#

Die Anwendung läuft im Browser des Benutzers und kommuniziert über APIs mit dem Server. React, Angular und Vue.js sind beliebte Frameworks für den Bau von SPAs. Diese Anwendungen haben folgende Merkmale:

1. Da der Code der Anwendung öffentlich sichtbar ist, gilt sie als öffentlicher Client.
2. Der allgemeine Benutzerauthentifizierungsablauf ist derselbe wie der, den wir im Abschnitt "OpenID Connect" besprochen haben.
3. Die Anwendung kann das vom Identitätsanbieter (d.h. dem OpenID Connect-Anbieter) ausgestellte ID-Token verwenden, um den Benutzer zu identifizieren und benutzerspezifische Inhalte anzuzeigen.
4. Um die Anwendung sicher zu halten, verwendet die Anwendung in der Regel einen Autorisierungscode-Ablauf mit PKCE (Proof Key for Code Exchange), um die Benutzerauthentifizierung durchzuführen und Token zu erhalten.

In der Regel müssen SPAs auf andere API-Dienste zugreifen, um Daten abzurufen und zu aktualisieren. Wir werden dies im Abschnitt "Schütze deine API" besprechen.

Mobile Anwendungen#

Die Anwendung läuft auf einem mobilen Gerät (iOS, Android usw.) und kommuniziert über APIs mit dem Server. In den meisten Fällen haben diese Anwendungen die gleichen Merkmale wie SPAs.

Machine-to-Machine (M2M)-Anwendungen#

Machine-to-Machine Anwendungen sind Clients, die auf einem Server (Maschine) laufen und mit anderen Servern kommunizieren. Diese Anwendungen haben folgende Merkmale:

1. Wie Webanwendungen, die auf einem Server laufen, sind M2M-Anwendungen private Clients.
2. Die Anwendung muss den Benutzer möglicherweise nicht identifizieren; stattdessen muss sie sich selbst authentifizieren, um auf andere Dienste zuzugreifen.
3. Die Anwendung kann das vom Identitätsanbieter (d.h. dem OAuth 2.0-Anbieter) ausgestellte Zugangstoken verwenden, um auf andere Dienste zuzugreifen.
4. Um die Anwendung sicher zu halten, verwendet die Anwendung in der Regel den Client-Anmeldeinformationen-Ablauf, um Zugangstoken zu erhalten.

Beim Zugriff auf andere Dienste muss die Anwendung möglicherweise das Zugangstoken im Anforderungsheader bereitstellen. Wir werden dies im Abschnitt "Schütze deine API" besprechen.

Anwendungen auf IoT-Geräten#

Die Anwendung läuft auf einem IoT-Gerät (z.B. Smart-Home-Geräte, Wearables usw.) und kommuniziert über APIs mit dem Server. Diese Anwendungen haben folgende Merkmale:

1. Je nach Fähigkeit des Geräts kann es sich um einen öffentlichen oder privaten Client handeln.
2. Der allgemeine Authentifizierungsablauf kann sich je nach Fähigkeit des Geräts von dem im Abschnitt "OpenID Connect" besprochenen unterscheiden. Zum Beispiel haben einige Geräte möglicherweise keinen Bildschirm, auf dem Benutzer ihre Anmeldedaten eingeben können.
3. Wenn das Gerät den Benutzer nicht identifizieren muss, kann es ID-Token oder Benutzerinfo-Endpunkte möglicherweise nicht verwenden; stattdessen kann es als Machine-to-Machine (M2M)-Anwendung behandelt werden.
4. Um die Anwendung sicher zu halten, kann die Anwendung entweder den Autorisierungscode-Ablauf mit PKCE (Proof Key for Code Exchange) für die Benutzerauthentifizierung und den Erhalt von Token verwenden oder den Client-Anmeldeinformationen-Ablauf, um Zugangstoken zu erhalten.

Wenn das Gerät mit dem Server kommuniziert, muss es möglicherweise das Zugangstoken im Anforderungsheader bereitstellen. Wir werden dies im Abschnitt "Schütze deine API" besprechen.

Schütze deine API#

Mit OpenID Connect ist es möglich, den Benutzer zu identifizieren und benutzerspezifische Daten über ID-Token oder Benutzerinfo-Endpunkte abzurufen. Dieser Prozess wird Authentifizierung genannt. Aber du möchtest wahrscheinlich nicht alle deine Ressourcen allen authentifizierten Benutzern zugänglich machen. Zum Beispiel können nur Administratoren auf die Benutzermanagement-Seite zugreifen.

Hier kommt die Autorisierung ins Spiel. Erinnere dich daran, dass OAuth 2.0 ein Autorisierungs-Framework ist und OpenID Connect eine Identitätsschicht auf OAuth 2.0; was bedeutet, dass du auch OAuth 2.0 verwenden kannst, wenn OpenID Connect bereits vorhanden ist.

Erinnern wir uns an das Beispiel, das wir im Abschnitt "OAuth 2.0" verwendet haben: MyApp möchte auf den Google Drive des Benutzers zugreifen. Es ist nicht praktikabel, MyApp den Zugriff auf alle Dateien des Benutzers in Google Drive zu gestatten. Stattdessen sollte MyApp ausdrücklich angeben, was es zugreifen möchte (z.B. schreibgeschützter Zugriff auf Dateien in einem bestimmten Ordner). In OAuth 2.0-Begriffen wird dies als Scope bezeichnet.

Du kannst den Begriff "Berechtigung" im Kontext von OAuth 2.0 als Synonym für "Scope" sehen, da "Scope" manchmal für nicht-technische Benutzer verwirrend sein kann.

Wenn der Benutzer MyApp den Zugriff gewährt, gibt der Autorisierungsserver ein Zugangstoken mit dem angeforderten Scope aus. Das Zugangstoken wird dann an den Ressourcenserver (Google Drive) gesendet, um auf die Dateien des Benutzers zuzugreifen.

Natürlich können wir Google Drive durch unsere eigenen API-Dienste ersetzen. Zum Beispiel muss MyApp auf den OrderService zugreifen, um die Bestellhistorie des Benutzers abzurufen. Diesmal, da die Benutzerauthentifizierung bereits vom Identitätsanbieter durchgeführt wurde und sowohl MyApp als auch OrderService unter unserer Kontrolle stehen, können wir das Bitten des Benutzers, den Zugriff zu gewähren, überspringen; MyApp kann die Anfrage direkt an OrderService mit dem vom Identitätsanbieter ausgestellten Zugangstoken senden.

Das Zugangstoken kann einen read:order Scope enthalten, um anzuzeigen, dass der Benutzer seinen Bestellverlauf lesen kann.

Angenommen, der Benutzer gibt versehentlich eine Admin-Seiten-URL im Browser ein. Da der Benutzer kein Administrator ist, gibt es keinen admin-Scope im Zugangstoken. Der OrderService wird die Anfrage ablehnen und eine Fehlermeldung zurückgeben.

In diesem Fall könnte der OrderService einen 403 Forbieden-Statuscode zurückgeben, um anzuzeigen, dass der Benutzer nicht berechtigt ist, auf die Admin-Seite zuzugreifen.

Für Machine-to-Machine (M2M)-Anwendungen ist kein Benutzer in den Prozess involviert. Anwendungen können direkt Zugangstoken vom Identitätsanbieter anfordern und diese verwenden, um auf andere Dienste zuzugreifen. Das gleiche Konzept gilt: Das Zugangstoken enthält die notwendigen Scopes, um auf die Ressourcen zuzugreifen.

Autorisierungsdesign#

Wir sehen zwei wichtige Dinge, die bedacht werden müssen, wenn wir die Autorisierung zum Schutz deiner API-Dienste entwerfen:

1. Scopes: Definieren, auf was der Client zugreifen kann. Scopes können fein-granular (z.B. read:order, write:order) oder allgemeiner gehalten (z.B. order) sein, abhängig von deinen Anforderungen.
2. Zugriffssteuerung: Definiere, wer spezifische Scopes haben kann. Zum Beispiel können nur Administratoren den admin-Scope haben.

In Bezug auf Zugriffssteuerung sind einige gängige Ansätze:

• Rollenbasierte Zugriffssteuerung (RBAC): Weise Rollen den Benutzern zu und definiere, welche Rollen auf welche Ressourcen zugreifen können. Zum Beispiel kann eine Administratorrolle auf die Admin-Seite zugreifen.
• Attributbasierte Zugriffssteuerung (ABAC): Definiere Richtlinien basierend auf Attributen (z.B. Abteilung des Benutzers, Standort usw.) und treffe Zugriffsentscheidungen basierend auf diesen Attributen. Zum Beispiel kann ein Benutzer aus der „Engineering“-Abteilung auf die Engineering-Seite zugreifen.

Es ist erwähnenswert, dass in beiden Ansätzen die standardmäßige Überprüfung der Zugriffssteuerung darin besteht, die Scopes des Zugangstokens zu überprüfen, anstatt Rollen oder Attribute. Rollen und Attribute können sehr dynamisch sein, während Scopes eher statisch sind, was die Verwaltung erleichtert.

Detaillierte Informationen zur Zugriffssteuerung findest du in RBAC und ABAC: Die Zugriffssteuerungsmodelle, die du kennen solltest.

Zugangstoken#

Obwohl wir den Begriff "Zugangstoken" oft erwähnt haben, haben wir nicht darüber gesprochen, wie man eines erhält. In OAuth 2.0 wird ein Zugangstoken vom Autorisierungsserver (Identitätsanbieter) nach einem erfolgreichen Autorisierungsablauf ausgestellt.

Schauen wir uns das Google Drive Beispiel genauer an und nehmen wir an, wir verwenden den Autorisierungscode-Ablauf:

Es gibt einige wichtige Schritte im Ablauf zur Ausstellung eines Zugangstokens:

• Schritt 2 (Weiterleitung zu Google): MyApp leitet den Benutzer zu Google mit einer Autorisierungsanfrage weiter. Typischerweise enthält diese Anfrage folgende Informationen:
  • Welcher Client (MyApp) die Anfrage initiiert
  • Welche Scopes MyApp anfordert
  • Wohin Google den Benutzer weiterleiten soll, nachdem die Autorisierung abgeschlossen ist
• Schritt 5 (Um Erlaubnis bitten, auf Google Drive zuzugreifen): Google bittet den Benutzer, MyApp den Zugang zu gewähren. Der Benutzer kann den Zugang gewähren oder ablehnen. Dieser Schritt wird Zustimmung genannt.
• Schritt 7 (Weiterleitung zu MyApp mit Autorisierungsdaten): Dieser Schritt ist neu im Diagramm eingeführt. Anstatt das Zugangstoken direkt zu senden, gibt Google einen einmal verwendbaren Autorisierungscode an MyApp zurück, um einen sichereren Austausch zu ermöglichen. Dieser Code wird verwendet, um das Zugangstoken zu erhalten.
• Schritt 8 (Verwende Autorisierungscode, um gegen Zugangstoken auszutauschen): Dies ist ebenfalls ein neuer Schritt. MyApp sendet den Autorisierungscode an Google, um Zugangstoken zu erhalten. Als ein Identitätsanbieter wird Google den Kontext der Anfrage zusammensatzellen und entscheiden, ob ein Zugangstoken ausgestellt werden soll:
  • Der Client (MyApp) ist der, der er zu sein behauptet
  • Der Benutzer hat dem Client Zugang gewährt
  • Der Benutzer ist der, der er zu sein behauptet
  • Der Benutzer hat die notwendigen Scopes
  • Der Autorisierungscode ist gültig und nicht abgelaufen

Das obige Beispiel geht davon aus, dass der Autorisierungsserver (Identitätsanbieter) und der Ressourcenserver derselbe sind (Google). Wenn sie separat sind, nehmen wir das Beispiel von MyApp und OrderService, dann wird der Ablauf so aussehen:

In diesem Ablauf gibt der Autorisierungsserver (IdP) sowohl ein ID-Token als auch ein Zugangstoken an MyApp aus (Schritt 8). Das ID-Token wird verwendet, um den Benutzer zu identifizieren, und das Zugangstoken wird verwendet, um auf andere Dienste wie den OrderService zuzugreifen. Da sowohl MyApp als auch OrderService erstklassige Dienste sind, bitten sie den Benutzer in der Regel nicht um Zustimmung; stattdessen verlassen sie sich auf die Zugriffssteuerung im Identitätsanbieter, um festzustellen, ob der Benutzer auf die Ressourcen zugreifen kann (d.h. ob das Zugangstoken die notwendigen Scopes enthält).

Schließlich sehen wir, wie das Zugangstoken in Machine-to-Machine (M2M)-Anwendungen verwendet wird. Da kein Benutzer in den Prozess involviert ist und die Anwendung vertraut ist, kann sie direkt ein Zugangstoken vom Identitätsanbieter anfordern:

Zugriffskontrolle kann hier immer noch angewendet werden. Für OrderService spielt es keine Rolle, wer der Benutzer ist oder welche Anwendung die Daten anfordert; es kümmert sich nur um das Zugangstoken und die Scopes, die es enthält.

Zugangstoken sind in der Regel als JSON Web Tokens (JWT) codiert. Um mehr über JWT zu erfahren, kannst du Was ist JSON Web Token (JWT)? nachlesen.

Ressourcenindikatoren#

OAuth 2.0 führt das Konzept von Scopes für die Zugriffskontrolle ein. Allerdings könntest du schnell erkennen, dass Scopes nicht ausreichen:

• OpenID Connect definiert eine Reihe von Standardscopes wie openid, offline_access und profile. Es kann verwirrend sein, diese Standardscopes mit deines eigenen benutzerdefinierten Scopes zu mischen.
• Du könntest mehrere API-Dienste haben, die denselben Scopenamen teilen, aber unterschiedliche Bedeutungen haben.

Eine gemeinsame Lösung ist es, Suffixe (oder Präfixe) zu den Scopenamen hinzuzufügen, um auf die Ressource (API-Dienst) hinzudeuten. Zum Beispiel sind read:order und read:product klarer als read und read. Eine OAuth 2.0-Erweiterung RFC 8707 führt einen neuen Parameter resource ein, um den Ressourcenserver zu benennen, auf den der Client zugreifen möchte.

In der Realität werden API-Dienste normalerweise durch URLs definiert, so dass es natürlicher ist, URLs als Ressourcenindikatoren zu verwenden. Zum Beispiel kann das OrderService-API dargestellt werden als:

Wie du sehen kannst, bringt der Parameter den Komfort, die tatsächlichen Ressource-URLs in den Autorisierungsanfragen und Zugangstoken zu verwenden. Es sei jedoch erwähnt, dass das RFC 8707 möglicherweise nicht von allen Identitätsanbietern implementiert wird. Du solltest die Dokumentation deines Identitätsanbieters überprüfen, um zu sehen, ob es den resource-Parameter unterstützt (Logto unterstützt ihn).

Im Wesentlichen kann der resource-Parameter in Autorisierungsanfragen und Zugangstoken verwendet werden, um die Ressource zu benennen, auf die der Client zugreifen möchte.

Es gibt keine Einschränkung bezüglich der Zugänglichkeit der Ressourcenindikatoren, d.h. der Ressourcenindikator muss keine echte URL sein, die auf einen API-Dienst zeigt. Daher spiegelt der Name "Ressourcenindikator" seine Rolle im Autorisierungsprozess richtig wider. Du kannst virtuelle URLs verwenden, um Ressourcen zu vertreten, die du schützen möchtest. Zum Beispiel könntest du eine virtuelle URL https://api.example.com/admin in deiner monolithischen Anwendung definieren, um die Ressource zu repräsentieren, auf die nur Administratoren zugreifen können.

Alles zusammenbringen#

An dieser Stelle haben wir die Grundlagen von OAuth 2.0 und OpenID Connect behandelt und wie man sie in verschiedenen Anwendungstypen und Szenarien verwendet. Obwohl wir sie einzeln besprochen haben, kannst du sie entsprechend deinen geschäftlichen Anforderungen kombinieren. Die gesamte Architektur kann so einfach sein wie:

Oder etwas komplexer:

Wenn deine Anwendung wächst, wirst du sehen, dass der Identitätsanbieter (IdP) eine kritische Rolle in der Architektur spielt; aber er bezieht sich nicht direkt auf deine Geschäftsziele. Während es eine großartige Idee ist, es an einen zuverlässigen Anbieter auszulagern, müssen wir den Identitätsanbieter klug wählen. Ein guter Identitätsanbieter kann den Prozess erheblich vereinfachen, den Entwicklungsaufwand reduzieren und dich vor potenziellen Sicherheitsfallen bewahren.

Abschließende Anmerkungen#

Für moderne Cloud-Anwendungen ist der Identitätsanbieter (oder Autorisierungsserver) der zentrale Ort für Benutzer Authentifizierung, Identitätsmanagement und Zugriffskontrolle. Obwohl wir in diesem Beitrag viele Konzepte besprochen haben, gibt es immer noch viele Nuancen zu beachten, wenn ein solches System implementiert wird. Wenn du daran interessiert bist, mehr zu erfahren, kannst du unseren Blog für tiefergehende Artikel durchstöbern.