Microsoft ID プラットフォームのベスト プラクティスと推奨事項
この記事では、Microsoft ID プラットフォームと統合する場合のベスト プラクティス、推奨事項、よくある見落としについて説明します。 このチェックリストに従うと、高品質で安全な統合を実現できます。 この一覧を定期的に確認して、アプリと ID プラットフォームとの統合の品質とセキュリティを維持してください。 チェックリストは、アプリケーション全体を確認することを目的としていません。 チェックリストの内容は、プラットフォームの改善に伴って変更される可能性があります。
まだ使い始めたばかりの場合は、Microsoft ID プラットフォームのドキュメントを確認して、Microsoft ID プラットフォームでの認証の基本、アプリケーション シナリオなどについて学習してください。
次のチェックリストは、アプリケーションが Microsoft ID プラットフォームと効果的に統合されていることを確認するために使用します。
ヒント
"統合アシスタント" は、これらのベスト プラクティスと推奨事項の多くを適用するのに役立ちます。 アシスタントを使い始めるには、いずれかのアプリの登録を選び、[統合アシスタント] メニュー項目を選択します。
基本
Microsoft プラットフォーム ポリシーを読んで理解します。 ユーザーとプラットフォームを保護するために設計時に要点をまとめた条項にアプリケーションが従っていることを確認します。
所有権
アプリの登録と管理に使用したアカウントに関連付けられている情報が最新であることを確認します。
ブランディング
「アプリケーションのブランド化ガイドライン」に従います。
アプリケーションにわかりやすい名前とロゴを用意します。 この情報は、アプリケーションの同意プロンプトに表示されます。 ユーザーが情報に基づいて決定を下せるように、名前とロゴが会社や製品を表現するものにします。 商標に違反していないことを確認します。
プライバシー
アプリのサービス使用条件とプライバシーに関する声明のリンクを用意します。
セキュリティ
リダイレクト URI を管理します。
- すべてのリダイレクト URI の所有権を維持し、それらの DNS レコードを最新の状態に保ちます。
- URI にワイルドカード (*) を使用しないでください。
- Web アプリの場合は、すべての URI がセキュリティで保護され、暗号化されていることを確認します (たとえば、https スキームの使用など)。
- パブリック クライアントの場合、該当する場合 (主に iOS および Android) はプラットフォーム固有のリダイレクト URI を使用します。 それ以外の場合は、アプリにコール バックするときの競合を防ぐために、ランダム性が高いリダイレクト URI を使用します。
- アプリが独立した Web エージェントから使用されている場合は、
https://login.microsoftonline.com/common/oauth2/nativeclientを使用できます。 - 未使用または不要なリダイレクト URI を定期的に確認して整理します。
アプリがディレクトリに登録されている場合は、アプリ登録所有者の一覧を最小化して手動で監視します。
明示的に必要な場合を除き、OAuth2 の暗黙的な許可フローのサポートを有効にしないでください。 有効なシナリオについては、こちらを参照してください。
ユーザー名/パスワードにうまく対処します。 ユーザーのパスワードを直接処理するリソース所有者パスワード資格情報フロー (ROPC) は使わないでください。 このフローには高度な信頼とユーザーの公開が必要であり、他のより安全なフローを使用できない場合にのみ使用します。 このフローは、一部のシナリオ (DevOps など) ではまだ必要ですが、それを使用するとアプリケーションに制約が課せされることに注意してください。 最新の手法については、「認証フローとアプリケーションのシナリオ」を参照してください。
Web アプリ、Web API、およびデーモン アプリに対応した機密アプリの資格情報を保護および管理します。 パスワードの資格情報 (クライアント シークレット) ではなく、証明書の資格情報を使用します。 パスワードの資格情報を使用する必要がある場合は、手動で設定しないでください。 資格情報は、コードまたは構成に格納しないでください。また、資格情報の人間による処理を許可しないでください。 可能であれば、Azure リソースのマネージド ID または Azure Key Vault を使用して資格情報を格納し、定期的にローテーションします。
アプリケーションで最低限の特権のアクセス許可が要求されていることを確認します。 アプリケーションに絶対に必要なアクセス許可のみを必要なときにのみ必須とします。 各種アクセス許可を理解します。 必要に応じて、アプリケーションのアクセス許可のみを使用します。可能であれば、委任されたアクセス許可を使用してください。 Microsoft Graph のアクセス許可の一覧については、こちらのアクセス許可リファレンスを参照してください。
Microsoft ID プラットフォームを使用して API をセキュリティで保護している場合は、公開する必要があるアクセス許可について慎重に検討します。 ソリューションに適した細分性と、管理者の同意が必要なアクセス許可を考慮します。 どのような承認でも、決定する前に受信トークンで予想されるアクセス許可を確認します。
実装
最新の認証ソリューション (OAuth 2.0、OpenID Connect) を使用して安全にユーザーのサインインを行います。
OAuth 2.0 や Open ID などのプロトコルに対する直接的なプログラミングは行いません。 代わりに、Microsoft Authentication Library (MSAL) を活用してください。 MSAL ライブラリでは、使いやすいライブラリ内に安全にセキュリティ プロトコルがラップされており、条件付きアクセスのシナリオに対する組み込みのサポート、デバイス全体のシングル サインオン (SSO)、および組み込みのトークン キャッシュ サポートを利用できます。 詳細については、Microsoft でサポートされているクライアント ライブラリの一覧を参照してください。 認証プロトコル用に手作業でコーディングする必要がある場合、Microsoft SDL か同様の開発手法に従ってください。 各プロトコルの標準仕様におけるセキュリティの考慮事項に十分注意してください。
アクセス トークンの値を調べたり、クライアントとして解析を試みたりしないでください。 値や形式が変化したり、警告なしで暗号化されたりする可能性があります。クライアントでユーザーに関する情報が必要な場合は、常に ID トークンを使ってください。 アクセス トークンの解析は、Web API でのみ行う必要があります (これは、形式の定義と暗号化キーの設定は、Web API で行われているためです)。 アクセス トークンは、特定のリソースへのアクセスを許可する機密の資格情報であるため、クライアントがそれを API に直接送信することはセキュリティ リスクです。 開発者は、アクセス トークンを検証するためにクライアントを信頼できると想定しないようにする必要があります。
Azure Active Directory Authentication Library (ADAL) から Microsoft Authentication Library へ既存のアプリを移行します。 MSAL は Microsoft の最新の ID プラットフォーム ソリューションであり、.NET、JavaScript、Android、iOS、macOS、Python、Java で利用できます。 ADAL.NET、ADAL.js、および ADAL.NET と iOS ブローカーアプリの移行に関する詳細を確認してください。
モバイル アプリの場合、アプリケーションの登録エクスペリエンスを使用して、各プラットフォームを構成します。 アプリケーションでのシングル サインインに Microsoft Authenticator または Microsoft ポータル サイトを利用するには、アプリに "ブローカー リダイレクト URI" が構成されている必要があります。 これにより、認証後に Microsoft からアプリケーションに制御を返すことができます。 各プラットフォームを構成するときに、アプリの登録エクスペリエンスにプロセスが表示されます。 クイックスタートを使用して、実際の例をダウンロードします。 iOS 上では、可能な限りブローカーと System Webview を使用します。
Web アプリまたは Web API では、アカウントごとに 1 つのトークン キャッシュを保持します。 Web アプリの場合、トークン キャッシュは、アカウント ID によってキー指定されている必要があります。 Web API の場合、アカウントは、API の呼び出しに使用されるトークンのハッシュによって、キー指定されている必要があります。 MSAL.NET では、.NET と .NET Framework の両方でカスタム トークン キャッシュのシリアル化が提供されます。 セキュリティとパフォーマンス上の理由から、ユーザーごとに 1 つのキャッシュをシリアル化することをお勧めします。 詳細については、トークン キャッシュのシリアル化に関するページを参照してください。
アプリに必要なデータを Microsoft Graph を介して入手できる場合は、個々の API ではなく Microsoft Graph エンドポイントを使用してこのデータに対するアクセス許可を要求します。
エンド ユーザー エクスペリエンス
同意エクスペリエンスを理解し、アプリを信頼するかどうかを判断できる十分な情報がエンド ユーザーと管理者に与えられるように、アプリの同意プロンプトを構成します。
対話フローの前にサイレント認証 (サイレント トークン取得) を試行することで、アプリの使用中にユーザーがログイン資格情報を入力する必要がある回数を最小限に抑えます。
サインインするたびに "prompt=consent" を使わないでください。 追加のアクセス許可について同意を求める必要があると判断した場合 (たとえば、アプリに必要なアクセス許可を変更した場合など) に限り、"prompt=consent" を使います。
該当する場合は、ユーザー データを使用してアプリケーションを強化します。 これを行うには、Microsoft Graph API を使用するのが簡単です。 初めて利用するときに役立つ Graph エクスプローラー ツール。
管理者がテナントに簡単に同意を許可できるように、アプリに必要なすべてのアクセス許可を登録します。 実行時に増分同意を使用して、最初の起動時に要求されたときにユーザーが懸念する、または混乱する可能性があるアクセス許可をアプリケーションが要求する理由をわかりやすくします。
クリーン シングル サインアウト エクスペリエンスを実装します。 これはプライバシーとセキュリティの要件であり、優れたユーザー エクスペリエンスのために役立ちます。
テスト
ユーザーがアプリケーションを使うことができるかどうかに影響する条件付きアクセス ポリシーをテストします。
サポートする予定がある可能性のあるすべてのアカウント (職場または学校のアカウント、個人用の Microsoft アカウント、子供のアカウント、ソブリン アカウントなど) を使用してアプリケーションをテストします。
その他のリソース
v2.0 についての詳細な情報: