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）客戶端通過向授權端點引導資源所有者的用戶代理開始流程.客戶端包括它的客戶端標識、請求范圍、本地狀態(tài)和重定向URI,一旦訪問被許可（或拒絕）授權服務器將傳送用戶代理回到該URI.
??? (B)授權服務器驗證資源擁有者的身份（通過用戶代理），并確定資源所有者是否授予或拒絕客戶端的訪問請求。
???. （C）假設資源所有者許可訪問,授權服務器使用之前（在請求時或客戶端注冊時）提供的重定向URI重定向用戶代理回到客戶端.重定向URI在URI片段中包含訪問令牌.
???. （D）用戶代理順著重定向指示向Web托管的客戶端資源發(fā)起請求（RFC2616該請求不包含片段).通常是帶有嵌入式腳本的HTML文檔）,該網頁能夠訪問包含用戶代理保留的片段的完整重定向URI并提取包含在片段中的訪問令牌（和其他參數）.
??? (F)用戶代理在本地執(zhí)行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: