Microsoft ID プラットフォームと Microsoft Entra ID を使用して、デーモン アプリケーションの回復性を高める方法について説明します。 バックグラウンド プロセス、サービス、サーバー間アプリ、およびユーザーなしのアプリケーションに関する情報を検索します。
次の図は、Microsoft ID プラットフォームを呼び出すデーモン アプリケーションを示しています。
Azure リソースのマネージド ID
Microsoft Azure でデーモン アプリを構築する場合は、シークレットと資格情報を処理する Azure リソースのマネージド ID を使用します。 この機能により、証明書の有効期限、ローテーション、または信頼を処理することで回復性が向上します。
マネージド ID は、有効期間の長いアクセス トークンと Microsoft ID プラットフォームからの情報を使用して、トークンの有効期限が切れる前に新しいトークンを取得します。 アプリは、新しいトークンの取得中に実行されます。
マネージド ID はリージョン エンドポイントを使用します。これは、サービスの依存関係を統合することでリージョン外の障害を防ぐのに役立ちます。 リージョン エンドポイントでは、地理的な領域でトラフィックを維持することができます。 たとえば、Azure リソースが WestUS2 内にある場合は、すべてのトラフィックが WestUS2 内にとどまります。
Microsoft Authentication Library
デーモン アプリを開発し、マネージド ID を使用しない場合は、認証と承認に Microsoft Authentication Library (MSAL) を使用します。 MSAL を使用すると、クライアント資格情報を提供するプロセスが容易になります。 たとえば、アプリケーションは、証明書ベースの資格情報を使用して JSON Web トークン アサーションを作成して署名する必要はありません。
Microsoft 認証ライブラリ (MSAL) の概要を参照してください。
.NET 開発者向けの Microsoft.Identity.Web
ASP.NET Core でデーモン アプリを開発する場合は、Microsoft.Identity.Web ライブラリを使用して承認を容易にします。 これには、複数のリージョンで実行される分散アプリの分散トークン キャッシュ戦略が含まれています。
詳細情報：
トークンのキャッシュと格納
認証と承認に MSAL を使用しない場合は、トークンのキャッシュと格納に関するベスト プラクティスがあります。 MSAL は、これらのベスト プラクティスを実装し、従います。
アプリケーションは ID プロバイダー (IdP) からトークンを取得して、保護された API を呼び出すアプリケーションを承認します。 アプリがトークンを受け取ると、トークンを含む応答には、トークンをキャッシュして再利用する期間をアプリケーションに伝える expires\_in プロパティが含まれます。 アプリケーションで expires\_in プロパティを使用してトークンの有効期間を決定することを確認します。 アプリケーションが API アクセス トークンをデコードしようとしないことを確認します。 キャッシュされたトークンを使用すると、アプリと Microsoft ID プラットフォームの間の不要なトラフィックを防ぐことができます。 ユーザーは、トークンの有効期間中にアプリケーションにサインインします。
Microsoft Entra ID バックアップ認証システムは、サポートされているプロトコルとフローを使用するアプリケーションに回復性を提供します。 バックアップ認証を利用するためのアプリケーション要件の詳細については、バックアップ認証 システムのアプリケーション要件を参照してください。
HTTP 429 および 5xx エラー コード
HTTP 429 および 5xx エラー コードについては、次のセクションを参照してください。
HTTP 429
回復性に影響する HTTP エラーがあります。 アプリケーションが HTTP 429 エラー コード (要求が多すぎます) を受け取った場合、Microsoft ID プラットフォームによって要求が調整され、アプリがトークンを受信できなくなります。 Retry-After 応答フィールドの時間が経過するまで、アプリがトークンを取得しようとしないようにしてください。 多くの場合、429 エラーは、アプリケーションがトークンを正しくキャッシュおよび再利用していないことを示しています。
HTTP 5xx
アプリケーションが HTTP 5x エラー コードを受け取った場合、アプリは高速再試行ループに入らてはなりません。 [ Retry-After ]\(再試行後\) フィールドの有効期限が切れるまでアプリケーションが待機していることを確認します。 応答に Retry-After ヘッダーがない場合は、最初の再試行 (応答の少なくとも 5 秒後) で指数バックオフ再試行を使用します。
要求がタイムアウトしたら、アプリケーションがすぐに再試行しないことを確認します。 前に示した指数バックオフ再試行を使用します。