Einführung in mehrere häufig verwendete Web-Sicherheitsauthentifizierungsmethoden

In diesem Artikel werden fünf häufig verwendete Web-Sicherheitsauthentifizierungsmethoden vorgestellt, die hoffentlich für alle hilfreich sein können.

1. Http Basic Auth

Dies ist die älteste Sicherheitsauthentifizierungsmethode, bei der beim Zugriff auf die API einfach der Benutzername und das Passwort angegeben werden wird immer seltener verwendet, und es werden jetzt sicherere und vertraulichere Authentifizierungsmethoden verwendet. Einige alte Plattformen verwenden es möglicherweise noch.

Wie im Bild unten gezeigt, erscheint ein Feld, in das Sie Ihren Benutzernamen und Ihr Passwort eingeben können. Dies ist die HTTPBasic-Authentifizierung, die mit Tomcat geliefert wird.

Dies sind Ihre Anmeldeinformationen für den Zugriff auf die Anwendung. Die xxxXXX-Zeichenfolge wurde von mir geschrieben, um anzuzeigen, dass es sich um einen Chiffretext handelt. Er wird nach der Base64-Verschlüsselung des Benutzernamens und des Passworts erhalten . Denken Sie jetzt genauso: Es ist zu leicht zu stehlen, daher verwenden neue Anwendungen diese Methode jetzt nur noch selten. Obwohl sie einfach ist, ist das Sicherheitsniveau zu niedrig.

2. OAuth2

In meinem vorherigen Blog habe ich OAuth2 und die Verwendung von Azure AD zur Implementierung der OAuth2-Authentifizierung vorgestellt. Hier werde ich einen Teil des Inhalts dieses Blogs extrahieren, damit jeder ihn zusammenfassen und überprüfen kann.

https://blog.csdn.net/aHardDreamer/article/details/88650939

OAuth steht für Open Authrization. Es handelt sich um einen offenen Standard, der es Benutzern ermöglicht, Anwendungen von Drittanbietern Zugriff auf die auf einer Website gespeicherten privaten Ressourcen des Benutzers zu gewähren, ohne den Benutzernamen und das Passwort an Dritte weiterzugeben. Wir sind beispielsweise mit der Anmeldung bei Plattformen Dritter über QQ/WeChat/Weibo usw. vertraut. Nach der Veröffentlichung von OAuth 1.0 gab es viele Sicherheitslücken, daher wurde OAuth 1.0 in OAuth 2.0 vollständig abgeschafft, wobei der Schwerpunkt auf der Einfachheit für Client-Entwickler lag, oder durch eine genehmigte Vereinbarung zwischen dem Ressourceneigentümer und dem HTTP-Dienstanbieter des Benutzers oder ermöglicht einer Drittanbieteranwendung, im Namen des Benutzers Zugriff zu erhalten. Es ist etwas kompliziert zu lesen, aber das Prinzip ist eigentlich sehr einfach. Bitte lesen Sie die Erklärung unten.

1. Zuerst müssen wir diese drei Rollen im OAuth2-Authentifizierungs- und Autorisierungsprozess verstehen:

1: Wie der Name schon sagt, stellt er geschützte Dienste und Ressourcen bereit und Benutzer speichern viele Dinge darin.

2. Benutzer: Eine Person, die Dinge (Fotos, Informationen usw.) beim Dienstanbieter gespeichert hat.

3. Der Dienstanbieter muss sich beim Dienstanbieter registrieren, wenn er auf die Ressourcen zugreifen möchte, andernfalls wird der Dienstanbieter diese nicht nutzen.

2. OAuth2-Authentifizierungs- und Autorisierungsprozess:

1) Der Benutzer möchte die im Dienstanbieter gespeicherten Ressourcen bedienen.

2) Der Benutzer meldet sich beim Client an und der Client fordert ein temporäres Token vom Dienstanbieter an.

3) Nachdem der Dienstanbieter die Identität des Kunden überprüft hat, gibt er ihm ein temporäres Token.

