Verwenden Sie OAuth2-Server-php, um einen OAuth2-Server auf dem Yii-Framework zu erstellen

Originaltext reproduziert von http://www.cnblogs.com/ldms/p/4565547.html

Yii verfügt über viele Erweiterungen, die verwendet werden können. Nachdem ich die OAuth-bezogenen Erweiterungen auf der offiziellen Website von Yii überprüft habe, habe ich mehrere OAuth2-Client-Erweiterungen gefunden, aber keine Erweiterung, die als OAuth2-Server verwendet werden kann. Da Yii ein gut organisiertes und leicht erweiterbares Framework ist, kann es in andere PHP-OAuth2-Server-Implementierungen integriert werden. Auf der offiziellen Website OAuth.net/2/ werden mehrere in PHP implementierte OAuth2-Server bereitgestellt. Der erste OAuth2-Server-php wird hier als OAuth2-Server-Erweiterung des Yii-Frameworks verwendet. Es sind einige notwendige Integrationsvorgänge erforderlich, hauptsächlich das Schreiben einer Klasse, um den Client-Zugriff zu akzeptieren und access_token usw. auszugeben.

Teil Eins: Datenbankvorbereitung

Die von OAuth2-Server-php verwendete Datenbankstruktur übernimmt die von oauth2-server-php README.md auf Github bereitgestellte Tabellenstruktur. Es gibt fünf insgesamt. Tabelle:

mysql> -----------
| |
----------
|. oauth_access_token |
|. oauth_refresh_token |
|. Benutzer |
-----------
5 Zeilen im Satz (0,00 Sek.)

Der Name jeder Tabelle beschreibt den Inhalt, auf den in der Tabelle zugegriffen wird. Der Speicherort für die Anpassung lautet: OAuth2/Storage/Pdo.php. Da hier die MySQL-Datenbank verwendet wird Was geändert werden muss, ist Pdo. Wenn Sie andere Speicherlösungen wie Redis verwenden, können Sie die entsprechenden Dateien selbst ändern. Beachten Sie, dass die Datenbanknamen hier alle im Singular vorliegen.

Verwenden Sie die folgende SQL-Anweisung, um diese 5 Tabellen zu erstellen und einen Testclient hinzuzufügen:
######################## ######
### oauth2-Tabellen
#############################
Tabelle löschen, falls vorhanden `oauth_client`;
Tabelle löschen, falls vorhanden `oauth_access_token`;
Tabelle löschen, falls vorhanden `oauth_authorization_code`;
Tabelle löschen, falls vorhanden `oauth_refresh_token`;
Tabelle löschen, falls vorhanden ` Benutzer `;

CREATE TABLE `oauth_client` (
`client_id` VARCHAR(80) NOT NULL,
`client_secret` VARCHAR(80) NOT NULL,
`redirect_uri` VARCHAR(2000 ) NOT NULL,
CONSTRAINT client_id_pk PRIMARY KEY (client_id)
);

CREATE TABLE `oauth_access_token` (
`access_token` VARCHAR(40) NOT NULL,
`client_id` VARCHAR (80) NOT NULL,
`user_id` VARCHAR(255),
`expires` TIMESTAMP NOT NULL,
`scope` VARCHAR(2000),
CONSTRAINT access_token_pk PRIMARY KEY (access_token)
);

