Ab diesem Zeitpunkt werde ich erklären, wie die REST-API-Authentifizierung / -Autorisierung mithilfe des OAuth 2.0-Berechtigungscode-Grant-Flows mithilfe von Spring Security OAuth (+ Spring Boot) mehrmals (wahrscheinlich 3 bis 5 Mal) realisiert wird. Machen. Während ich sage ... Ich bin auch nicht mit OAuth 2.0 vertraut ... Möglicherweise gibt es eine falsche Erklärung (nicht schlecht ...): heat_smile: Wenn Sie eine falsche Erklärung finden, hinterlassen Sie bitte einen Kommentar (Korrekturanforderung). Bitte! !!

Also, diesmal zum ersten Mal ... Ich möchte kurz erklären, was OAuth 2.0 ist (= Überprüfung). Übrigens ... Ich spreche diesmal nicht von Spring Security OAuth und Spring Boot ~: stecken_out_tongue_winking_eye:

Teil 2: Vorerst eine App erstellen

Was ist OAuth 2.0?

Lassen Sie uns zunächst einen kurzen Blick auf OAuth 2.0 werfen. OAuth 2.0 ist ein Autorisierungsframework, mit dem Dienstanbieter Clients geeignete Zugriffsbereiche (Bereiche) bereitstellen können, wenn sie WEB-Ressourcen für "Anwendungen von Drittanbietern (im Folgenden als Clients bezeichnet)" bereitstellen. Einige RFCs haben technische Spezifikationen.

Darüber hinaus gibt es einen RFC für die Verwendung von JWT (JSON Web Token) als Zugriffstoken.

In diesem Eintrag sollten Sie zumindest wissen, ob Sie OAuth 2.0 verwenden, und ich möchte kurz die Architektur von OAuth 2.0 erläutern, wobei der Inhalt im Mittelpunkt steht (Rolle, Berechtigungsgewährung, Umfang, Zugriffstoken, Aktualisierungstoken usw.). Ich werde.

Rolle

OAuth 2.0 definiert die folgenden vier Rollen, die bei der Durchführung der Authentifizierung / Autorisierung angezeigt werden.

rollen	Erläuterung
Resource Owner	Der Eigentümer der Ressource, der für die Autorisierung des Zugriffs auf die Ressource verantwortlich ist (Bereitstellung von Autorisierungszuschüssen). Dienstnutzer (Menschen) spielen häufig diese Rolle.
Resource Server	Es ist dafür verantwortlich, die Ressourcen des Ressourcenbesitzers unter angemessener Zugriffskontrolle bereitzustellen (Zugriffskontrolle unter Verwendung des dem Zugriffstoken zugewiesenen Bereichs). Der Webserver des Dienstanbieters spielt diese Rolle.
Authorization Server	Authentifizierung des Ressourcenbesitzers, Autorisierung durch den Ressourcenbesitzer(Erhalt eines lizenzierten Zuschusses), Verantwortlich für die Ausstellung von Zugriffstoken, die autorisierten Zuschüssen entsprechen. Der Webserver des Dienstanbieters spielt diese Rolle.
Client	Verantwortlich für den Zugriff auf geschützte Ressourcen im Namen des Ressourcenbesitzers mithilfe des Zugriffstokens, das der vom Ressourcenbesitzer bereitgestellten Berechtigungsgewährung entspricht. Webanwendung, Benutzeragenten-basierte Clientanwendung(JavaScript usw.), Native Anwendungen usw. spielen diese Rolle.

Die grafische Darstellung der Interaktion zwischen Rollen (Protokollfluss) ist wie folgt.

spring-security-oauth-oauth2.0.png

Lizenzierter Zuschuss

In OAuth 2.0 wird das Gewähren des Zugriffs auf Ressourcen als "Autorisierungsgewährung" bezeichnet, und die folgenden vier Typen werden als Gewährungstypen definiert.

