2

私は、特定のサービスを外部クライアントが使用できるように、ユーザーがユーザーを作成してアプリケーションキーまたは秘密を作成できるようにするプロジェクトを進めています。ユーザーは、複数のクライアント間で使用することを選択できる複数の秘密を作成できます。identityserver4上のユーザー用に複数の外部クライアント

このため、identityserver4を使用するデカップリングされた認証サーバーを作成する予定です。

本当に私を後悔させているのは、認証サーバーでAPIレイヤーを作成する必要があるかどうかわかりません。私が認証サーバーでAPIを検討している理由は、ユーザーにアプリケーションキー/秘密の作成、更新、アクセスのフロントエンドを提供する管理ポータルクライアントの種類を作成できるようにするためです。管理ポータルでさえも、デカップル角度アプリケーションになります。

瞬間に戻って私を保持している2つのものがあります。

  1. は、私はそれが API層を介してこのデータを提供するために良いか安全でしょうかどうかわからないです。私が理解していることから、identityserverはエンドポイント経由でユーザーのクライアントのリストにアクセスできる機能を提供することはできませんが、私が間違っていればこれを修正してください。
  2. 私は新しいクライアントを簡単に作成し、identityserver4を使用してデータベースに永続化することができ、ユーザークライアントにClientCredentials許可タイプを使用する予定ですが、データベースとユーザーとクライアントの間のIDレベルのリンクがありますか?または、自分でその機能を作成する必要がありますか?

これまでのところ、私が見てきたが、私はidentityserver4

のnoobの質問には申し訳ありませんと私の状況と似ている例を見つけることができハチしていない、私は一般的にidentityserverとWebセキュリティに取得していますこれらのコンセプトの多くはまだ私にとって非常に新しいものです。

答えて

1

数字が1の場合は、サーバーデータへのAPIレイヤーを作成できます。 IdenttiyServer4 AdminUIを確認した場合、Rock SolidはUIの背後にある管理APIも使用します。しかし、これを安全に保つためには、暗号化、TLSなどのセキュリティメカニズムを考慮する必要があります。

AFIKは2番ですが、ユーザーとクライアントの間にIDレベルのリンクはありません。あなたはそれを自分で作る必要があります。

基本的には、Multitenancyをサポートするシステムが必要です。 AspNetIdentityユーザーテーブルにTenantIdフィールドを追加することでこれを達成しました。テナントIDを要求リストに追加しました。

私が間違っている場合は、私を修正することをためらわしくはありません。

+0

ありがとうございます。これは私の心配のほとんどを解決しました。 あなたがここで意味していたどの請求リストを確信していませんでした: "また、テナントIDを要求リストに追加しました"。しかし、私はあなたがそれをクライアントのクレームリストに追加し、ユーザーのクレームリストを正しく追加していないことを意味していると仮定しています。 –

+0

いいえ、私はユーザーのクレームを追加しました – MJK

+0

あの場合、テナントはクライアント側のClientIdやクライアント側のようなものと一致する必要はありませんか?基本的には、スキーマを使用して、クライアント2のユーザx、y、zを作成でき、ユーザxだけがクライアント2の所有者です。 –

関連する問題