CREATE TABLE `oauth_authorization_code` (
`authorization_code` VARCHAR(40) NOT NULL,
`client_id` VARCHAR(80) NOT NULL,
`user_id` VARCHAR( 255 );

CREATE TABLE `oauth_refresh_token` (
`refresh_token` VARCHAR(40) NOT NULL,
`client_id` VARCHAR(80) NOT NULL,
`user_id` VARCHAR(255),
`expires` TIMESTAMP NOT NULL,
`scope` VARCHAR(2000),
CONSTRAINT restart_token_pk PRIMARY KEY (refresh_token)
);

--
CREATE TABLE ` Benutzer ` (
`user_id` INT(11) NOT NULL AUTO_INCREMENT,
`username` VARCHAR(255) NOT NULL,
`password` VARCHAR(2000),
`first_name` VARCHAR(255) ,
`last_name` VARCHAR(255),
CONSTRAINT user_pk PRIMARY KEY (user_id)
);
-- Testdaten
INSERT INTO oauth_client (client_id, client_secret, redirect_uri)
VALUES ("testclient", "testpass", "http://fake/");
INSERT INTO user (Benutzername, Passwort , Vorname, Nachname)
VALUES ('rereadyou', '8551be07bab21f3933e8177538d411e43b78dbcc', 'bo', 'zhang');


Teil 2: Authentifizierungsschema und Implementierung

Die Die OAuth2 RFC 6749-Spezifikation bietet vier grundlegende Authentifizierungsschemata. Im Folgenden wird jedes dieser vier Authentifizierungsschemata und ihre Verwendung in dieser Implementierung beschrieben.

Die erste Authentifizierungsmethode: Autorisierungscode-Gewährung (Autorisierungscode-Authentifizierung)

Der Autorisierungscode wird erhalten, indem der Autorisierungsserver als Vermittler zwischen dem Client und dem Ressourcenbesitzer verwendet wird. Anstatt die Autorisierung direkt vom Ressourcenbesitzer anzufordern, leitet der Client den Ressourcenbesitzer an einen Autorisierungsserver weiter (durch einen in RFC 2616 definierten Benutzeragenten), der den Ressourcenbesitzer dann mit einem Autorisierungscode an den Client zurückleitet.

Bevor der Autorisierungsserver den Ressourcenbesitzer anweist, mit dem Autorisierungscode zum Client zurückzukehren, identifiziert er den Ressourcenbesitzer und holt seine Autorisierung ein. Da sich der Ressourcenbesitzer nur beim Autorisierungsserver authentifiziert, müssen die Anmeldeinformationen des Ressourcenbesitzers nicht mit dem Client geteilt werden.

Autorisierungscodes bieten einige wichtige Sicherheitsvorteile, wie z. B. die Möglichkeit, die Identität des Clients zu überprüfen und das Zugriffstoken direkt an den Client zu übertragen, anstatt es möglicherweise offenzulegen, indem es über den Benutzeragenten des Ressourceneigentümers weitergeleitet wird. an andere (einschließlich des Ressourceneigentümers).

Der Berechtigungstyp „Autorisierungscode“ wird zum Erhalten von Zugriffstokens und Aktualisierungstokens verwendet und ist für vertrauliche Clients optimiert. Da es sich um einen weiterleitungsbasierten Prozess handelt, muss der Client in der Lage sein, mit dem Benutzeragenten des Ressourceneigentümers (normalerweise einem Webbrowser) zu interagieren und eingehende Anfragen vom Autorisierungsserver zu empfangen (über Weiterleitungen).

Der Autorisierungscode-Gewährungsprozess (auch bekannt als Webserver-Flow) ist wie folgt:
----------
| > |. |
                                                                                                                                                                                                                                                               |. Agent --- -(B)-- Benutzer authentifiziert --->|. ---|---                                                                    )                                                                            |. |. --------                                          & Umleitungs-URI |
|. |<---(E)----- Zugriffstoken - ---------- --------'
--------- (mit optionalem Aktualisierungstoken)

Hinweis: Erklären Sie die Schritte (A ), (B) und (C) Die Leitung wird beim Durchlaufen des Benutzeragenten in zwei Teile geteilt.
Abbildung 1: Ablauf des Autorisierungscodes

Der in Abbildung 1 dargestellte Ablauf umfasst die folgenden Schritte:

