OAuth2-Server-php を使用して Yii フレームワーク上に OAuth2 サーバーを構築します

Yii には多数の拡張機能が用意されています。 Yii 公式 Web サイトで提供されている OAuth 関連の拡張機能を確認したところ、OAuth2 クライアント拡張機能はいくつか見つかりましたが、OAuth2 サーバーとして使用できる拡張機能は見つかりませんでした。 Yii はよく整理されており、簡単に拡張できるフレームワークであるため、他の PHP OAuth2 サーバー実装と統合できます。 OAuth.net/2/ 公式 Web サイトでは、PHP で実装されたいくつかの OAuth2 サーバーが提供されています。最初の OAuth2-Server-php は、Yii フレームワークの OAuth2 Server 拡張機能としてここで使用されます。主に、クライアント アクセスを受け入れて access_token を発行するためのクラスを作成するなど、いくつかの必要な統合操作が必要です。

パート 1: データベースの準備

OAuth2-Server-php で使用されるデータベース構造は、Github の oauth2-server-php README.md で提供されるテーブル構造 (スキーマ) を採用しています。 合計 5 つのテーブルがあります:

mysql。 > テーブルを表示;
+--------------------------+
Tables_in_oauth2 |
+----- -- ------------------+
| oauth_access_token |
| oauth_client |
| |
+-------------------------------------+
5 行セット (0.00 秒)
それぞれの名前の説明table テーブル内でアクセスされるコンテンツ、テーブル名はカスタマイズ可能、カスタマイズの場所は次のとおりです: OAuth2/Storage/Pdo.php config 配列内の 48 行。ここでは mysql データベースが使用されるため、Pdo を変更する必要があります。 Redis などの他のストレージ ソリューションを使用している場合は、対応するファイルを自分で変更できます。ここでのデータベース名はすべて単数形であることに注意してください。

以下の SQL 句句を使用してこの 5 つの表を作成し、クライアントを追加します:
############################## #
### oauth2 テーブル
##################################
テーブルが存在する場合は削除します`oauth_client`;
存在する場合はテーブルを削除 `oauth_access_token`;
存在する場合はテーブルを削除 `oauth_authorization_code`;
存在する場合はテーブルを削除 `oauth_refresh_token`;
存在する場合はテーブルを削除`ユーザー`;

CREATE TABLE `oauth_client` (
`client_id` VARCHAR(80) NOT NULL、
`client_secret` VARCHAR(80) NOT NULL、
`redirect_uri` (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)
);
作成するTABLE `oauth_authorization_code` (

`authorization_code` VARCHAR(40) NOT NULL,
`client_id` VARCHAR(80) NOT NULL,
`user_id` VARCHAR(255),
`redirect_uri` VARCHAR( 2000)、
`expires` TIMESTAMP NOT NULL、
`scope` VARCHAR(2000)、
CONSTRAINT auth_code_pk PRIMARY KEY (authorization_code)
);
CREATE TABLE `oauth_refresh_token` (

`refresh_token` VARCHAR(40) NOT NULL、
`client_id` VARCHAR(80) NOT NULL、
`user_id` VARCHAR(255)、
`expires` TIMESTA MP が NULL ではありません、
` scope` VARCHAR(2000),
CONSTRAINT fresh_token_pk PRIMARY KEY (refresh_token)
);
--

