IdentityServer 3 + Asp.net ID：スコープ、クレーム、およびクライアント - 明確化

Question

認証と認可のサーバーアーキテクチャのさまざまな部分がどのように機能するかほとんどわかります。私はIdentityServerが大きなソフトウェアだと本当に思っています。

私の発見を要約して、私の質問の根拠を定めることを試みています。

1. IdentityServerはOpenID Connectを使用してトークンを発行します。発行されたトークンはIDトークンとアクセストークンです。
2. OAuth 2.0フローを使用して、トークンがクライアントに要求されます。クライアントごとに1つのフロー。
3. クライアントはスコープのコレクション（少なくとも "openid"、つまりOpenID Connectフローがアクティブ化されていることを伝えなければならないため）を要求します。
4. クライアントは、聞く、質問する。 IdentityServerにEntity Frameworkプラグインを使用する場合、この情報はClientScopeテーブルに含まれています。クライアントが要求する権限がないスコープを要求すると、フローは中断されます。
5. スコープにはクレームが含まれている場合があります。つまり、スコープにクレームのグループが含まれている場合、クライアントにトークンが発行されるたびに、このトークンにはすべての対応するユーザーのクレームも含まれます。たとえば、「役割」という主張を含むスコープを「役割」と呼ぶ。クライアントが承認されるとすぐに、受け取ったトークンにはすべてのユーザーの役割が（請求として）含まれます。
6. 要求された各スコープは、許可されている場合、「スコープ」という名前のクレームで「翻訳」されます。つまり、クライアントが定義された "api"スコープなどを要求した場合、生成されたIDには少なくとも "scope"という値が "api"というクレームがあります。私が書いたもののすべては、より少ない正しい場合

、ここに私の質問は以下のとおりです。クレームがIdentityServerのものに接続されているasp.netのIDテーブル（すなわちAspNetUserClaims）上で定義されているか

1. 。私が見たことでは、その名前に照合が行われます。この結論は正しいのでしょうか？言い換えれば、私のクライアントが（役割の範囲を求めているので）クライアントが "役割"クレームを受け取らなければならない場合、IdentityServerの "Asp.Net Identity"プラグインは、認証されたユーザー？
2. "EntityFramework"プラグインテーブルを参照すると、 "ClientClaims"テーブルの意味は何ですか？クレームをクライアントに直接つなげる方法を知ることはできません...何が欠けていますか？

3. のは、私のリソースサーバで、私はResourceAuthorizeで保護アクションは次のように属性きたと仮定してみましょう：私はチェック私の認可マネージャ・で[ResourceAuthorize（「読む」、「受注」）]

   をクレーム "order_read"またはクレーム "api"の存在。これらはAuthorizationServerで定義された2つの異なるスコープです.1つは「オーダー・リード」、もう1つは完全なAPIアクセスです。最初のものは第三者のクライアントから依頼されることがありますが、後者のクライアントは依頼されません。それはいい練習ですか？

4. 私のクライアントがid_tokenで行うべきことを理解できません。 jsライブラリOIDCトークンマネージャを使用しているので、この問題を無視する必要がありますか？このライブラリによってセキュリティコントロールが実行されていますか？

5. 最後の質問：私のアプリケーションがアクセストークンを提示するとき、どのようにClaimsIdentityが生成されますか？ Identity Server上のトークンを検証した後に生成されると言うことができますか？これは、IdentityServerがアクセストークンを取得し、一連の要求でそれを変換することを意味しますか？

ご協力ありがとうございました！

マルコ

Answer 1

うん、あなたはそれの要点を持っています。ご質問については：

どのようにあなた次第ですasp.netのIDテーブル

に定義された主張です。 IdentityServerはアイデンティティ管理ライブラリを要求しません。 IUserService拡張ポイントは、そのギャップを埋める場所です。私たちはIUserServiceのスターターバージョンを持っていますが、これはコードベースのNuGetで、必要なものを実際に変更することができます。

私は私のクライアントはid_token

で何をすべきかを理解することはできません主に（サインアウト要求を認証するために）サインアウト時にバックIdentityServerに渡すために使用されます。

私のアプリケーションはClaimsIdentityが

を生成されたアクセストークンを検証するためのミドルウェア（AccessTokenValidation）がありますどのように、アクセストークンを提示します。その結果、クレームがトークンから形成され、トークンはClaimsIdentityに変換され、下流の処理（Web APIコードなど）で使用できるようになります。 「ClientClaims」テーブル

Client設定を使用すると、クライアントに代わって請求を発行したい場合はClaims性質を持っているの意味は何

。ドキュメントをチェック：https://identityserver.github.io/Documentation/docsv2/configuration/clients.html

はのは、私のリソースサーバで、私はこの

これはIdentityServerとは無関係であり、IdentityModelライブラリの一部であるようResourceAuthorize属性で保護されたアクションをしたと仮定してみましょう。 ResourceAuthorizeは、承認結果を決定しようとするときに実行されるユーザー、リソース、およびアクションを使用するためのフレームワークです。