(A) Der Client leitet zunächst den Benutzeragenten des Ressourceneigentümers an den Autorisierungsendpunktprozess weiter . Der Client umfasst seine Client-Identität, den Anforderungsbereich, den lokalen Status und einen Umleitungs-URI, an den der Autorisierungsserver den Benutzeragenten zurücksendet, sobald der Zugriff gewährt (oder verweigert) wird.
(B) Der Autorisierungsserver überprüft die Identität des Ressourceneigentümers (über den Benutzeragenten) und bestimmt, ob der Ressourceneigentümer die Zugriffsanforderung des Clients gewährt oder ablehnt.
(C) Unter der Annahme, dass der Ressourceneigentümer Zugriff gewährt, leitet der Autorisierungsserver den Benutzeragenten mithilfe des zuvor bereitgestellten Umleitungs-URI (zum Zeitpunkt der Anforderung oder bei der Registrierung des Clients) zurück zum Client um. Der Umleitungs-URI enthält den Autorisierungscode und alle zuvor vom Client bereitgestellten lokalen Status.
(D) Der Client fordert vom Token-Endpunkt des Autorisierungsservers ein Zugriffstoken an, indem er den im vorherigen Schritt erhaltenen Autorisierungscode einschließt. Bei einer Anfrage authentifiziert sich der Client beim Autorisierungsserver. Der Client enthält den Umleitungs-URI, der zum Abrufen des Autorisierungscodes für die Authentifizierung verwendet wird.
(E) Der Autorisierungsserver authentifiziert den Client, überprüft den Autorisierungscode und stellt sicher, dass der empfangene Umleitungs-URI mit dem URI übereinstimmt, der zum Umleiten des Clients in Schritt (C) verwendet wurde. Bei Übergabe antwortet der Autorisierungsserver mit einem Zugriffstoken und optionalem Aktualisierungstoken.

Prozessimplementierung:
1. Client-App verwendet App-ID, um Autorisierungscode zu erhalten:

www.yii.com/oauth2/index.php?r=oauth2/authroize&response_type=code&client_id= testclient&state =xyz

Rückgabe: $authcode = Autorisierungscode.
Tipps: Der Autorisierungscode läuft in 30 Sekunden ab. Sie können die Konstruktorkonfigurationsparameter der AuthorizationCode-Klasse in OAuth2/ResponseType/AuthorizationCode.php ändern, um sie anzupassen die gültige Zeit des Authorization_Codes.
Client_id ist der zuvor auf diesem Server registrierte Anwendungsname, der zum Bereich der Clientverwaltung gehört.
Für diesen Schritt muss sich der Benutzer (Ressourcenbesitzer) beim OAuth2-Server anmelden, um den Autorisierungsvorgang abzuschließen. Die Benutzeranmeldung gehört zur Kategorie der Benutzerverwaltung und ist keine Funktion, die in OAuth2 Server geschrieben werden sollte.
Nach der Anmeldung können Benutzer die Vorgänge (Autorisierung) auswählen, die sie für die Client-App öffnen können.
Während dieses Schritts des Bindungsprozesses sollte der Benutzer aus Sicherheitsgründen gezwungen werden, den Benutzernamen und das Passwort erneut einzugeben, um die Bindung zu bestätigen. Lesen Sie nicht direkt die aktuelle Benutzersitzung für die Bindung.

2. Access_token abrufen:
Die Client-App verwendet den Autorisierungscode im Austausch gegen das Access_token

curl -u testclient:testpass www.yii.com/oauth2/index.php?r=oauth2/token -d "grant_type=authorization_code&code=$authcode

Rückgabe:
Erfolg:
{" access_token: „aea4a1059d3194a3dd5e4117bedd6e07ccc3f402“,
„expires_in“:3600,
„token_type“:„bearer“,
„scope“:null,
1852eefcf115f4882b820"
}

                                                                                                  & ken ist für 1209600 gültig und kann erstellt werden Die AccessToken-Klasse in OAuth2/ResponseType/AccessToken.php (Ändern Sie sie in der Funktionskonfiguration. Unterstützt die Ausgabe von Aktualisierungstoken) und ist für öffentliche Clients optimiert, die den spezifischen Umleitungs-URI des Vorgangs kennen. Diese Clients werden normalerweise mithilfe einer Skriptsprache im Browser implementiert wie JavaScript

