[解決済み] OAuth v2による認証サーバーとリソースサーバー間のコミュニケーション

質問

OAUTH-v2がどのように機能するか理解するのに苦労しています。

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

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

   クライアントは、保護されたリソースにアクセスするために リソースにアクセスするために
   
   トークンをリソースサーバに提示します。 リソースサーバーは を検証しなければなりません。
   
   アクセストークンを検証し、それが有効期限内であること 有効期限が切れていないこと、そしてそのスコープが
   
   をカバーすることを確認します。 リソースサーバーが にリソースサーバが使用するメソッドです。
   
   アクセストークンを検証するためにリソースサーバが使用するメソッド（および を検証するために使用されるメソッドです。 を超えています。 この仕様の範囲外です。 ですが 一般に リソース間の相互作用や リソースサーバーと認証サーバーの間の サーバと認可
   
   サーバ .

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

• リソースサーバーはどのようにして 受け取ったアクセストークンが有効であることを どのように判断するのですか？
• リソースサーバーはどのようにして リソースサーバーはどのように許可された スコープをどのように抽出するのでしょうか？スコープはアクセストークンにエンコードされているのか、それともリソースサーバーが最初に認証サーバーにコンタクトしなければならないのか？
• リソースサーバーと認証サーバーの間の信頼はどのように確立されますか？

アクセストークンの属性と 保護されたリソースへのアクセスに使用されるメソッド リソースにアクセスするために使用されるメソッドは の範囲外です。 仕様の範囲外です。 で定義されており で定義されています。

どなたかトークン属性の例を教えてください。

どのように解決するのですか？

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

たとえば、認証とアクセスを管理する1つのサーバーと、APIコールを提供する独自のサーバーを持つ個別のサービスのセットがそれぞれあるのでしょうか。または、認証/認可と API 呼び出しの両方を処理する 1 つの Web サーバーを備えた 1 つのボックスがあるだけでしょうか。

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

分散環境を扱うときは少し複雑になりますが、それほど大きな差はありません。認証サーバでトークンを発行することに変わりはありませんが、リソースサーバはそれを検証する方法が必要です。リソースサーバーが内部APIを利用できるようにして、認証サーバーにトークンの解決(ローカル環境では高速)を依頼するか、または公開/秘密鍵ペアまたは共通鍵を確立して、リソースサーバーが必要とするすべてをトークンに暗号化して使用することが可能です。

自己完結型トークンはより長いですが、リクエストごとのパフォーマンスははるかに優れています。しかし、その代償として、有効期間内（期限切れでない）であれば、実際に取り消すことができないのです。このため、自己完結型トークンは非常に短命であるべきで、（取り消した後にアクセスを開いたままにするために許容できる範囲であれば何でもよく、たとえば多くのサイトでは 1 時間を使っています）新しいトークンを取得するために 1 年以上有効なリフレッシュ トークンを持つべきです。