Grant-Typ	Erläuterung
Authorization Code	Der Ressourcenbesitzer gibt einen Autorisierungscode (einen Code, der angibt, dass der Zugriff auf die Ressource autorisiert ist) über den Autorisierungsserver aus und stellt ihn dem Client zur Verfügung. Da der Client das Zugriffstoken mit dem vom Ressourcenbesitzer bereitgestellten Autorisierungscode austauscht, werden die Anmeldeinformationen des Ressourcenbesitzers (Benutzername und Kennwort) nicht an den Client übergeben, und es kann davon ausgegangen werden, dass dies der sicherste Grant-Typ ist.
Implicit	Der Punkt, an dem der Ressourcenbesitzer den Zugriff auf die Ressource über den Autorisierungsserver zulässt, entspricht dem Erteilen des Autorisierungscodes. Bei der implizierten Erteilung wird das Zugriffstoken jedoch direkt nach der Autorisierung ausgestellt. Wie bei der Erteilung des Autorisierungscodes werden die Anmeldeinformationen des Ressourcenbesitzers (Benutzername und Kennwort) nicht an den Client übergeben, die Sicherheit ist jedoch geringer als die Erteilung des Autorisierungscodes, da der Client nicht authentifiziert ist.
Resource Owner Password Credential	Stellen Sie ein Zugriffstoken aus, indem Sie die Anmeldeinformationen des Ressourcenbesitzers (Benutzername und Kennwort) als Berechtigungsgewährung übergeben. Da die Anmeldeinformationen des Ressourcenbesitzers an den Client übergeben werden müssen, besteht ein erhöhtes Risiko des Missbrauchs der Anmeldeinformationen des Ressourcenbesitzers für nicht vertrauenswürdige oder böswillige Clients.
Client Credential	Ein Zugriffstoken wird ausgestellt, indem die Anmeldeinformationen des Clients (Client-ID und Kennwort) als Autorisierungsgewährung übergeben werden. Dies ist ein Grant-Typ, der verwendet wird, wenn der Client selbst wie ein Ressourcenbesitzer ist.

Umfang

OAuth 2.0 verwendet das Konzept des Bereichs, um die Ressourcen zu begrenzen, auf die Clients zugreifen können. Der Bereich, der verarbeitet werden kann, wird vom Autorisierungsserver verwaltet, und der Client kann den "Bereich, für den Sie autorisiert werden möchten" angeben, wenn er die Ausgabe des Autorisierungscodes oder des Zugriffstokens anfordert.

Zugangstoken

In OAuth 2.0 wird das Zugriffstoken mit der vom Ressourcenbesitzer bereitgestellten Berechtigungsgewährung ausgetauscht, und beim Zugriff auf die Ressource wird das Zugriffstoken zur Authentifizierung / Autorisierung übergeben. Das Zugriffstoken kann ein Ablaufdatum haben. Wenn das Ablaufdatum abläuft, muss die Berechtigung erneut vom Ressourcenbesitzer eingeholt werden. Wenn das Ablaufdatum kurz ist, ist die Benutzerfreundlichkeit des Anwendungsbenutzers gering, und umgekehrt ist das Risiko eines Missbrauchs aufgrund von Leckagen / Leckagen von Zugriffstoken erhöht, wenn das Ablaufdatum lang ist.

Token aktualisieren

Gibt es eine Möglichkeit, die Benutzerfreundlichkeit zu verringern, ohne das Risiko von Leckagen bei Zugriffstoken zu erhöhen? ... natürlich gibt es! !! "Token aktualisieren" löst dieses Problem sofort. Ein Aktualisierungstoken ist ein Token, mit dem ein Zugriffstoken erneut ausgestellt wird, wenn das Zugriffstoken abgelaufen ist. Mithilfe des Aktualisierungstokens können Sie ein neues Zugriffstoken mit demselben Umfang ausstellen, zu dem Sie das Zugriffstoken erhalten haben, sodass Sie sich die Mühe ersparen können, den Ressourcenbesitzer zur erneuten Autorisierung aufzufordern. Sie können auch ein Ablaufdatum für das Aktualisierungstoken festlegen. Nach Ablauf des Aktualisierungstokens können Sie das Zugriffstoken nicht erneut ausstellen (= Sie müssen erneut eine Autorisierung vom Ressourcenbesitzer einholen).

Zugriff auf Token und Aktualisierungsstrategie für Token aktualisieren