Da es sich um einen umleitungsbasierten gerichteten Fluss handelt, muss der Client in der Lage sein, mit dem Benutzeragenten des Ressourceneigentümers (normalerweise ein Webbrowser) zu interagieren und eingehende Anfragen vom Autorisierungsserver zu empfangen ( über Weiterleitungen).

Im Gegensatz zum Berechtigungstyp „Autorisierungscode“, bei dem der Client Autorisierung und Zugriffstoken separat anfordert, erhält der Client das Zugriffstoken als Ergebnis der Autorisierungsanforderung.

Implizite Berechtigungstypen umfassen keine Clientauthentifizierung, sondern basieren auf der Anwesenheit des Ressourceneigentümers und der Registrierung des Umleitungs-URI. Da das Zugriffstoken im Umleitungs-URI codiert ist, kann es dem Ressourceneigentümer und anderen Anwendungen auf demselben Gerät zugänglich gemacht werden.

Der Autorisierungsüberprüfungsprozess mithilfe der Implicit Grant-Methode zum Erhalten eines Zugriffstokens wird auch als User-Agent-Flow bezeichnet und eignet sich für alle Anwendungen ohne Serverkooperation (da Anwendungen häufig in einem Benutzeragenten liegen, z. B. in ein Browser, daher wird diese Art von Anwendung auf einigen Plattformen auch als Client-Side-Anwendung bezeichnet), wie z. B. mobile/Desktop-Client-Programme, Browser-Plug-Ins usw., sowie Anwendungen, die auf Skript-Client-Skriptsprachen basieren, wie z Eines ihrer gemeinsamen Merkmale ist: Ja, die App kann ihren geheimen App-Schlüssel nicht ordnungsgemäß behalten. Wenn der Autorisierungscode-Modus übernommen wird, besteht die Möglichkeit, dass der geheime App-Schlüssel verloren geht. Das Prozessdiagramm lautet wie folgt:

----------
| Ressource |
|. - -
^
                                                                                                                                                      - Benutzer authentifiziert -->|. Server |
|     |          |          mit Zugriffstoken     ---------------
     |          |            im Fragment
     |          |                                ---------------
     |          |----(D)--- Umleitungs-URI ---->|   Webgehostet  |
     |          |          ohne Fragment      |     Kunde    |
     |          |                                |    Ressource   |
     |     (F)  |<---(E)------- Skript ---------<|               |
     |          |                                ---------------
     -|--------
       |    |
      (A)  (G) Zugriffstoken
       |    |
       ^    v
     ---------
     |         |
     |  Kunde |
     |         |
     ---------

    

     图2:隐式许可流程

    图2中的所示流程包含以下步骤:

    （A）客户端通过向授权端点引导资源所有者的用户代理开始流程.客户端包括它的客户端标识、请求范围、本地状态和重定向URI,一旦访问被许可（或拒绝）授权服务器将传送用户代理回到该URI.
    (B)授权服务器验证资源拥有者的身份（通过用户代理），并确定资源所有者是否授予或拒绝客户端的访问请求。
   . （C）假设资源所有者许可访问,授权服务器使用之前（在请求时或客户端注册时）提供的重定向URI重定向用户代理回到客户端.重定向URI在URI片段中包含访问令牌.
   . （D）用户代理顺着重定向指示向Web托管的客户端资源发起请求（RFC2616该请求不包含片段).通常是带有嵌入式脚本的HTML文档）,该网页能够访问包含用户代理保留的片段的完整重定向URI并提取包含在片段中的访问令牌（和其他参数）.
    (F)用户代理在本地执行Web托管的客户端资源提供的提取访问令牌的脚本.
（G）用户代理传送访问令牌给客户端.

     Tipps: 1. Geben Sie „client_secret“ und „client_id“ ein需要认证.
       2. Impliziter Gewährungstyp ist der Typ „refresh_token“. （或可自行实现)机制.
       3. Sobald der Benutzer Ihre App zum ersten Mal authentifiziert, indem er IMPLICIT GRANT FLOW verwendet, speichern Sie das Zugriffstoken! Sobald Sie das Zugriffstoken haben, versuchen Sie nicht, sich erneut zu authentifizieren. Ihr von Ihnen gespeichertes Zugriffstoken sollte weiterhin funktionieren!
         >       4. Client-seitig Anwendung，如手机/桌面客户端程序、浏览器插件等

