次の方法で共有

identity 管理ソリューションを選択する

  • [アーティクル]

ほとんどの Web アプリは、ユーザーが本人であることを確認するための認証をサポートしています。 ユーザーは、個人または別のアプリの場合があります。 アクセスを管理すると、ユーザーは表示および変更が許可されている情報のみを表示および変更できるようになります。 たとえば、エンド ユーザーは Web サイトの管理セクションにアクセスできないようにする必要があります。 Identity 管理ソリューションは、認証および認可関連のタスクの要件を処理するために構築されています。 identity 管理の詳細については、「identity およびアクセス管理とは」をご覧ください。 多くの.NET Web アプリ用の identity 管理ソリューションが利用可能であり、それぞれに異なる機能と、使用またはインストールするための要件があります。 この記事では、適切なソリューションを選択する方法についてのガイダンスを提供します。

ASP.NET Core Identity を使用した基本的な identity 管理

ASP.NET Core には、組み込みの認証プロバイダー ASP.NET Core Identity が付属しています。 プロバイダーには、ユーザー ID の管理、ユーザー資格情報の保存、権限の付与または取り消しをサポートする API、UI、バックエンド データベース構成が含まれています。 サポートされるその他の機能は次のとおりです。

ほとんどのシナリオでは、これが必要な唯一のプロバイダーである可能性があります。

詳細については、以下を参照してください。

他のシナリオでは、認証と identity を管理するサーバーまたはサービスが役立つ場合があります。

OIDC サーバーが必要かどうかを判断する

Web は既定でステートレスであるため、Web アプリでは過去のアクションを記憶する方法が必要です。 そうしないと、ユーザーは新しいページに移動するたびに資格情報を入力する必要があります。 状態を記憶するための一般的なソリューションは、データを保存するためのブラウザーベースのメカニズムである Cookie です。 Web サーバーは最初の cookie を送信し、ブラウザーはそれを保存し、要求ごとに送り返します。 これは自動的に行われ、開発者がコードを記述する必要はありません。 Cookie はブラウザーに組み込まれていて使いやすいですが、単一の Web サイトまたは Web ドメイン内で使用するように設計されています。 ASP.NET Core に組み込まれている既定のソリューションは、cookieベースの認証を使用します。

トークンは、HTTP 要求のヘッダーまたは本文を通じて明示的に渡されるメタデータを含むコンテナーです。 Cookie を使用するトークンの主な利点は、トークンが特定のアプリやドメインに結び付いていないことです。 代わりに、トークンは通常、非対称暗号化を使用して署名されます。 たとえば、OIDC サーバーは、署名を含む JSON Web Token (JWT) 形式を使用して、identity に関する情報を含むトークンを発行します。 非対称暗号化では、署名者のみが知っている秘密キーと、すべてのユーザーが知ることができる公開キーの組み合わせが使用されます。 トークンは暗号化することもできます。

秘密キーのため、署名されたトークンを改ざんすることはできません。 公開キー:

  • トークンが変更されていないことを確認するために、トークンを検証できるようになります。
  • 秘密キーを保持するエンティティによって生成されたことを保証します。

トークンを使用する主な欠点は、トークンの発行と検証の両方にサービス (通常は OIDC サーバー) が必要であることです。 サービスはインストール、構成、保守する必要があります。

OIDC サーバーが必要となる一般的な理由は、他のアプリによって使用される Web ベースの API を公開するアプリケーションのためです。 公開された Web ベース API の場合、シングル ページ アプリケーション (SPA)、モバイル クライアント、デスクトップ クライアントなどのクライアント UI は、同じアプリの一部であるとみなされます。 SPA の例には、Angular、React、Blazor WebAssembly が含まれます。 Web アプリ以外のアプリまたはクライアント UI がアプリに対して安全な API 呼び出しを行う必要がある場合は、トークンを使用することをお勧めします。 クライアント UI のみがある場合、ASP.NET Core Identity には、認証中にトークンを取得するオプションが用意されています。 ASP.NET Core Identity によって発行された認証トークン:

  • モバイル クライアントとデスクトップ クライアントで使用できます。 セキュリティと単純さの両方で、トークンよりも Cookie の方が好ましいです。
  • サードパーティ製アプリからのアクセスの管理には適していません。

OIDC サーバーが必要なもう 1 つの理由は、他のアプリとサインインを共有するためです。 一般にシングル サインオンと呼ばれるこの機能により、ユーザーは次のことが可能になります。

  • Web アプリのフォームを使用して 1 回サインインします。
  • 結果として得られた資格情報を使用して、再度サインインしたり、別のパスワードを選択したりすることなく、他のアプリで認証します。

シングル サインオン用の安全でスケーラブルなソリューションを提供するには、通常、OIDC サーバーが推奨されます。

