原文は http://www.cnblogs.com/ldms/p/4565547.html より転載
Yiiには利用できる拡張機能が多数あります。 Yii公式サイトで提供されている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 つのテーブルがあります。テーブルを表示 ;
+---------------+
Tables_in_oauth2 |
+--------------- - ------------+
| oauth_authorization_code |
| oauth_refresh_token |
| ----------+
5 行セット (0.00 秒)
各テーブルの名前は、テーブル内でアクセスされるコンテンツを説明します。テーブル名はカスタマイズできます: OAuth2/Storage。 /Pdo.php の 48 行目の config 配列では、ここでは mysql データベースが使用されているため、Redis などの他のストレージ ソリューションが使用されている場合は、対応するファイルを自分で変更するだけです。ここでのデータベース名はすべて単数形であることに注意してください。
次の SQL ステートメントを使用して、これら 5 つのテーブルを作成し、テスト クライアントを追加します:
##############################
### oauth2 テーブル
#############################
テーブルが存在する場合は削除します `oauth_client`;
テーブルが存在する場合は削除します ` oauth_access_token`;
存在する場合はテーブルを削除 `oauth_authorization_code`;
存在する場合はテーブルを削除 `oauth_refresh_token`;
存在する場合はテーブルを削除 `user`;
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) 注_token)
; 000)、
`expires` TIMESTAMP NOT NULL、
`scope` VARCHAR(2000)、
CONSTRAINT auth_code_pk PRIMARY KEY (authorization_code)
);
CREATE TABLE `oauth_refresh_token` (
`リフレッシュする_to ken` VARCHAR( 40）nullではない、
`client_id` varchar（80）noll、
`user_id` varchar（255）、
` expires` not null、
`scope` varchar（2000）、
制約refresh_token_pkプライマリキー（refresh_token_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) に INSERT INTO
VALUES ("testclient"、"testpass"、"http://fake/");
ユーザー (username、password、first_name、last_name) に INSERT INTO
値（ 'rereadyou'、 '8551be07bab21f3933e817538d411e43b78dbcc'、 'bo'、 'zhang'）;ソリューションと、それがこの実装でどのように使用されるかについては、別途説明します。
最初の認証方法: 認可コードグラント
認可コードは、クライアントとリソースオーナーの間の仲介者として認可サーバーを使用することによって取得されます。クライアントは、リソース所有者に直接認可を要求するのではなく、(RFC 2616 で定義されたユーザー エージェントによって) リソース所有者を認可サーバーに誘導し、その後、認可コードを使用してリソース所有者をクライアントに送り返します。
リソース所有者が認可コードをクライアントに返すように誘導する前に、認可サーバーはリソース所有者を識別し、その認可を取得します。リソース所有者は認可サーバーでのみ認証されるため、リソース所有者の資格情報をクライアントと共有する必要はありません。
認証コードは、クライアントの ID を検証する機能や、リソース所有者のユーザー エージェントを介してアクセス トークンを渡して他のユーザー (リソースを含む) にアクセス トークンを公開するのではなく、クライアントに直接アクセス トークンを送信する機能など、いくつかの重要なセキュリティ上の利点を提供します。所有者）。
認証コード許可タイプは、アクセス トークンとリフレッシュ トークンを取得するために使用され、機密クライアント用に最適化されています。これはリダイレクトベースのプロセスであるため、クライアントはリソース所有者のユーザー エージェント (通常は Web ブラウザ) と対話でき、認可サーバーからの受信リクエストを (リダイレクト経由で) 受信できる必要があります。 Z 認証コード付与プロセス (Web サーバー フローとも呼ばれます) は次を参照してください:
+----------+
| -------------------------------------------------- --------------------------------- --- -(A)-- & リダイレクト URI ----> ;| ユーザー - |
| エージェント +----(B)-- ユーザー認証 --->| | +----------- ---+
|
| +---------+ | クライアント |
| アクセストークン-----'
+----------+ (オプションのリフレッシュ トークンあり)
注: ステップ (A)、(B)、および (C) を表す直線は 2 つの部分に分割されていますユーザーエージェントを経由するからです。
図 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
Return: $authcode =ヒント: 認証コードは 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
17bedd6 e07ccc3f402",
"Expires_in": 3600,
"token_type": " Bearer"、
"Scope": NULL、
"Refresh_token": "269a623F54171E8598B1852eefcf115F4882" Error ":" Invalid_grant "、
" error_descripting " :"認証コードが存在しないか、クライアントに対して無効です"
}
ヒント:このステップでは、クライアントの client_id と client_secret および access_code を交換するために前のステップで取得した authorization_code を使用する必要があります。これは、OAuth2/ResponseType/AccessToken.php の AccessToken クラスのコンストラクター設定で変更できます。暗黙的 (暗黙的認証)
暗黙的認証タイプは、アクセス トークンを取得するために使用され (リフレッシュ トークンの発行はサポートされません)、これらのクライアントは通常、操作の特定のリダイレクト URI を知っているパブリック クライアント用に最適化されます。 JavaScript などのスクリプト言語を使用するブラウザ
これはリダイレクトベースのクライアントであるため、クライアントはリソース所有者のユーザー エージェント (通常は Web ブラウザ) と対話でき、リソース所有者のユーザー エージェントからの受信リクエストを受信できる必要があります。認可サーバー (リダイレクト経由)
認可を要求するクライアントと、認可リクエストの結果としてクライアントが受け取るアクセス トークンの認可コード付与タイプとは異なります。
暗黙的な権限タイプにはクライアント認証は含まれませんが、リソース所有者の存在とリダイレクト URI の登録に依存します。アクセス トークンはリダイレクト URI にエンコードされるため、リソース所有者や同じデバイス上にある他のアプリケーションに公開される可能性があります。
アクセス トークンを取得するための Implicit Grant メソッドを使用した認可検証プロセスは、ユーザー エージェント フローとも呼ばれ、サーバーと連携しないすべてのアプリケーションに適しています (アプリケーションはブラウザーなどのユーザー エージェントに配置されることが多いため、そのようなアプリケーションはモバイル/デスクトップ クライアント プログラム、ブラウザ プラグインなど、一部のプラットフォームではクライアント サイド アプリケーションとも呼ばれます。また、JavaScript などのスクリプト クライアント スクリプト言語に基づくアプリケーションも含まれます。それらの共通の特徴の 1 つは、認証コードモードを採用した場合、アプリケーションがアプリ秘密鍵を適切に保持できないため、アプリ秘密鍵が漏洩する可能性があります。プロセス図は次のとおりです:
(B )
+----|-----+ クライアント識別子 +---------------+
| +- --(A)-- & リダイレクト URI -- ->| ユーザー - |認可 |
|--(B)-- ユーザーがサーバーを認証します |
| )- - リダイレクト URI ----<| | | アクセストークン付き +---------------+
| | フラグメント内
| | +--------------+
| |----(D)--- リダイレクト URI ---->| ウェブホスト |
| | フラグメントなし | クライアント |
| | | リソース |
| (F) |<---(E)------ スクリプト ---------<| |
| | +--------------+
+-|--------+
| |
(A) (G) アクセストークン
| |
^ v
+---------+
| |
| クライアント |
| |
+---------+
注: 説明ステップ (A) と (B) の直線は、ユーザー エージェントを介して 2 つの部分に分割されています。図２に示されているフローには、以下のステップが含まれています。 （A）クライアントは、アクセス許可エンドポイントに向けて、リソース所有者のユーザプロキシを介してフローを開始します。
(B) 許可サーバーは、リソース所有者の身元を (ユーザー エージェント経由で) 確認し、リソース所有者がゲストを許可するか拒否するかを確認します。户端の问
(C) リソース所有者がアクセスを許可し、許可サーバーの使用前 (要求時またはクライアントの登録時) に提供される再方向 URI が、ユーザー エージェントをクライアントに返します。
（D） ユーザ エージェントは、Web ブラウザのクライアント エンド リソースへの要求の送信を再指示します（RFC2616 では、このリクエストにはセグメントが含まれません）。 ユーザ エージェントは、セグメント情報をそのまま保持します。ネットワーク (通常は、挿入されたスクリプトを含む HTML テキスト) を返すと、このネットワークは、ユーザー エージェントが保持するセグメントの完全な方向 URI を含み、セグメント内に含まれるアクセス タイル (およびその他のパラメータ) を抽出することができます。 ) ユーザプロキシは、Web ブラウザのクライアントソースから提供されるハンドラタイルのスクリプトを実行します。
(G) ユーザプロキシは、クライアントにハンドラタイルを送信します。
2. 暗黙的な許可タイプは、refresh_token（または自動実行可能）機構をサポートしません。
3. ユーザーが暗黙的な許可フローを使用して初めてアプリを認証するときは、アクセス トークンを保存してください。アクセス トークンを取得した後は、再認証を試行しないでください。保存したアクセス トークンは引き続き機能するはずです。
access_token (redirect_uri のフラグメント中、つまり uri 中の # 部分に存在します) を取得すると、クライアントは access_token を自己保存する必要があります。
4. 手動などのクライアント側アプリケーションに適しています。 /桌面客户端程序、浏览器插件等
oauth2-server-php は、この認可メソッドを次のように実装します。
1. この認可メソッドは、認可コード付与 (認可コード付与メソッドを簡略化したもの) に含まれています。
OAuth2Controller を初期化するときは、次のように AuthorizationCode タイプの認証を OAuth2 サーバーに追加するだけです:
$server->addGrantType(new OAuth2GrantTypeAuthorizationCode($storage));
認証コードはデフォルトでは Implicit をサポートしていないため、Grant はサーバー変更する必要があります。 .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 に移行するためにも使用されます。
+----------+
パスワード認証情報
-----> |
|認証 |
| クライアント | イオン更新トークン) | --------+ +------+
図3：资源所有者密码凭据流程
図3中示されたフローには以下のステップが含まれます:
(A) リソース所有者はクライアントにユーザー名とパスワードを提供します。
(B) クライアントは、リソース所有者から受け取った認証情報を含めて、認可サーバーのトークン エンドポイントにアクセス トークンをリクエストします。リクエストを行う際、クライアントは認可サーバーで認証を行います。
(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= restartyou '
戻り値:
{"access_token":"66decd1b10891db5f8f63efe7cc352ce326895c6",
"expires_in":3600,
"token_type":bear" er",
"scope":null,
"refresh_token":"b5 fa0c24e786e37e7ce7d6e2f911805dc65a0d7c"}
ヒント: Github [12] の oauth2-server-php によって提供される SQL スキーマ ユーザー テーブルには user_id フィールドがありません。このフィールド (主キー、auto_increment) を自分で追加する必要があります。
ユーザーテーブルの設計は、ソルトを追加せずに sha1 ダイジェストメソッドを使用します。
== sha1（$ password）;
}
ユーザー認証に関して、この関数を書き直す必要があります。
4番目の認証方法: Client Credentials Grant (Client Credentials Grant)
クライアントが管理対象へのアクセスを要求する場合、または事前に認可サーバーとネゴシエートする場合(使用される方法はこの仕様の範囲外です)他のリソース所有者のリソースが保護されている場合、クライアントはクライアント資格情報 (またはその他のサポートされている認証方法) のみを使用してアクセス トークンを要求できます。
クライアント資格情報のアクセス許可タイプは、機密クライアントのみが使用する必要があります。
| & Gt;-(A) - クライアント認証
| ------------------- --<| +---------------+
図 4 に示すフローには次の手順が含まれます:
(A) クライアントは認可サーバーで認証し、トークン エンドポイントからアクセス トークンを要求します。
(B) 認可サーバーはクライアントを認証し、有効であればアクセス トークンを発行します。
ヒント: これは最も簡単な認証方法です。
認可権限としてクライアント認証を使用するため、他の認可リクエストは必要ありません。
実装は次のとおりです:
1. Oauth2Controller にクライアント認証メソッドのサポートを追加します:
$server->addGrantType(new OAuth2GrantTypeClientCredentials($storage));
credentials 2. access_token を取得します:
curl -u testclient ;
「scope」:null}
ヒント: クライアントは、独自のクライアント ID と client_secret を直接使用して、access_token を取得します。
RFC6749 仕様では、クライアント認証で access_token を取得するときに、クリネット資格情報に refresh_token が含まれないと指定しています [10]。ただし、OAUTH2-Server-PHP は、Oauth2/GrantTypes/Clientcredials.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
クライアントは、「Bearer」HTTP 認証スキームの「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 リクエストを開始します: access_token=mF_9.B5f -4.1JqM
c. HTTP リクエスト URI でアクセス トークンを送信するとき、クライアントは「access_token」パラメータを取得してアクセスを追加します。 「Uniform Resource Identifier (URI): Common Syntax」RFC3986 カードで定義されているリクエスト URI のクエリ部分へのトークン。
クライアントは、トランスポート層セキュリティを使用して次の HTTP リクエストを開始できます:
アクセス トークンは、「Authorization」リクエスト ヘッダー フィールドまたは HTTP リクエスト エンティティ本文で送信できません。
上記の 3 つの access_token の使用方法は、rfc6750 仕様で提案されています。最初のオプションを使用することをお勧めします。 Bearer トークンを使用するには、access_token 送信のセキュリティを確保するために TLS が必要です。
パート 4: Bearer access_token を使用して API を呼び出す
1. access_token:
curl -u testclient:testpass www.yii.com/oauth2/index.php?r=oauth2/token -d の代わりに、refresh_token を使用します。 Grant_type =refresh_token&refresh_token=1ce1a52dff3b5ab836ae25714c714cb86bf31b6f"
戻り値:
{"access_token":"50540a7ead3a27cdb458b6cdc38df25f64da18f 1",
"expires_in ":3600,
"token_type":"bearer",
"scope":null}
新しいrefresh_tokenはありませんここでは、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 権限: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
Grant_type =refresh_token&refresh _トークン=tGzv3JOkF0XG5Qx2TlKWIA
client_id と client_secret を指定する必要があり、grant_type 値はfresh_token である必要があります。
access_token の有効期間中は、refresh_token を使用して新しい access_token を交換することはできません。
2. access_token を使用します:
a. クライアント アプリは、access_token を使用してリソース情報を取得します。
oauth2 サーバー検証 access_token:
curl www.yii.com/oauth2/index.php?r=oauth2/verifytoken -d 'access_token=aea4a1059d3194a3dd5e4117bedd6e07ccc3f402'
戻り値:
{"結果":"成功"、
「メッセージ」:「アクセス トークンは有効です。」
この部分は、クライアント アプリがこのメソッドを直接呼び出す必要はなく、リソースを要求するときにサーバーが独自にこのメソッドを呼び出して続行します。判定結果に応じて異なる治療を行います。
Oauth2拡張機能のServer.phpでaccess_tokenの有効期限を変更できます。
3. スコープ
スコープでは、サーバーが特定の実行可能な操作を決定する必要があります。
スコープは、クライアントが実行できる操作権限を決定するために使用されます。プロジェクト内の操作権限は srbac によって制御されており、当面は Oauth2 で処理されません。
4. state
state は、OAuth2 サーバーに渡され、クライアント アプリが最初のステップで認証コードを取得したときに OAuth2 サーバーによって返されるランダム ハッシュ パラメーターです。 state パラメータは主に、クロスサイト リクエスト フォージェリ (Cross Site Request Forgery、CSRF) を防ぐために使用されます。関連する議論については、この記事の最後にある参考文献 [7] と [8] を参照してください。
参考文献:
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