4) Nachdem der Client das temporäre Token erhalten hat, leitet er den Benutzer zur Autorisierungsseite des Dienstanbieters weiter und fordert die Benutzerautorisierung an. (In diesem Prozess werden das temporäre Token und der Rückruflink/die Schnittstelle des Clients an den Dienstanbieter gesendet. Natürlich wird der Dienstanbieter nach der Benutzerauthentifizierung und -autorisierung zurückkommen, um diese Schnittstelle aufzurufen.)

5) Der Benutzer gibt die ein Benutzer meldet sich mit einem Passwort an. Nach erfolgreicher Anmeldung kann der Kunde zum Zugriff auf die Ressourcen des Dienstanbieters autorisiert werden in Schritt 4);

7) Der Client erhält den offiziellen Zugriffstoken vom Dienstanbieter auf der Grundlage des temporären Tokens

8) Der Dienstanbieter gewährt den Client-Zugriffstoken auf der Grundlage des temporären Tokens und der Autorisierung des Benutzers

9) Der Client verwendet das Zugriffstoken, um auf die geschützten Ressourcen des Benutzers zuzugreifen, die beim Dienstanbieter gespeichert sind.

3. Es gibt vier Möglichkeiten, Zugriffstoken zu erhalten (Grant-Typ), für die es jeweils anwendbare Anwendungsszenarien gibt:

1. Autorisierungscode (Autorisierungscode-Modus)

Wird in Verbindung mit gewöhnlichen serverseitigen Anwendungen verwendet .

1) Der Benutzer greift auf den Client zu und dieser leitet ihn an den Authentifizierungsserver weiter. Unter der Annahme, dass der Benutzer die Autorisierung erteilt, leitet der Authentifizierungsserver den Benutzer an die vom Client vorab angegebene „Umleitungs-URI“ weiter und fügt einen Autorisierungscode hinzu.

2) Der Client erhält den Autorisierungscode, hängt den früheren „Umleitungs-URI“ an und beantragt ein Token vom Authentifizierungsserver: GET /oauth/token?response_type=code&client_id=test&redirect_uri=Link zur Umleitungsseite. Die Anfrage gibt erfolgreich einen Code-Autorisierungscode zurück, der im Allgemeinen 10 Minuten lang gültig ist.

3) Der Authentifizierungsserver überprüft den Autorisierungscode und den Umleitungs-URI. Nachdem er bestätigt hat, dass sie korrekt sind, sendet er das Zugriffstoken und das Aktualisierungstoken an den Client. POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=Seitenlink umleiten. Die Anforderung gibt den Zugriffstoken und den Aktualisierungstoken erfolgreich zurück.

(Kostenloses Teilen von Lernvideos: php-Video-Tutorial)

2. Implizit (vereinfachter Modus)

Verwendung in Verbindung mit mobilen Anwendungen oder Web-Apps.

Zugriffstoken wird direkt vom Autorisierungsserver zurückgegeben (nur Front-End-Kanal)

Aktualisierungstoken werden nicht unterstützt

Angenommen, der Ressourceneigentümer und die öffentliche Clientanwendung befinden sich auf demselben Gerät

Am anfälligsten für Sicherheitsangriffe

3. Anmeldeinformationen für Ressourcenbesitzer-Passwörter

eignen sich für vertrauenswürdige Clientanwendungen, z. B. interne oder externe Anwendungen innerhalb derselben Organisation.

Apps, die sich mit Benutzername und Passwort anmelden, wie z. B. Desktop-Apps

Benutzername/Passwort als Autorisierungsmethode verwenden, um Zugriffstoken vom Autorisierungsserver zu erhalten

Aktualisierungstoken werden im Allgemeinen nicht unterstützt

Gehen Sie davon aus, dass der Ressourceneigentümer und Der öffentliche Client befindet sich auf demselben Gerät

4. Client-Anmeldeinformationen

Geeignet für Clients zum Aufrufen von Hauptdienst-API-Anwendungen (z. B. Baidu API Store, Microservices zwischen verschiedenen Projekten rufen sich gegenseitig auf)

Nur Back-End-Kanäle , verwenden Sie Kundenanmeldeinformationen, um ein Zugriffstoken zu erhalten. Da Kundenanmeldeinformationen symmetrische oder asymmetrische Verschlüsselung verwenden können, unterstützt diese Methode gemeinsame Passwörter oder Zertifikate.

3 Wir lernen zuerst J2EE. Es besteht darin, auf der Serverseite ein Sitzungsobjekt für die Anforderungsauthentifizierung zu erstellen und gleichzeitig auf der Browserseite des Clients ein Cookie-Objekt zu erstellen, das mit dem Sitzungsobjekt auf dem Server übereinstimmt Seite, um staatliche Verwaltung zu erreichen. Standardmäßig werden Cookies gelöscht, wenn wir den Browser schließen. Sie können das Cookie jedoch für einen bestimmten Zeitraum gültig machen, indem Sie die Ablaufzeit des Cookies ändern.

Diese auf Cookies basierende Authentifizierung macht es jedoch schwierig, die Anwendung selbst zu erweitern. Unabhängige Server können es nicht mehr übertragen. Bei mehr Benutzern treten Probleme mit sitzungsbasierten Authentifizierungsanwendungen auf.

Probleme basierend auf der Sitzungsauthentifizierung:

1) Zunehmende Sitzungen erhöhen den Server-Overhead

Nachdem jeder Benutzer von unserer Anwendung authentifiziert wurde, muss unsere Anwendung eine Aufzeichnung auf dem Server erstellen, um die nächste Anfrage des Benutzers zu erleichtern. Für die Authentifizierung sind normalerweise Sitzungen erforderlich im Speicher gespeichert werden. Mit zunehmender Anzahl authentifizierter Benutzer steigt der serverseitige Overhead erheblich.

2) Nicht anpassbar in einer verteilten oder Multi-Server-Umgebung

Nach der Benutzerauthentifizierung erstellt der Server Authentifizierungsdatensätze im Speicher, was bedeutet, dass der Benutzer die nächste Anfrage nur auf diese Weise anfordern muss Auf diesem Server können autorisierte Ressourcen abgerufen werden, was die Möglichkeiten des Load Balancers bei verteilten Anwendungen entsprechend einschränkt. Dies bedeutet auch eine Einschränkung der Skalierbarkeit der Anwendung. Allerdings können einige Server jetzt Sitzungen zwischen den einzelnen Servern teilen, indem sie Sticky Sessions einrichten.

3) Anfällig für CSRF-Angriffe

Da die Benutzeridentifikation auf Cookies basiert, sind Benutzer anfällig für Cross-Site-Request-Forgery-Angriffe

4. Token-Authentifizierung Der Autorisierungsmechanismus ähnelt dem http-Protokoll und ist zustandslos. Die Authentifizierungsinformationen oder Sitzungsinformationen des Benutzers müssen nicht auf dem Server gespeichert werden. Dies bedeutet, dass Anwendungen, die auf dem Token-Authentifizierungsmechanismus basieren, nicht berücksichtigen müssen, bei welchem ​​Server sich der Benutzer anmeldet, was die Anwendungserweiterung erleichtert.

Prozess:

Der Benutzer verwendet den Benutzernamen und das Passwort, um den Server anzufordern.

Der Server überprüft die Informationen des Benutzers Bei jeder Anfrage

Der Server überprüft den Tokenwert und gibt die Daten zurück

Dieses Token muss bei jeder Anfrage an den Server übergeben werden und sollte im Anfrageheader gespeichert werden. Außerdem muss der Server das CORS (Cross-) unterstützen. Im Allgemeinen können wir dies auf der Serverseite „Access-Control-Allow-Origin“ tun.

Eigenständig

Die Nutzlast enthält alle vom Benutzer benötigten Informationen und vermeidet so mehrere mal Abfragen der Datenbank

Die Verwendung von JSON Web Token ist in den folgenden Szenarien sinnvoll:

Autorisierung: Dies ist das häufigste Szenario für die Verwendung von JWT. Sobald der Benutzer angemeldet ist, enthält jede nachfolgende Anfrage ein JWT, das dem Benutzer den Zugriff auf die durch dieses Token zugelassenen Routen, Dienste und Ressourcen ermöglicht. Single Sign-On ist eine Funktion von JWT, die mittlerweile weit verbreitet ist, da sie nur wenig Overhead verursacht und problemlos domänenübergreifend verwendet werden kann.

Informationsaustausch: JSON Web Tokens sind zweifellos eine gute Möglichkeit, Informationen sicher zwischen Parteien zu übertragen. Da JWTs beispielsweise mit einem öffentlichen/privaten Schlüsselpaar signiert werden können, können Sie sicher sein, dass der Absender derjenige ist, für den er sich ausgibt. Da die Signatur anhand des Headers und der Nutzlast berechnet wird, können Sie außerdem überprüfen, ob der Inhalt nicht manipuliert wurde.

Die Struktur von JWT:

Aus diesem Bild geht hervor, dass die Struktur von JWT in drei Teile unterteilt ist, die mit „.“ verbunden sind:

Header:

Header besteht normalerweise aus zwei Teile: Token-Typ („JWT“) und Algorithmusname (z. B. HMAC SHA256 oder RSA usw.).

Zum Beispiel:

Dann verwenden Sie Base64, um diesen JSON zu codieren, um den ersten Teil des JWT zu erhalten.

Nutzlast:

Der zweite Teil des JWT ist die Nutzlast, die die Deklaration (Anforderung) enthält. Ansprüche sind Aussagen über Entitäten (normalerweise Benutzer) und andere Daten. Es gibt drei Arten von Erklärungen: registrierte, öffentliche und private Erklärungen.

Registrierte Ansprüche: Hier finden Sie eine Reihe vordefinierter Ansprüche. Sie sind nicht obligatorisch, werden aber empfohlen. Zum Beispiel: iss (Aussteller), exp (Ablaufzeit), sub (Betreff), aud (Zielgruppe) usw.

Öffentliche Ansprüche: können nach Belieben definiert werden.

Private Ansprüche: Ansprüche, die dem Austausch von Informationen zwischen Parteien dienen, die sich bereit erklären, sie zu verwenden, und nicht registriert oder öffentlich sind.

Hier ist ein Beispiel:

Base64 kodiert die Nutzlast, um den zweiten Teil des JWT zu erhalten.

Hinweis: Fügen Sie keine vertraulichen Informationen in die Nutzlast oder den Header des JWT ein, es sei denn, sie sind verschlüsselt.

Signatur:

Um den Signaturteil zu erhalten, müssen Sie über den codierten Header, die codierte Nutzlast, einen geheimen Schlüssel und den im Header angegebenen Signaturalgorithmus verfügen und diese dann einfach signieren.

Zum Beispiel:

HMACSHA256(base64UrlEncode(header) + „.“ + base64UrlEncode(payload), Secret)

Die Signatur wird verwendet, um zu überprüfen, ob die Nachricht während des Zustellungsprozesses geändert wurde, und für mit signierte Token Mithilfe privater Schlüssel kann außerdem überprüft werden, ob der Absender des JWT derjenige ist, für den es sich ausgibt.

Wenn Sie auf das JWT-Token stoßen, können Sie es auf der offiziellen Website von JWT entschlüsseln. Nachfolgend sind die von der offiziellen Website entschlüsselten Daten aufgeführt:

Weitere Informationen zu JWT erhalten Sie kann zu diesem Blog gehen:

https://www.cnblogs.com/cjsblog/p/9277677.html

Referenz:

https://www.jianshu.com/p/f8c43dcd8b69

https:// blog.csdn.net/alan_liuyue/article/details/88183267

https://www.cnblogs.com/cjsblog/p/9277677.html

Verwandte Empfehlungen: Webserver-Sicherheit

Das obige ist der detaillierte Inhalt vonEinführung in mehrere häufig verwendete Web-Sicherheitsauthentifizierungsmethoden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!