トークン生成のためのユーザ認証情報、プライベートIdentityServerの外部認証プロバイダの使用

Question

私はいくつかのクライアントのためにトークンを提供するはずのセキュリティバックエンドを設計しており、多くのAPIを保護しています。ユーザーデータベースはAzure B2C https://azure.microsoft.com/en-us/services/active-directory-b2c/です。 ユーザーアクセスに基づいて異なる主張を含むAPIトークンを作成したいとします。例：ユーザーAは/ api/stores/11を呼び出せますが、/ api/stores/12は呼び出せません。

ユースケース：ユーザーのログインおよびトークン生成のためのAzure B2Cに直接行く

• アプリ（アプリ）。このトークンを使用して、ユーザープロファイルのソーシャルインタラクションなどのAPIを呼び出します。
• アクセス権の制限と同じAPI（異なるモジュール）を呼び出す外部システム。外部システムには管理者がおり、Azure B2Cから資格を取得します。これまで

私のソリューション：

1. IdentityServer4（https://github.com/IdentityServer/IdentityServer4）ユーザー資格情報を検証するためのAzureのB2Cログインを呼び出します。
2. 認証が完了すると（コールバック時）、IdentityServerは外部システムに対するユーザーの所有権（アクセス権など）を適用し、トークンを生成します。 IdentityServerには、ユーザーIDと電子メールをアクセス権で接続するローカルデータベースがあります。
3. APIは、マルチテナント認証プロバイダを使用して、Azure B2Cと私の "中間" IdentityServerのトークンの両方をサポートします。プロバイダはそれぞれIdentityServerAuthenticationとOpenIdConnectAuthenticationです。

これは実行可能な解決策ですか？それはあまりにも複雑ですか？この場合、あなたはどうしたら違うのですか？ 2番目のユーザーログインを実装する必要はありません。Azure B2Cは細かいアクセス権をサポートしていないようです。

ありがとうございます。

Answer 1

これは実際には非常に一般的なアーキテクチャです。

コアIDとトークンプラットフォームはで所有されていますが、これは唯一正しいことです。

次に、どのようなメカニズム（あなたの場合はAzure B2C）を使用して認証を行うことができます。将来、ユーザーやその他の認証メカニズムを使用してローカルデータベースを追加することもできます。それはまったく問題ありません。

重要な点は、アプリケーションが気にしないことです。彼らが知っているのはあなたのプラットフォームです（あなたのケースでは、identityserverを使用して構築されています）。ある日決めたら、認証プロバイダを変更する必要があります。これは問題ありません。あなたのアプリケーションはその事実から保護されています。

この時点で、あなたのアプリケーションとサービスは、identityserverからのトークンだけを信頼する必要があります。 - identityserverは、外部の当事者との信頼を仲介します。

Answer 2

これはIdentityServer4で非常に有効です。ユースケースを提供することができます。私はsamplesをチェックアウトすることをお勧めします。