oauth2-server-php implementiert diese Autorisierungsmethode wie folgt:

1. Diese Autorisierungsmethode ist in der Authorization Code Grant (eine Vereinfachung der Authorization Code Grant-Methode) enthalten.

Fügen Sie beim Initialisieren von OAuth2Controller einfach die Autorisierung vom Typ „AuthorizationCode“ zum OAuth2-Server hinzu, wie folgt:
$server->addGrantType(new OAuth2GrantTypeAuthorizationCode($storage));

Autorisierungscode unterstützt implizite Gewährung standardmäßig nicht. Sie müssen „allow_implicit“ in Zeile 104 von Server.php auf „true“ ändern, um implizite Gewährung zu aktivieren.


2. Access_token abrufen

http://www.yii.com/oauth2/index.php?r=oauth2/authorize&response_type=token&client_id=testclient&state=xyz&redirect_uri=www.baidu .com

Parameter: Response_Type=Token (erforderlich, fester Wert)
Client_ID (erforderlich)
Redirect_uri optional
Scope optional
                                                                                                                                                                                          using   using   use using         through   out out through out out out outcer outmb's'' out's        out out out out out out-‐‐‐‐‐out’s erfordern ein Token anstelle eines Codes, da für die implizite Autorisierung kein Erhalt des Autorisierungscodes erforderlich ist.
Rückgabe:
Erfolg:
Der Benutzer muss zuerst auf die Autorisierungsschaltfläche klicken.
ERFOLGREICH! Autorisierungscode: www.baidu.com?#access_token=9f0c38b475e51ccd3

