認証とリソースサーバー間のOAuthv2通信

OAUTH-v2がどのように機能するかを理解するのに問題があります。

OAuthのバージョン2の仕様は、読み取ります。

7. 保護されたリソースへのアクセス

   クライアントは、アクセス
   トークンをリソースサーバーに提示することにより、保護されたリソースにアクセスします。リソースサーバーは、
   アクセストークンを検証し、有効期限が切れていないこと、およびそのスコープが
   要求されたリソースをカバーしていることを確認する必要があります。リソースサーバーが
   アクセストークン（およびエラー応答）を検証するために使用する方法は、この仕様の範囲を超えていますが、通常、リソースサーバーと承認
   サーバー間の相互作用または調整が含まれます。

リソースサーバーと承認サーバー間のこの相互作用は実際にはどのように機能しますか？

• リソースサーバーは、受信したアクセストークンが有効であるとどのように判断しますか？
• リソースサーバーは、トークンから許可されたスコープをどのように抽出して、特定のリソースにアクセスを許可する必要があるかどうかを確認しますか？スコープはアクセストークンにエンコードされていますか、それともリソースサーバーは最初に承認サーバーに接続する必要がありますか？
• リソースサーバーと承認サーバー間の信頼はどのように確立されますか？

アクセストークンの属性と保護されたリソースへのアクセスに使用されるメソッドは、この仕様の範囲を超えており、コンパニオン仕様によって定義されています。

誰かがトークン属性の例を挙げられますか？

これが仕様の範囲外である理由は、2つのエンティティ間のこの接続を実現するためのさまざまな方法です。主な質問は、展開がどれほど複雑かということです。

たとえば、認証とアクセスを管理する1つのサーバーと、API呼び出しを処理する独自のサーバーを持つ個別のサービスのセットがありますか？または、認証/承認とAPI呼び出しの両方を処理する1つのWebサーバーを備えたボックスが1つだけありますか？

単一のボックスの場合、トークンを発行するエンティティはトークンを検証するエンティティと同じであるため、それほど多くは必要ありません。トークンを実装してデータベーステーブルキーを使用し、リクエストごとにデータベース（またはメモリキャッシュ）のレコードを検索するか、スコープ、ユーザーID、その他の情報をトークンに直接エンコードして、対称または非対称を使用して暗号化することができますアルゴリズム。

分散環境を扱う場合、状況は少し複雑になりますが、それほど複雑ではありません。承認サーバーでトークンを発行しますが、リソースサーバーにはそれらを検証する方法が必要です。リソースサーバーが内部APIを利用できるようにして、認証サーバーにトークンを「解決」するように依頼するか（ローカル環境では高速）、2つで公開鍵と秘密鍵のペアまたは対称秘密を確立できます。これを使用して、リソースサーバーが必要とするすべてのものをトークンに暗号化します。

自己完結型トークンは長くなりますが、リクエストごとにはるかに優れたパフォーマンスを提供します。ただし、価格が付いています。有効な（有効期限が切れていない）間は、実際に取り消すことはできません。このため、自己完結型トークンは非常に短命であり（失効後にアクセスを開いたままにしておくことが許容されるものは何でも-たとえば、多くのサイトは1時間を使用します）、新しいトークンを取得するために1年以上有効な更新トークンを使用します。

リソースから認証サーバーへのAPIの一例は、Google DevelopersWebサイトにあるものです。
アクセストークンの形式は指定されていませんが、応答は非常に普遍的に役立つようです。