OAuth認証とリソースサーバー間のv2通信
OAUTH-v2の仕組みを理解するのに問題があります。
OAuthバージョン2仕様 は次のようになります。
保護されたリソースへのアクセス
クライアントはアクセスを提示することで保護されたリソースにアクセスします
リソースサーバーへのトークン。リソースサーバーは、
アクセストークン。有効期限が切れていないことと、その範囲がカバーしていることを確認してください
リクエストされたリソース。リソースサーバーが使用するメソッド
アクセストークン（およびすべてのエラー応答）がこの仕様の範囲外であることを検証しますが、一般的にはリソースサーバーと承認の間の相互作用または調整を伴う
server。
リソースサーバーと承認サーバー間のこの相互作用は、実際にはどのように機能しますか？
- リソースサーバーは、受信したアクセストークンが有効であるとどのように判断しますか？
- リソースサーバーは、トークンから許可されたスコープをどのように抽出して、特定のリソースへのアクセスを許可する必要があるかを確認しますか？スコープはアクセストークンにエンコードされていますか、それともリソースサーバーは最初に承認サーバーに接続する必要がありますか？
- リソースサーバーと承認サーバーの間の信頼はどのように確立されますか？
保護されたリソースにアクセスするために使用されるアクセストークン属性とメソッドはこの仕様の範囲を超えており、コンパニオン仕様によって定義されます。
誰かがトークン属性の例を挙げられますか？
これが仕様の範囲外である理由は、2つのエンティティ間のこの接続を実現するためのさまざまな方法です。主な問題は、展開がいかに複雑かということです。
たとえば、認証とアクセスを管理する1つのサーバーと、それぞれがAPI呼び出しを処理する独自のサーバーを持つ個別のサービスのセットがありますか？または、認証/承認とAPI呼び出しの両方を処理する1つのWebサーバーを備えた1つのボックスしかありませんか？
単一のボックスの場合、トークンを発行するエンティティはトークンを検証するエンティティと同じであるため、それほど必要ではありません。トークンを実装してデータベーステーブルキーを使用し、リクエストごとにデータベース（またはメモリキャッシュ）のレコードを検索するか、スコープ、ユーザーID、その他の情報をトークンに直接エンコードして、対称または非対称を使用して暗号化できます。アルゴリズム。
分散環境を扱う場合、状況は少し複雑になりますが、それほど複雑ではありません。承認サーバーでトークンを発行しますが、リソースサーバーはそれらを検証する方法が必要です。リソースサーバーが内部APIを利用できるようにすることでそれを行うことができ、承認サーバーにトークンを「解決」するように要求します（ローカル環境では高速である場合があります）、または2つは公開/秘密キーのペアまたは対称秘密を確立できます。これを使用して、リソースサーバーがトークンに必要なすべてのものを暗号化します。
自己完結型トークンは長くなりますが、リクエストごとのパフォーマンスが大幅に向上します。ただし、これらには代償が伴います。有効期限が切れていないまま、無効にすることはできません。このため、自己完結型トークンの有効期間は非常に短く（取り消された後、アクセスを開いたままにしておくことが許容されるものであれば、たとえば、多くのサイトでは1時間使用します）、更新トークンを1年以上使用すると、新しいトークンを取得できます。
リソースから承認サーバーAPIへの1つの例は、 Google Developers Website にあるものです。
ただし、アクセストークンの形式は指定していませんが、応答はかなり一般的に役立ちます。