APIs und Authentifizierung auf dem Jamstack

Der Kern der Jamstack -Architektur liegt in "APIs" (Anwendungsprogrammschnittstelle), die statische Websites leistungsstarke dynamische Funktionen verleiht. Durch APIs können Entwickler die Komplexität verändern und statische Websites dynamische Funktionen hinzufügen. Der Zugriff auf die API erfordert normalerweise eine Überprüfung der Authentizität der Anfrage, die normalerweise in Form von Authentifizierung (Authentifizierung) erfolgt, nach dem verwendeten Dienst und den zu erledigenden Aufgaben auf der Client oder Serverseite durchgeführt werden.

Unterschiede in verschiedenen Protokollen führen zu unterschiedlichen Authentifizierungsimplementierungen von APIs. Diese Authentifizierungsprotokolle und Implementierungsdetails fügen zusätzliche Herausforderungen bei der Integration von APIs in Jamstack -Websites hinzu. Glücklicherweise ist dies nicht außer Betrieb. Jedes Protokoll kann einem bestimmten Anwendungsfall zugeordnet werden, und der Schlüssel zur Implementierung der Authentifizierung besteht darin, dies zu verstehen.

Um dies besser zu veranschaulichen, tauchen wir in die verschiedenen Protokolle und ihre besten Szenarien ein.

Überblick über Vereinbarung

OAuth 2.0 ist ein häufiger Standard, dass die Authentifizierung heute befolgt wird. OAuth ist ein ziemlich flexibler Autorisierungsrahmen, der eine Reihe von Genehmigungen enthält, die die Beziehung zwischen dem Kunden und dem API -Endpunkt definieren. Im OAuth -Prozess fordert die Client -Anwendung einen Zugriffs -Token aus dem autorisierten Endpunkt an und verwendet dieses Token, um die Anfrage für den API -Endpunkt zu unterzeichnen.

Es gibt vier Haupttypen der Autorisierung - Authorisierungscode, implizite Prozess, Kennwort für Ressourcenbesitzer und Client -Anmeldeinformationen. Wir werden jeden separat untersuchen.

Autorisierungscode Autorisierung

Von allen OAuth -Autorisierungstypen ist die Genehmigung des Autorisierungscode wahrscheinlich die häufigste. Dieser Autorisierungsprozess wird hauptsächlich verwendet, um ein Zugriffstoken zu erhalten, um API -Anfragen zu autorisieren, nachdem der Benutzer explizit Berechtigungen gewährt hat. Es folgt einem zweistufigen Prozess:

• Erstens werden Benutzer auf den Einverständniserklärung (d. H. Der Autorisierungsserver) gerichtet, wo sie der Dienstberechtigung erhalten, auf ihre persönlichen Konten und Daten zuzugreifen.
• Sobald die Berechtigung eingereicht wurde, besteht der nächste Schritt darin, das Zugriffsstoken vom Authentifizierungsserver abzurufen, mit dem dann die Anforderungen des API -Endpunkts authentifiziert werden können.

Die Autorisierungscode -Autorisierung fügt eine zusätzliche Sicherheitsebene hinzu, indem der Schritt hinzugefügt wird, wenn der Benutzer im Vergleich zu anderen Autorisierungsarten eine explizite Autorisierung anfordert. Dieser Multi-Step-Code-Austausch bedeutet, dass das Zugriffstoken niemals ausgesetzt ist und immer über einen sicheren Backend-Kanal zwischen der Anwendung und dem Autorisierungsserver gesendet wird. Auf diese Weise kann ein Angreifer nicht leicht zu Zugangsstoken stehlen, indem er Anfragen abfasst. Google-Dienste wie Google Mail und Google Calendar verwenden diesen Autorisierungscode-Prozess, um auf persönliche Inhalte in Benutzerkonten zuzugreifen. Wenn Sie mehr über diesen Workflow erfahren möchten, lesen Sie diesen Blog -Beitrag, um mehr zu erfahren.

Implizite Genehmigung

Die implizite Genehmigung ähnelt der Autorisierung des Autorisierungscode, jedoch mit einem offensichtlichen Unterschied: Anstatt die Benutzerberechtigungen zum Abrufen des Autorisierungscode zu erhalten und ihn dann in ein Zugriffstoken auszutauschen, gibt es das Zugriffstoken sofort zurück, indem der Snippet (Hash) Teil der URL (d. H. Der vordere Kanal) umgeleitet wird .

Aufgrund der reduzierten Schritte des Autorisierungscode besteht der implizite Autorisierungsprozess das Risiko einer Token -Exposition. Da das Token direkt in die URL eingebettet ist (und in die Browsergeschichte aufgezeichnet) ist, ist es leicht zugänglich, wenn die Umleitung abgefangen wird.