他のアプリとログインを共有しないアプリの場合、アプリを迅速に保護する最も簡単な方法は、組み込みの ASP.NET Core Identity プロバイダーを使用することです。 それ以外の場合は、サードパーティの identity 管理ソリューションによって提供される OIDC サーバーが必要です。 OIDC サーバーは次のように利用できます。

  • サーバーにインストールする製品は、自己ホストと呼ばれます。
  • コンテナーは Docker などのホストで実行されます。
  • identity を管理するために統合する Web ベースのサービス。

無料でオープンソースのソリューションもあれば、商用ライセンスを取得しているソリューションもあります。 利用可能なオプションの一覧については、「identity 管理ソリューション」をご覧ください。 組織がすでに identity プロバイダーを使用している可能性があります。 その場合、別のソリューションを使用するのではなく、既存のプロバイダーを使用することが合理的である可能性があります。 すべての主要なソリューションでは、製品またはサービスを使用するために ASP.NET Core を構成するためのドキュメントが提供されています。

切断されたシナリオ

Microsoft Entra ID などの多くのソリューションはクラウドベースであり、動作するにはインターネット接続が必要です。 インターネットに接続できない環境ではサービスをご利用いただけません。

ASP.NET Core Identity は、次のような切断されたシナリオでも完全に機能します。

  • アプリがインターネットにアクセスできません。
  • インターネットが切断されても、アプリはローカル ネットワーク上で機能し続ける必要があります。

切断されたシナリオで完全な OIDC サーバーが必要な場合は、次のオプションのいずれかを選択します。

  • 独自のマシンにサービスをインストールして実行できるソリューション。
  • 認証サービスをコンテナーとしてローカルで実行します。

サインインなどのユーザー データを保存する場所を決定する

考慮すべきもう 1 つの重要な要素は、ユーザーのサインイン データが保存される場所です。 多くの開発者は、identity の管理に Microsoft Entra ID などの外部のクラウドベースのサービスを選択しています。 クラウドベースのサービス プロバイダー:

  • データを安全に保管する責任を負います。
  • 最新のセキュリティ パッチとリリースによってソフトウェアを最新の状態に保ちます。
  • privacy規制への準拠

規制、コンプライアンス、ポリシー、またはその他の理由により、データを独自のサーバーに保存することを好むユーザーもいます。

データがサーバーに保存されている場合は、インストール可能なソリューションまたはコンテナーベースのソリューションを選択する必要がある可能性があります。

Identity と OIDC サーバー

次の図は、認証と承認に ASP.NET Core Identity システムと OIDC サーバーのどちらを使用するかを決定するのに役立ちます。

Identity 管理決定フロー

次の表は、identity 管理ソリューションを選択する際に考慮すべき事項の一部を示しています。

機能 自己ホスト (インフラストラクチャまたはコンテナー) クラウド
アプリの統合 ライブラリまたはフレームワークとして実装されたローカル ソリューションは、多くの場合、独自のアプリに直接統合できます。 コンテナーベースのソリューションでは、Web アプリとコンテナーベースのサービスの間でハンドオフが発生する必要があります。 クラウドベースのソリューションは通常、サインイン フローの特定のポイントで統合され、テーマに合わせて UI を更新する構成を提供しますが、利用できるカスタマイズのレベルは限られています。
Configuration 自己ホスト ソリューションでは、ID の管理方法を設定するだけでなく、環境に合わせてソフトウェアを構成する必要があります。 コンテナーベースのソリューションは通常、構成用の Web ベースの UI を提供します。 クラウドベースのソリューションは通常、構成用の Web ベースの UI を提供します。
カスタマイズ 自己ホスト ソリューションは通常、コードベースの変更を含め、高度にカスタマイズ可能です。 コンテナー化されたソリューションは拡張性のオプションを提供しますが、多くの場合、より制限されます。 クラウドベースのサービスではカスタマイズが可能ですが、通常は構成ベースの変更に限定されます。
メンテナンス インストールされた製品には、すべてのセキュリティ パッチが適時に適用され、アップグレードを管理するための専用リソースが必要です。 コンテナーのアップグレードとパッチのプロセスは通常、手間が少なく、提供されたコンテナー イメージをインストールするだけです。 サービス プロバイダーは、必要なパッチの適用やアップグレードの処理など、クラウドベースのソリューションを維持します。
ユーザー認証情報のストレージ データ ガバナンスと違反への対応はお客様の責任です。 ユーザー資格情報の取り扱いに関連するリスクを管理し、規制を遵守します。 サービス プロバイダーに委任されます。

使用可能なオプションの詳細については、「IdentityASP.NET Core の管理ソリューション」を参照してください。

次のステップ