Es scheint eine gängige Praxis zu sein, die Benutzerfreundlichkeit des Benutzers beizubehalten, ohne das Risiko eines Verlusts von Zugriffstoken zu erhöhen, indem das Ablaufdatum des Zugriffstokens so weit wie möglich verkürzt und das Ablaufdatum des Aktualisierungstokens verlängert wird.

Autorisierungscode gewähren Flussfluss

Die Einführung ist etwas lang geworden, aber von hier aus wollen wir sehen, wie Sie auf Ressourcen zugreifen, wenn Sie den in diesem Eintrag behandelten "Berechtigungscode-Grant-Flow" verwenden.

spring-security-oauth-oauth2.0-code-grant.png

Artikelnummer	Erläuterung
(1)	Der Ressourcenbesitzer stellt eine Anzeigeanforderung für eine beliebige Seite (Seite, die auf den Ressourcenserver zugreift), die vom Client über den Benutzeragenten bereitgestellt wird. Der Client antwortet mit einer Umleitungsanweisung auf den Autorisierungsbildschirm des Autorisierungsservers, um die Autorisierung vom Ressourcenbesitzer zu erhalten.
(2)	Der Benutzeragent ist die vom Client angewiesene Seite(Autorisierungsbildschirm des Autorisierungsservers)Stellen Sie eine Anzeigeanforderung (Weiterleitung). Der Autorisierungsserver antwortet mit einem Bildschirm zum Abrufen der Autorisierung vom Ressourcenbesitzer über den Benutzeragenten.
(3)	Der Ressourcenbesitzer stellt eine Genehmigungsanforderung für die vom Client über den Benutzeragenten angeforderte Autorisierungsanforderung. Der Authentifizierungsserver gibt einen Code (Autorisierungscode) aus, der angibt, dass der Ressourcenbesitzer autorisierten Zugriff auf die Ressource hat, und dann erneut.(1)Der Ressourcenbesitzer antwortet mit einer Umleitungsanweisung auf die Seite des Clients, der die Anzeigeanforderung gestellt hat. Zusätzlich wird der Autorisierungscode dem Parameter zur URL zur Weiterleitung hinzugefügt und verknüpft.
(4)	Der Benutzeragent stellt eine Anzeigeanforderung (Umleitung) für die vom Autorisierungsserver angewiesene Seite (die Seite des Clients, die der Ressourcenbesitzer zuerst zum Anzeigen angefordert hat). Der Client erhält die Ressource des Ressourcenbesitzers vom Ressourcenserver (Details 5).,(Siehe 6) und antworten Sie dann mit einer Seite, auf der die erfassten Ressourceninformationen eingebettet sind.
(5)	Der Client erfasst einen Berechtigungscode aus dem Anforderungsparameter, gibt den erfassten Berechtigungscode an und fordert die Ausgabe eines Zugriffstokens an. Der Autorisierungsserver stellt nach Überprüfung der Gültigkeit des Autorisierungscodes ein Zugriffstoken aus und antwortet dem Client mit dem Zugriffstoken.
(6)	Der Client ruft die REST-API des Ressourcenservers auf, indem er das vom Autorisierungsserver erhaltene Zugriffstoken angibt. Nach Überprüfung der Gültigkeit des Zugriffstokens und des Bereichs ruft der Ressourcenserver den REST-API-Prozess auf und antwortet dem Client mit den von der REST-API zurückgegebenen Ressourcen.

Zusammenfassung

Teil 1 war eine kurze Überprüfung von OAuth 2.0. Der in diesem Eintrag beschriebene Inhalt ist nur ein Teil der von OAuth 2.0 definierten Spezifikationen. Wir würden uns jedoch freuen, wenn Sie sich den Ablauf des Berechtigungscode-Erteilungsflusses grob vorstellen könnten. (Ich bin nicht sicher ...: Schweiß_smile :) Beim nächsten Mal möchte ich Spring Security OAuth (+ Spring Boot) verwenden, um die REST-API-Authentifizierung / -Autorisierung mithilfe des Berechtigungscode-Grant-Flows tatsächlich durchzuführen. (Ich weiß nicht wann es sein wird, aber nächstes Mal ~)

[JAVA] Lassen Sie uns den Ablauf der Erteilung des Autorisierungscodes mit Spring Security OAuth-Part 1: Review of OAuth 2.0 erleben