Trotz der Sicherheitsanfälligkeit ist die implizite Autorisierung für Benutzer-Agent-basierte Clients wie einseitige Anwendungen nützlich. Da Anwendungscode und Speicher in den clientseitigen Anwendungen leicht zugänglich sind, gibt es keinen sicheren Weg, um den Client-Schlüssel zu schützen. Implizite Flows werden zur logischen Lösung für dieses Problem, indem sie eine Anwendung mit einer schnellen und einfachen Möglichkeit zur Authentifizierung von Benutzern im Client bereitstellen. Dies ist auch ein effektiver Weg, um CORS-Probleme zu lösen, insbesondere bei der Verwendung autorisierter Server von Drittanbietern, die keine Cross-Domänen-Anfragen unterstützen. Aufgrund der inhärenten Token -Expositionsrisiken dieses Ansatzes ist es wichtig zu beachten, dass Zugangsantrieb in impliziten Prozessen häufig vorübergehend sind und niemals ein Refresh -Token ausstellen. Daher kann dieser Vorgang für jede Anfrage an eine privilegierte Ressource angemeldet werden.

Ressourcenbesitzer Passwort Autorisierung

Im Falle der Autorisierung des Ressourcenbesitzers sendet der Ressourcenbesitzer seinen Benutzernamen- und Kennwort -Anmeldeinformationen an den Autorisierungsserver, der dann das Zugriffs -Token mit einem optionalen Aktualisierungs -Token zurücksendet. Da Ressourcenbesitzer -Anmeldeinformationen im Autorisierungsaustausch zwischen Client -Anwendungen und Autorisierungsserver sichtbar sind, muss eine Vertrauensbeziehung zwischen Ressourcenbesitzer und Client -Anwendung bestehen. Obwohl es offensichtlich nicht so sicher ist wie andere Autorisierungsarten, bietet die Autorisierung des Ressourcenbesitzerkennworts eine hervorragende Benutzererfahrung für First-Anbieter-Clients. Dieser Autorisierungsprozess eignet sich am besten für Situationen, in denen Anwendungen hoch privilegiert sind oder im Gerätebetriebssystem arbeiten. Dieser Autorisierungsprozess wird normalerweise verwendet, wenn andere Prozesse nicht machbar sind.

Client -Anmeldeinformationen Autorisierung

Der Autorisierungstyp der Client -Anmeldeinformationen wird hauptsächlich verwendet, wenn ein Client einen Zugriffstoken außerhalb des Benutzerkontexts erhalten muss. Dies gilt für die Authentifizierung von Maschinen zu Maschinen, wenn nicht garantiert ist, dass jeder Zugriff auf eine geschützte Ressource die explizite Genehmigung des Benutzers erteilt. Die CLI und die Dienste, die im Backend ausgeführt werden, sind Fälle, in denen dieser Autorisierungsart nützlich ist. Anstatt sich auf die Benutzeranmeldung zu verlassen, besteht die Client -ID und die Schlüssel, um das Token zu erhalten, mit dem die API -Anforderung authentifiziert werden kann.

In der Regel wird bei der Autorisierung von Client -Anmeldeinformationen ein Dienstkonto erstellt, durch das die Anwendung ausführt und API -Anrufe tätigt. Auf diese Weise ist der Benutzer nicht direkt involviert und die Anwendung kann die Anfrage weiterhin authentifizieren. Dieser Workflow ist weit verbreitet, wenn eine Anwendung eher auf ihre eigenen Daten (z. B. Analysen) als auf bestimmte Benutzerdaten zugreifen möchte.

abschließend

Jamstack-Websites stützen sich auf Dienste von Drittanbietern, um komplexe Funktionen zu implementieren. Daher ist das sorgfältige Entwerfen von Authentifizierungslösungen für die Aufrechterhaltung ihrer Sicherheit von wesentlicher Bedeutung. Als Hauptmethode, um Daten in Jamstack auszutauschen, ist die API ein großer Teil davon. Wir haben vier verschiedene API -Anforderungs -Authentifizierungsmethoden mit jeweils eigenen Vorteilen und Auswirkungen auf die Benutzererfahrung angesehen.

Wir haben zu Beginn erwähnt, dass diese vier die Hauptformen der Authentifizierung sind, mit denen Daten aus der API anfordern. Es gibt viele andere Typen, die eine sehr gute Übersicht auf oAuth.net sind. Insgesamt wurde die Website nicht nur in die verfügbaren Authentifizierungen, sondern auch in das gesamte OAuth -Framework eingeteilt.

Bevorzugen Sie eine Methode gegenüber einer anderen? Haben Sie Nutzungsbeispiele, auf die Sie hinweisen können? Bitte teilen Sie die Kommentare mit!

Das obige ist der detaillierte Inhalt vonAPIs und Authentifizierung auf dem Jamstack. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!