CREATE TABLE `user` (
`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)
);
-- テストデータ
oauth_client (client_id, client_secret, redirect_uri) に挿入します
VALUES ("testclient", "testpass", "http://fake/");
ユーザーに挿入します (ユーザー名、パスワード、名、姓)
VALUES ('rereadyou', '8551be07bab21f3933e8177538d411e43b78dbcc', 'bo', 'zhang');


パート 2: 認証スキームと実装

OAuth2 RFC 6749 仕様では、次の 4 つが提供されています基本的な認証スキームは次のとおりです。 4 つの認証スキームと、それらがこの実装でどのように使用されるかについては、個別に説明します。

最初の認証方法: 認可コードグラント

認可コードは、クライアントとリソースオーナーの間の仲介者として認可サーバーを使用することによって取得されます。クライアントは、リソース所有者に直接認可を要求するのではなく、(RFC2616 で定義されたユーザー エージェントによって) リソース所有者を認可サーバーに誘導し、その後、認可コードを使用してリソース所有者をクライアントに送り返します。

リソース所有者が認可コードをクライアントに返すように誘導する前に、認可サーバーはリソース所有者を識別し、その認可を取得します。リソース所有者は認可サーバーでのみ認証されるため、リソース所有者の資格情報をクライアントと共有する必要はありません。

認証コードは、クライアントの ID を検証する機能や、リソース所有者のユーザー エージェントを介してアクセス トークンを渡して他のユーザー (リソースを含む) にアクセス トークンを公開するのではなく、クライアントに直接アクセス トークンを送信する機能など、いくつかの重要なセキュリティ上の利点を提供します。所有者）。

認証コード許可タイプは、アクセス トークンとリフレッシュ トークンを取得するために使用され、機密クライアント用に最適化されています。これはリダイレクトベースのプロセスであるため、クライアントはリソース所有者のユーザー エージェント (通常は Web ブラウザ) と対話でき、認可サーバーからの受信リクエストを (リダイレクト経由で) 受信できる必要があります。

認証コード付与プロセス (Web サーバー フローとも呼ばれます) は次のとおりです:
認証コード付与
+----- ----------+
| ---(A)-- & リダイレクト URI ---->| |
| 認証
| |
| |。リダイレクトURI | | |。 図 1: 認可コード プロセス
図 1 に示すプロセスは次のステップで構成されます: (A) クライアントは、リソース所有者のユーザー エージェントを認可エンドポイントに指示することでプロセスを開始します。クライアントには、クライアント ID、リクエスト スコープ、ローカル状態、およびアクセスが許可 (または拒否) された後に認可サーバーがユーザー エージェントを送り返すリダイレクト URI が含まれます。
(B) 認可サーバーはリソース所有者の身元を (ユーザーエージェント経由で) 検証し、リソース所有者がクライアントのアクセス要求を許可するか拒否するかを決定します。 (C) リソース所有者がアクセスを許可すると、認可サーバーは、以前に (リクエスト時またはクライアントの登録時に) 提供されたリダイレクト URI を使用して、ユーザー エージェントをクライアントにリダイレクトします。リダイレクト URI には、クライアントによって以前に提供された認証コードとローカル ステータスが含まれます。 (D) クライアントは、前のステップで受信した認可コードを含めて、認可サーバーのトークン エンドポイントにアクセス トークンをリクエストします。リクエストを行う際、クライアントは認可サーバーで認証を行います。クライアントには、認証用の認可コードを取得するために使用されるリダイレクト URI が含まれています。
(E) 認可サーバーはクライアントを認証し、認可コードを検証し、受信したリダイレクト URI がステップ (C) でクライアントのリダイレクトに使用された URI と一致することを確認します。渡された場合、認可サーバーはアクセス トークンとオプションのリフレッシュ トークンで応答します。

プロセス実装:
1. クライアント アプリはアプリ ID を使用して認証コードを取得します:

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

戻り値: $ authcode = authorization code.
ヒント: 認証コードは 30 秒で期限切れになります。OAuth2/ResponseType/AuthorizationCode.php の AuthorizationCode クラスのコンストラクター設定パラメーターを変更して、authorization_code の有効時間をカスタマイズできます。
Client_id は、このサーバーに以前に登録されている、クライアント管理の範囲に属するアプリケーション名です。
このステップでは、ユーザー (リソース所有者) が OAuth2 サーバーにログインして認可操作を完了する必要があります。ユーザーログインはユーザー管理のカテゴリに属し、OAuth2 サーバーに記述する必要がある機能ではありません。
ログイン後、ユーザーはクライアント アプリに対して実行できる操作 (承認) を選択できます。
バインド プロセスのこのステップでは、セキュリティの観点から、バインドを確認するためにユーザーにユーザー名とパスワードの再入力を強制する必要があります。バインドのために現在のユーザー セッションを直接読み取らないでください。

2. access_token を取得します:
クライアント アプリは認証コードを使用して access_token を交換します

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

戻り値:
成功:
_in":3600,
"token_type":"bearer",
"scope":null,
"refresh_token":"269a623f54171e8 598b1852eefcf115f4882b820"
}
"失敗: " {" error":"invalid_grant",


"error_description":"認証コードが存在しないか、クライアントに対して無効です"
}
ヒント: このステップtype/AccessToken.php の AccessToken クラスを変更するには、client_id、client_secret、および前の手順で取得した authorization_code が必要です。

2 番目の認証方法: Implicit (暗黙的認証)

暗黙的な認証タイプアクセス トークンを取得するために使用され (リフレッシュ トークンの発行はサポートされていません)、操作の特定のリダイレクト URI を知っているパブリック クライアント向けに最適化されます。これらのクライアントは通常、JavaScript などのスクリプト言語を使用してブラウザーに実装されます

。はリダイレクトベースのプロセスであるため、クライアントはリソース所有者と通信できる必要があり、ユーザー エージェント (通常は Web ブラウザー) が対話し、認可サーバーからの受信リクエストを (リダイレクト経由で) 受信できる必要があります。

クライアントが認可トークンとアクセストークンを別々に要求する認可コード許可タイプとは異なり、クライアントは認可リクエストの結果としてアクセストークンを受け取ります。

暗黙的な権限タイプにはクライアント認証は含まれませんが、リソース所有者の存在とリダイレクト URI の登録に依存します。アクセス トークンはリダイレクト URI にエンコードされるため、リソース所有者や同じデバイス上にある他のアプリケーションに公開される可能性があります。

アクセス トークンを取得するための Implicit Grant メソッドを使用した認可検証プロセスは、ユーザー エージェント フローとも呼ばれ、サーバー連携のないすべてのアプリケーションに適しています (アプリケーションはブラウザーなどのユーザー エージェントに配置されることが多いため、そのようなアプリケーションはモバイル/デスクトップ クライアント プログラム、ブラウザ プラグインなど、一部のプラットフォームではクライアント サイド アプリケーションとも呼ばれます。また、JavaScript などのスクリプト クライアント スクリプト言語に基づくアプリケーションも含まれます。それらの共通の特徴の 1 つは、認証コードモードを採用すると、アプリケーションがアプリ秘密鍵を適切に保持できないため、アプリ秘密鍵が漏洩する可能性があります。プロセス図は次のとおりです| エージェント |----(B)-- ユーザー認証 -->| サーバー |
|---- (D)--- Web ホスト型 |
| | フラグメントなし |
| )------ ------

2つのパートに分かれています。
図 2: 暗黙的な許可フロー 図 2 に示すフローには次のステップが含まれています:
(A) クライアントは、リソース所有者のユーザー エージェントを認可エンドポイントに指示することでプロセスを開始します。クライアントには、クライアント ID、リクエスト スコープ、ローカル状態、およびアクセスが許可 (または拒否) された後に認可サーバーがユーザー エージェントを送り返すリダイレクト URI が含まれます。 (B) 認可サーバーは、リソース所有者の身元を (ユーザーエージェント経由で) 検証し、リソース所有者がクライアントのアクセス要求を許可するか拒否するかを決定します。
(C) リソース所有者がアクセスを許可すると、認可サーバーは、以前に (リクエスト時またはクライアントの登録時に) 提供されたリダイレクト URI を使用して、ユーザー エージェントをクライアントにリダイレクトします。リダイレクト URI には、URI フラグメントにアクセス トークンが含まれています。 (D) ユーザー エージェントはリダイレクト指示に従い、Web ホストのクライアント リソースへのリクエストを開始します (リクエストには RFC2616 に基づくフラグメントは含まれません)。ユーザーエージェントはフラグメント情報をローカルに保持します。
(E) Web ホストのクライアント リソースは、ユーザー エージェントが保持するフラグメントを含む完全なリダイレクト URI にアクセスし、フラグメントに含まれるアクセス トークンを抽出できる Web ページ (通常はスクリプトが埋め込まれた HTML ドキュメント) を返します。カード (およびその他のパラメータ)。
(F) ユーザー エージェントは、Web ホストのクライアント リソースによって提供されるスクリプトをローカルで実行し、アクセス トークンを抽出します。
(G) ユーザーエージェントはアクセストークンをクライアントに送信します。

ヒント: 1. 通常、client_secret は必要ありません。単一ユーザーにも認証が必要です。
2. 暗黙的な許可タイプは、refresh_token メカニズムをサポートしません (または自分で実装できます)。
3. ユーザーが初めて暗黙的な許可フローを使用してアプリを認証するときは、アクセス トークンを取得したら、再認証を試みないでください。 (redirect_uri のフラグメント、つまり uri の # 部分に存在します)、クライアントは自身で access_token を保存する必要があります。
4. モバイル/デスクトップ クライアント プログラム、ブラウザ プラグインなどのクライアント側アプリケーションにより適しています。

oauth2-server-php は、この認証メソッドを次のように実装します。

1. この認証メソッドは、 Authorization Code Grant (これは、Authorization Code Grant メソッドを簡略化したものです)。

OAuth2Controller を初期化するときは、次のように AuthorizationCode タイプの認証を OAuth2 サーバーに追加するだけです:
許可します。暗黙的な認証を有効にするには、Server.php の 104 行目の 'allow_implicit' を 'true' に変更する必要があります。
2. access_token を取得します

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

パラメータ: response_type=token (必須、固定値）
インチ。暗黙の承認は承認コードの取得を必要としないため。
戻り:
成功:
ユーザーは最初に承認ボタンをクリックする必要があります。
成功！承認コード：www.baidu.com？#access_token =9f0c38b475e51ccd3

-off。
{"error":"redirect_uri_mismatch","error_description":"指定されたリダイレクト URI が見つからないか、一致しません","error_uri":"http://tools.ietf.org/html/rfc6749#section-3.1 。 2"}


access_token は redirect_uri のフラグメントに存在します。つまり、「#」記号の後に、クライアントはフラグメント内の access_token を抽出して保存する必要があります。開発者は、一部のユーザー エージェントが、HTTP "Location" HTTP 応答ヘッダー フィールドにフラグメント コンポーネントを含めることをサポートしていないことに注意する必要があります。これらのクライアントは、3xx リダイレクト応答以外のメソッドを使用してクライアントをリダイレクトする必要があります。たとえば、リダイレクト URI にリンクされたアクションを含む「続行」ボタンを含む HTML ページを返すなどです。


3 番目の認証方法: リソース所有者のパスワード認証情報

リソース所有者のパスワード認証情報のアクセス許可タイプは、デバイスのオペレーティング システムや高度な特権アプリケーションなど、リソース所有者がクライアントと信頼関係がある状況に適しています。認証サーバーは、このライセンス タイプを有効にする場合、および他のプロセスが使用できない場合にのみ、特別な注意を払う必要があります。
この権限タイプは、リソース所有者の資格情報 (ユーザー名とパスワード、通常は対話的に) を取得できるクライアントに適しています。また、保存されている資格情報をアクセス トークンに変換することで、HTTP 基本認証やダイジェスト認証などの直接認証スキームを使用している既存のクライアントを OAuth に移行するためにも使用されます。

+----------+
|リソース |
|  オーナー |
|          |
+----------+
v
|    リソース所有者
(A) パスワード資格情報
|
v
+--------+ +---------------+
|         |>--(B)---- リソース所有者 ------->|               |
|         |         パスワード認証情報 |承認 |
|クライアント |                                  |     サーバー |
|         |
|         |    (オプションのリフレッシュ トークン付き) |               |
+---------+ +---------------+

図3：资源所有者密码凭定流程

図3中のもの示されているフローには、次のステップが含まれています:

(A) リソース所有者は、クライアントにそのユーザー名と暗号を提供します。

(C) 許可サーバーは、クライアントに対して個人認証を実行し、必要に応じて、リソース所有者の認証を行います。効果、问牌を公開します。
ヒント: ゲスト端末は、アクセス権タイルを取得したら、メッセージを送信する必要があります。

oauth2-server-php リソース所有者のパスワード認証情報の実装は次のようになります:

1. 最初に Oauth2Controller の構造関数に追加します。リソース所有者のパスワード認証情報の許可方式サポート、以下の代コード：


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

2. access_token :

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

戻り：
{"access_token":"66decd1b10891db5f8f63efe7cc352ce326895c6",

"expires_in":3600,
"token_type": "bearer",
"scope":null,
"refresh_token":"b5fa0c24e786e37e7ce7d6e2f911805dc65a0d7c"}
ヒント: Github 上の oauth2-server-php が提供する SQL スキーマ ユーザー 表里面に user_id 字段[12]、このフィールドを自動的に追加する必要があります (主键、auto_increment)。 ユーザー テーブルの設定では sha1 を使用し、ソルトは追加しません。  これをアプリケーション用にオーバーライドします


protected function checkPassword($user, $password)


{
return $user['password'] == sha1($password);
} 用户认证についてこの関数を変更する必要があります。



4番目の認証方法: Client Credentials Grant (Client Credentials Grant)

クライアントが管理対象へのアクセスを要求する場合、または事前に認可サーバーとネゴシエートする場合(使用される方法はこの仕様の範囲外です)他のリソース所有者のリソースが保護されている場合、クライアントはクライアント資格情報 (またはその他のサポートされている認証方法) のみを使用してアクセス トークンを要求できます。

クライアント認証情報のアクセス許可タイプは、機密クライアントのみが使用する必要があります。

クライアント認証 --->| 認可 |
| |
|
図 4: クライアント認証情報プロセス 図 4 示されているフローには次のステップが含まれています:
(A)クライアントは認可サーバーで認証し、トークン エンドポイントからアクセス トークンを要求します。
(B) 認可サーバーはクライアントを認証し、有効であればアクセス トークンを発行します。 ヒント: これは最も簡単な認証方法です。
クライアント認証が認可権限として使用されるため、他の認可リクエストは必要ありません。
1. oauth2controller：

$ server-> addgranttype（new oauth2granttypeclientcredentials（$ stray）;




2.アクセス_token：

curl-

curl-addgranttypeにクライアント認証メソッドのサポートを追加します。 u testclient:testpass www.yii.com/oauth2/index.php?r=oauth2/token -d 'grant_type=client_credentials'


パラメータを送信します: Grant_type 値は "client_credentials" に設定する必要があります。
スコープはオプションです。
戻り値: "token_type":"bearer",

"scope":null}

ヒント: 独自のクライアント ID と client_secret を使用してアクセスを取得します_token; RFC6749 仕様では [10] クリネット資格情報クライアントを指定しますaccess_token を取得する際の認証には、refresh_token は含まれません。ただし、OAUTH2-Server-PHP は、Oauth2/Granttypes/ClientCReDentials.php No. 33 [11] で、
デフォルトの $ Includereshtoken = False; で Refresh_token を発行します。


パート 3: access_token タイプの説明
クライアントは、(API を介して) データ リソースを操作するときに、access_token をサーバーに提示する必要があります。 access_token および access_token タイプを提示する方法については、次のセクションで説明します。 IETF rfc 6749 に記載されている access_token には、ベアラー タイプと MAC タイプの 2 つのタイプがあります。 OAuth2-Server-php は MAC タイプ access_token 用にまだ開発中であるため、以下では最も一般的に使用されるベアラー タイプ access_token についてのみ説明します。
リソースリクエストでベアラー access_token リソースをリソースサーバーに送信するには 3 つの方法があります [13]。クライアントは、リクエストごとに複数のメソッドを使用してトークンを送信することはできません。 a. HTTP/1.1 [RFC2617] で定義されている「Authorization」リクエストヘッダーフィールドでアクセストークンを送信する場合、クライアントは「Bearer」認証スキームを使用してアクセストークンを送信します。

GET /resource HTTP/1.1
ホスト:server.example.com
認可:Bearer mF_9.B5f-4.1JqM

クライアントはHTTP認可スキームの「Bearer」「Authorization」を使用する必要があります。ヘッダー フィールドは、ベアラー トークンを使用して認証リクエストを開始します。リソース サーバーはこのメソッドをサポートする必要があります。

b. フォームエンコードされた本文パラメーター
HTTP リクエストエンティティ本文でアクセストークンを送信する場合、クライアントは「access_token」パラメーターを使用してアクセストークンをリクエスト本文に追加します。次の条件がすべて満たされない限り、クライアントはこのメソッドを使用できません:
HTTP リクエストのエンティティ ヘッダーには、「application/x-www-form-urlencoded」に設定された「Content-Type」ヘッダー フィールドが含まれています。
エンティティ本体は、HTML4.01 [W3C.REC-html401-19991224] で定義されているコンテンツタイプ「application/x-www-form-urlencoded」のエンコード要件に従います。
HTTP リクエストのエンティティ本体は 1 つの部分です。
エンティティ本体でエンコードされたコンテンツは、完全に ASCII [USASCII] 文字で構成されている必要があります。
HTTP リクエスト メソッドは、リクエスト本文で定義される構文です。特に、「GET」メソッドが使用できないことを意味します。採端 クライアントは、伝送層を使用して次の HTTP リクエストを安全に開始します:


Post/Resource http/1.1
Host: Server.example.com
Content-Type: Application/X-WWW-FORLEM- UrlenCoded
access_token=mF_9.B5f-4.1JqM
c. HTTP リクエスト URI でアクセス トークンを送信するとき、クライアントは「Uniform Resource Identifier (URI): Common Syntax」RFC3986 の「access_token」パラメータを受け取ります。定義 リクエストURIのクエリ部分にアクセストークンを追加します。端 たとえば、クライアントは伝送層を使用して次の HTTP リクエストを安全に開始します:


Get /Resource?Access_token=mf_9.b5f-4.1jqm http /1.1


host: Server.example.com
It should not be は、「Authorization」リクエスト ヘッダー フィールドまたは HTTP リクエスト エンティティ本体でアクセス トークンを送信できない場合を除き、使用されません。 上記の 3 つの access_token の使用方法は、rfc6750 仕様で提案されています。最初のオプションを使用することをお勧めします。 Bearer トークンを使用するには、access_token 送信のセキュリティを確保するために TLS が必要です。


パート 4: Bearer access_token を使用して API を呼び出す

1. access_token:

の代わりに、refresh_token を使用します。curl -u testclient:testpass www.yii.com/oauth2/index.php?r=oauth2/token -d "grant_type=refresh_token&refresh_token=1ce1a52dff3b5ab836ae25714c714cb86bf31b6f"


戻り値: {"access_token":"50540a7ead3a27cdb458b6cdc38",


"expires_in":3600,
"token_type":"bearer",
"scope" :null } ここには、refresh_token を再取得するように設定する必要があります。OAuth2/GrantType/RefreshToken.php の RefreshToken クラス __construct メソッドで 'always_issue_new_refresh_token' => true を変更して、発行を有効にします。新しいrefresh_tokenの。
ヒント: IETF rfc2649 のfresh_token セクションの部分的な説明、 POST /token HTTP/1.1


ホスト:server.example.com
権限:基本 czZCaGRSa3F0Mzp nWDFmQmF0M2JW
Content-Type: application/x-www -form-urlencoded crant_type = refress_token＆refresh_token =tgzv3jokf0xg5qx2tlkwia
は、client_idとclient_secretをclient_tokenで提供する必要があります。 access_token の有効期間中は、refresh_token を使用して新しい access_token を交換することはできません。
2. access_token を使用します:
a. クライアント アプリは、access_token を使用してリソース情報を取得します。oauth2 -server Verify Access_token：

curl www.yii.com/oauth2/index.php?r=oauth2/verifytoken -d 'access_token = aea4a1059d3194a3dd5e4117bedd6e07cc3f402' "" "" "" "message":"your access token is valid."


}
この部分は、リソースを要求するときに、このメソッドを直接呼び出す必要はありません。サーバーは自身を呼び出し、判定結果に応じて異なる処理を実行します。 Oauth2拡張機能のServer.phpでaccess_tokenの有効期限を変更できます。
3. スコープ スコープでは、サーバーが特定の実行可能な操作を決定する必要があります。 スコープは、クライアントが実行できる操作権限を決定するために使用されます。プロジェクト内の操作権限は srbac によって制御されており、当面は Oauth2 で処理されません。

4. state
state は、OAuth2 サーバーに渡され、クライアント アプリが最初のステップで認証コードを取得したときに OAuth2 サーバーによって返されるランダム ハッシュ パラメーターです。 state パラメータは主に、クロスサイト リクエスト フォージェリ (Cross Site Request Forgery、CSRF) を防ぐために使用されます。関連する議論については、この記事の最後にある参考文献 [7] と [8] を参照してください。


参考文献:
[0] OAuth2 rfc6749 中国語版
[1] Yii 公式 Web サイト OAuth 拡張機能リスト
[2] OAuth2 公式 Web サイト
[3] Github の oauth2-server-php
] 認証コードライセンス 中国語版
[ 5] access_tokenの代わりにrefresh_tokenを使用します
[6] 常に新しいrefresh_tokenを送信します
[7] OAuth2状態パラメータ
[8] CSRFのIETF OAuth2ドラフト説明
[9] sohu暗黙的付与の説明
[10] RFC6 749クライアント認証情報Refresh_token に関する説明
[11] oauth2-server-php リフレッシュトークンに関する修正情報
[12] oauth2-server-php リソース所有者パスワード認証情報付与の user_id に関する修正
[13] Bearer トークンの使用方法