質問するのが難しいので、中途半端な OAuth 2.0 ソリューションについて説明させてください。
現在、信頼できる許可のみを使用しており、ユーザー名とパスワードを要求しています。これらの資格情報が正常に認証されると、アクセス トークンと更新トークンが発行されます。ただし、その応答メッセージにはスコープ情報がありません。OAuth2 仕様では、スコープがリクエストで提供された場合、それをレスポンスでも返す必要があると規定されていますが、許可されたスコープがリクエストされたスコープと異なる場合に限られます。いずれにしても、トークンにスコープを割り当てるのではなく、ユーザーが検証済みであることを示すトークンのみを割り当てます。これは私には適切ではありませんが、考えすぎているのかもしれません。
フローの後半で、クライアントは、特定のロールにのみ付与された Web サイトへのログインなど、保護されたリソースへのアクセスを試みます。そのため、認証されている (アクセス トークンを持っている) 場合でも、役割が原因でこのサイトへのログインが許可されない場合があります。現在これを検証する方法は、リソース エンドポイントにアクセス トークンを送信することです。次に、そのエンドポイントは、アクセスしようとしている uri とともにトークンを検証サーバーに送信します。検証サーバーは、トークンが適切であること、およびロール (データベース内のトークン エントリによって検索されます) によってアクセスが許可されていることを検証します。 200 を返して続行を許可するか、そのエンドポイントへのアクセス権がないことを示す 403 を返します。つまり、アクセス トークンにはスコープが直接割り当てられていません。むしろ、それはあなたが誰であるかを教えてくれるだけで、私たちはあなたのパーミッションを調べてリクエストと比較し、賛成か反対かを判断します。これは私には奇妙に思えます。
私が見た他の実装では、実際には次のように機能するはずだという印象を受けました。
- アクセス トークンを要求すると、資格情報が正常に検証された場合にトークンが生成されます。
- 次に、認証サーバーはリクエストされたスコープを調べ、リクエストされたスコープの承認された部分 (部分的または完全) と共にデータベースにトークンを生成します。むしろ、abc と d をリクエストしたが、b と d のみが承認された場合、データベースに保存されているトークンは、そのトークンで b と c のみが許可されていることを反映します。
- 承認されたスコープと共にトークン文字列がクライアントに送り返されます。
- 保護されたリソースのリクエスト中に、データベースでトークンを検索し、リクエストされたリソースを、提供されたトークンのスコープ エントリにあるものと比較してから、ユーザーのアクセス許可を検索するのではなく、yay または nay を返します。
違いは何ですか？TOKEN にはスコープが含まれているという印象を受けました。したがって、ユーザー A がリソース ABCD と E を許可されているが、BC と F を要求した場合、トークンは B と C に対してのみ有効になります。彼は AD または E を要求しておらず、F を許可されていないため、トークンはそれらを許可していません。それは理にかなっていますか？
だから私の質問はこれです。現在の実装は、それが使用されるはずの方法についての私の理解に基づいて間違っていますか? 私の理解は正しいですか？