Fehler: Redirect_uri stimmt nicht mit dem registrierten Client-Redirect_uri überein.
               {"error": "redirect_uri_mismatch", "error_description": "Der angegebene Weiterleitungs-URI fehlt oder stimmt nicht überein", "error_uri": "http://tools.ietf.org/html/rfc6749#section- 3.1.2"🎜>
access_token ist im Fragment in Redirect_uri vorhanden, d. h. nach dem „#“-Symbol muss der Client das access_token im Fragment extrahieren und speichern. Entwickler sollten beachten, dass einige Benutzeragenten die Aufnahme von Fragmentkomponenten in das HTTP-Antwort-Header-Feld „Location“ nicht unterstützen. Diese Clients müssen eine andere Methode als eine 3xx-Umleitungsantwort verwenden, um den Client umzuleiten – beispielsweise eine HTML-Seite zurückgeben, die eine Schaltfläche „Weiter“ mit einer Aktion enthält, die mit dem Umleitungs-URI verknüpft ist.


Die dritte Authentifizierungsmethode: Ressourcenbesitzer-Passwort-Anmeldeinformationen (Berechtigung „Ressourcenbesitzer-Passwort-Anmeldeinformationen“)

Der Berechtigungstyp „Ressourcenbesitzer-Passwort-Anmeldeinformationen“ eignet sich für die Vertrauensstellung zwischen dem Ressourcenbesitzer und dem Client. Relevante Situationen, wie z. B. das Betriebssystem des Geräts oder hochprivilegierte Anwendungen. Der Autorisierungsserver sollte bei der Aktivierung dieses Lizenztyps besondere Vorsicht walten lassen und nur dann, wenn kein anderer Prozess verfügbar ist.

Dieser Berechtigungstyp eignet sich für Clients, die die Anmeldeinformationen des Ressourceneigentümers (Benutzername und Passwort, normalerweise interaktiv) erhalten können. Es wird auch verwendet, um vorhandene Clients, die direkte Authentifizierungsschemata wie HTTP Basic oder Digest Authentication verwenden, auf OAuth zu migrieren, indem gespeicherte Anmeldeinformationen in Zugriffstokens umgewandelt werden.

----------
|. Ressource |
|
|. Ressourcenbesitzer
(A) Passwort-Anmeldeinformationen
|
v
--------- - -------------
||. Client |.--(C)---- Zugriffstoken --------<| (mit optionalem Aktualisierungstoken) |. - --------------

Abbildung 3: Prozess der Passwortanmeldeinformationen des Ressourceneigentümers

Abbildung Der in 3 gezeigte Ablauf enthält die folgenden Schritte:

(A) Der Ressourcenbesitzer stellt dem Client seinen Benutzernamen und sein Passwort zur Verfügung.
(B) Der Client fordert ein Zugriffstoken vom Token-Endpunkt des Autorisierungsservers an, indem er die vom Ressourcenbesitzer erhaltenen Anmeldeinformationen einschließt. Bei einer Anfrage authentifiziert sich der Client beim Autorisierungsserver.

(C) Der Autorisierungsserver authentifiziert den Client, überprüft die Anmeldeinformationen des Ressourcenbesitzers und stellt bei Gültigkeit ein Zugriffstoken aus.


Tipps: Der Client muss die Anmeldeinformationen verwerfen, sobald er das Zugriffstoken erhält.

oauth2-server-php implementiert die Passwort-Anmeldeinformationen des Ressourcenbesitzers wie folgt:

1. Fügen Sie zunächst im Konstruktor von Oauth2Controller Unterstützung für die Autorisierungsmethode „Passwort-Anmeldeinformationen des Ressourcenbesitzers“ hinzu und fügen Sie den folgenden Code hinzu:

$server->addGrantType(new OAuth2GrantTypeUserCredentials($storage));

2. Access_token abrufen:

curl -u testclient:testpass www.yii.com/ oauth2/index.php?r=oauth2/token -d 'grant_type=password&username=rereadyou&password=rereadyou'

Rückgabe:
{"access_token":"66decd1b10891db5f8f63efe7cc352ce326895c6",
. "expires_in":36 00 ,
"token_type": "bearer",
"scope":null,
"refresh_token": "b5fa0c24e786e37e7ce7d6e2f911805dc65a0d7c"🎜>
Tipps: SQL bereitgestellt von oauth2-server-php auf Github Es gibt kein user_id-Feld [12] in der Schema-Benutzertabelle. Sie müssen dieses Feld (Primärschlüssel, auto_increment) selbst hinzufügen.
Das Design der Benutzertabelle verwendet die Sha1-Digest-Methode ohne Zugabe von Salz.
                                                                                                                                                                                                                                                     Return $ user ['password'] == Sha1 ($password)
Für die Benutzerzertifizierung muss diese Funktion neu geschrieben werden.



Die vierte Authentifizierungsmethode: Client Credentials Grant (Client Credentials Grant)

Wenn der Client Zugriff auf das anfordert, was er kontrolliert, oder im Voraus mit dem Autorisierungsserver verhandelt ( Der Client kann ein Zugriffstoken nur mit seinen Client-Anmeldeinformationen (oder anderen unterstützten Authentifizierungsmethoden) anfordern.

Der Berechtigungstyp „Client-Anmeldeinformationen“ darf nur von vertraulichen Clients verwendet werden.
                                                                                                      
|>--(A)- Client-Authentifizierung |
| ​​​​—-------------

Abbildung 4: Ablauf der Client-Anmeldeinformationen

Der in Abbildung 4 dargestellte Ablauf enthält die folgenden Schritte:

(A) Der Client authentifiziert sich beim Autorisierungsserver und fordert ein Zugriffstoken vom Token-Endpunkt an.

(B) Der Autorisierungsserver authentifiziert den Client und stellt, falls gültig, ein Zugriffstoken aus.

Tipps: Dies ist die einfachste Authentifizierungsmethode.

Da die Client-Authentifizierung als Autorisierungsberechtigung verwendet wird, ist keine weitere Autorisierungsanfrage erforderlich.

Die Implementierung ist wie folgt:
1. Unterstützung für die Authentifizierungsmethode für Client-Anmeldeinformationen in Oauth2Controller hinzufügen:

$server->addGrantType(new OAuth2GrantTypeClientCredentials($storage));

2. Access_token abrufen:

curl -u testclient:testpass www.yii.com/oauth2/index.php?r=oauth2/token -d 'grant_type=client_credentials'

Parameter senden: grant_type ERFORDERLICH. Der Wert MUSS auf „client_credentials“ gesetzt sein.
Bereich OPTIONAL ?? Der Refresh_token des Credentials-Clients ist beim Abrufen des access_token für die Authentifizierung nicht enthalten.
oauth2-server-php bietet jedoch einen Kontrollschalter in OAuth2/GrantTypes/ClientCredentials.php Zeile 33 [11],
Der Standardwert $includeRefreshToken = false; wenn dieser auf true gesetzt ist, kann der access_token ausgegeben werden gleichzeitig aktualisieren.


Teil 3: Beschreibung des Access_token-Typs
Der Client muss dem Server access_token präsentieren, wenn er Datenressourcen betreibt (über die API). Wie die Typen access_token und access_token präsentiert werden, wird im folgenden Abschnitt erläutert.
In IETF RFC 6749 werden zwei access_token-Typen beschrieben: Bearer-Typ und MAC-Typ.
Da sich OAuth2-Server-php für den MAC-Typ access_token noch in der Entwicklung befindet, wird im Folgenden nur der am häufigsten verwendete Bearer-Typ access_token erläutert.

Es gibt drei Möglichkeiten, die Bearer-access_token-Ressource in der Ressourcenanforderung an den Ressourcenserver zu senden [13]. Der Client kann nicht mehr als eine Methode verwenden, um das Token pro Anfrage zu übertragen.
a. Beim Senden eines Zugriffstokens im Anforderungsheaderfeld „Autorisierung“, das durch HTTP/1.1 [RFC2617] definiert ist, verwendet der Client das Authentifizierungsschema „Bearer“, um das Zugriffstoken zu übertragen.

GET /resource HTTP/1.1
Host: server.example.com
Autorisierung: Bearer mF_9.B5f-4.1JqM

Clients sollten Authentifizierungsanfragen mit einem Bearer-Token unter Verwendung des Anforderungsheaderfelds „Authorization“ mit dem HTTP-Autorisierungsschema „Bearer“ initiieren. Der Ressourcenserver muss diese Methode unterstützen.

b. Formularcodierte Körperparameter
Beim Senden eines Zugriffstokens im HTTP-Anforderungskörper verwendet der Client den Parameter „access_token“, um das Zugriffstoken zum Anforderungskörper hinzuzufügen. Der Client kann diese Methode nur verwenden, wenn alle der folgenden Bedingungen erfüllt sind:
Der Entitätsheader der HTTP-Anfrage enthält das Headerfeld „Content-Type“, das auf „application/x-www-form-urlencoded“ gesetzt ist.
Der Entitätskörper folgt den Codierungsanforderungen des Inhaltstyps „application/x-www-form-urlencoded“, der in HTML4.01 [W3C.REC-html401-19991224] definiert ist.
Der HTTP-Anfrage-Entitätskörper besteht aus einem einzigen Teil.
Der im Entitätskörper codierte Inhalt muss vollständig aus ASCII-Zeichen [USASCII] bestehen.
HTTP-Anfragemethode ist die durch den Anfragetext definierte Syntax. Dies bedeutet insbesondere, dass die Methode „GET“ nicht verwendet werden kann.

Der Client verwendet Transport Layer Security, um die folgende HTTP-Anfrage zu initiieren:

POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/ x -Www-Form-Urlencoded
Access_token = MF_9.B5F-4.1JQM

C. Beim Senden des Zugriffstokens im HTTP-Anforderungs-URI verwendet der Client den Parameter „Access_token“ für „Unified Resource Labeling URI: „Universelle Syntax“ RFC3986 definiert den Abfrageteil des Anforderungs-URI zum Hinzufügen eines Zugriffstokens.

Der Client verwendet beispielsweise Transport Layer Security, um die folgende HTTP-Anfrage zu initiieren:

GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
Host: Server. example. com

Es sollte nicht verwendet werden, es sei denn, das Zugriffstoken kann nicht im Anforderungsheaderfeld „Autorisierung“ oder im HTTP-Anforderungskörper übertragen werden.

Die oben genannten drei Möglichkeiten zur Verwendung von access_token werden in der RFC6750-Spezifikation vorgeschlagen. Es wird empfohlen, die erste Option zu verwenden. Die Verwendung des Bearer-Tokens erfordert TLS, um die Sicherheit der access_token-Übertragung zu gewährleisten.


Teil 4: API mit Bearer access_token aufrufen

1. Refresh_token im Austausch für access_token verwenden:
curl -u testclient:testpass www.yii.com/oauth2/index .php?r=oauth2/token -d "grant_type=refresh_token&refresh_token=1ce1a52dff3b5ab836ae25714c714cb86bf31b6f"

Rückgabe:
{"access_token":"50540a7ead3a2. 7cdb458b6cdc38df 25f64da18f1",
"expires_in":3600,
„token_type“: „bearer“,
„scope“:null}
Hier gibt es kein neues Refresh_token. Sie müssen es konfigurieren, um das Refresh_token erneut zu erhalten. Sie können die __construct-Methode der RefreshToken-Klasse in OAuth2/ ändern. GrantType/RefreshToken.php. 'always_issue_new_refresh_token' => true, um die Ausgabe eines neuen Refresh_tokens zu ermöglichen.
Tipps: Teilweise Beschreibung des Abschnitts „refresh_token“ in IETF rfc2649,
POST /token HTTP/1.1
Host: server.example.com
Autorisierung: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Inhaltstyp: application/ x -www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Sie müssen die client_id und das client_secret des Clients angeben, und der grant_type-Wert muss restart_token sein.
Der Refresh_token kann während der Gültigkeitsdauer des Access_token nicht zum Austausch gegen einen neuen Access_token verwendet werden.

2. Access_token verwenden:
a. Die Client-App verwendet access_token, um Ressourceninformationen abzurufen.
oauth2-server verify access_token:
curl www.yii.com/oauth2/index.php?r=oauth2/verifytoken -d 'access_token=aea4a1059d3194a3dd5e4117bedd6e07ccc3f402'

Return:
{" Ergebnis: „Erfolg“,
„message“: „Ihr Zugriffstoken ist gültig.“
Dieser Teil dient nur dazu, die Gültigkeit des Zugriffstokens zu überprüfen. Die Client-App sollte diese Methode nicht direkt aufrufen, sondern der Server ruft sie selbst auf, wenn er Ressourcen anfordert. Dem Urteil zufolge werden die Ergebnisse unterschiedlich verarbeitet.
Sie können die Gültigkeitsdauer von access_token in Server.php der Oauth2-Erweiterung ändern.

3. Geltungsbereich
Der Geltungsbereich erfordert, dass der Server bestimmte durchführbare Vorgänge bestimmt.
Der Bereich wird verwendet, um die Betriebsberechtigungen zu bestimmen, die der Client ausführen kann. Die Betriebsberechtigungen im Projekt werden von srbac gesteuert und vorerst nicht in Oauth2 verarbeitet.

4. Status
Status ist der zufällige Hash-Parameter, der an den OAuth2-Server übergeben und vom OAuth2-Server zurückgegeben wird, wenn die Client-App im ersten Schritt den Autorisierungscode erhält. Der Statusparameter wird hauptsächlich verwendet, um die Fälschung von Cross-Site-Anfragen (Cross Site Request Forgery, CSRF) zu verhindern. Weitere Informationen finden Sie in den Referenzen [7] und [8] am Ende dieses Artikels.

 
Referenzen: