開発するクライアントアプリケーションで認証と認可の回復性を向上させる

[アーティクル]
12/13/2023

Microsoft ID プラットフォームと Microsoft Entra ID を使用してユーザーのサインインを行い、それらのユーザーに代わってアクションを実行するクライアントアプリケーションで回復性を強化する方法を学習します。

Microsoft Authentication Library (MSAL) を使用する

Microsoft Authentication Library (MSAL) は、Microsoft ID プラットフォームの一部です。 MSAL ではトークンを取得、管理、キャッシュ、および更新します。回復性のベストプラクティスを使用します。 MSAL は、開発者がセキュリティで保護されたソリューションを作成するのに役立ちます。

詳細情報:

MSAL では、トークンがキャッシュされ、サイレントトークン取得パターンが使用されます。 MSAL では、ユニバーサル Windows プラットフォーム (UWP)、iOS、Android などのセキュリティで保護されたストレージをネイティブに提供するオペレーティングシステムでトークンキャッシュをシリアル化します。以下を使用している場合はシリアル化の動作をカスタマイズします。

Microsoft.Identity.Web
MSAL.NET
MSAL for Java
MSAL for Python

詳細情報:

MSAL を使用する場合、トークンのキャッシュ、更新、およびサイレント取得がサポートされます。単純なパターンを使用して、認証用のトークンを取得します。多くの言語がサポートされています。 Microsoft ID プラットフォームコードサンプルでコードサンプルを検索します。

C#
JavaScript

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

return myMSALObj.acquireTokenSilent(request).catch(error => {
    console.warn("silent token acquisition fails. acquiring token using redirect");
    if (error instanceof msal.InteractionRequiredAuthError) {
        // fallback to interaction when silent call fails
        return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {
            console.log(tokenResponse);

            return tokenResponse;
        }).catch(error => {
            console.error(error);
        });
    } else {
        console.warn(error);
    }
});

MSAL ではトークンを更新できます。 Microsoft ID プラットフォームは、有効期間が長いトークンを発行するときに、トークンを更新するための情報をクライアントに送信できます (refresh_in)。古いトークンが有効な間はアプリが実行されますが、別のトークンの取得には時間がかかります。

MSAL リリース

認証はアプリセキュリティの一部であるため、開発者は最新の MSAL リリースを使用するプロセスを構築することをお勧めします。このプラクティスは、開発中のライブラリに使用し、アプリの回復性を向上させます。

最新バージョンとリリースノートを検索します。

トークン処理のための回復性があるパターン

MSAL を使用しない場合は、回復性があるパターンをトークン処理に使用します。 MSAL ライブラリではベストプラクティスが実装されています。

一般的に、先進認証を使用するアプリケーションでは、エンドポイントを呼び出して、ユーザーを認証するトークンを取得したり、アプリケーションが保護された API を呼び出すことを承認したりします。 MSAL は認証を処理し、回復性を向上させるためのパターンを実装します。 MSAL を使用しない場合は、ベストプラクティスについてこのセクションのガイダンスを使用してください。それ以外の場合は、MSAL はベストプラクティスを自動的に実装します。

トークンをキャッシュする

アプリが Microsoft ID プラットフォームからトークンを正確にキャッシュするようにします。アプリがトークンを受け取った後、トークンを含む HTTP 応答には、キャッシュする期間と、それを再利用するタイミングを示す expires_in プロパティがあります。アプリケーションが API アクセストークンをデコードしようとしないことを確認します。

アプリケーションを実行しているデバイス上のトークンキャッシュを介して Microsoft ID プラットフォームを呼び出すアプリの図。

キャッシュされたトークンでは、アプリと Microsoft ID プラットフォーム間の不要なトラフィックを防ぎます。このシナリオでは、トークン取得呼び出しを減らすことで、アプリがトークン取得エラーの影響を受けにくくなります。キャッシュされたトークンでは、アプリがトークンの取得をブロックする頻度が低くなるため、アプリケーションのパフォーマンスが向上します。ユーザーは、トークンの有効期間中、アプリケーションにサインインしたままです。

トークンをシリアル化および永続化する

アプリがトークンキャッシュを安全にシリアル化して、アプリインスタンス間でトークンを保持するようにします。有効期間中にトークンを再利用する。更新トークンとアクセストークンが何時間も発行されます。この間に、ユーザーがアプリケーションを複数回起動する場合があります。アプリが起動したら、有効なアクセスまたは更新トークンを検索することを確認します。これにより、アプリの回復性とパフォーマンスが向上します。

詳細情報:

永続的トークンストレージに、ユーザー所有者またはプロセス ID に関するアクセス制御と暗号化があることを確認します。さまざまなオペレーティングシステムには、資格情報ストレージ機能があります。

トークンをサイレントに取得する

ユーザーを認証したり、API を呼び出すための認可を取得したりするためには、Microsoft ID で複数の手順が必要です。たとえば、初めてサインインするユーザーは資格情報を入力し、多要素認証を実行します。各ステップは、サービスを提供するリソースに影響します。依存関係が最も少ない最適なユーザーエクスペリエンスは、サイレントトークンの取得です。

ユーザー認証または承認の完了に役立つ Microsoft ID プラットフォームサービスの図。

サイレントトークンの取得は、アプリのトークンキャッシュにある有効なトークンから開始されます。有効なトークンがない場合、アプリは使用可能な更新トークンとトークンエンドポイントを使用してトークンの取得を試行します。どちらのオプションも使用できない場合、アプリは prompt=none パラメーターを使用してトークンを取得します。このアクションでは承認エンドポイントが使用されますが、ユーザーの UI は表示されません。可能であれば、Microsoft ID プラットフォームはユーザーの操作なしにアプリにトークンを提供します。トークンを生成するメソッドがない場合、ユーザーは手動で再認証します。

Note

一般的に、アプリで 'ログイン' や '同意' などのプロンプトが使用されないようにします。これらのプロンプトは、操作が必要ない場合に、ユーザーの操作を強制します。

応答コードの処理

応答コードについては、次のセクションを参照してください。

HTTP 429 応答コード

回復性に影響するエラー応答があります。アプリケーションが HTTP 429 応答コード (要求が多すぎます) を受信した場合、Microsoft ID プラットフォームによって要求が調整されています。アプリの要求が多すぎる場合は、アプリがトークンを受け取らないように調整されます。 Retry-After 応答フィールド時間が完了する前に、アプリがトークンの取得を試みることを許可しないでください。多くの場合、429 応答は、アプリケーションがトークンを正しくキャッシュおよび再利用していないことを示します。アプリケーションでどのようにトークンがキャッシュされて再利用されているかを確認します。

HTTP 5x 応答コード

アプリケーションが HTTP 5x 応答コードを受信した場合、アプリは高速再試行ループに入ってはなりません。 429 応答にも同じ処理を行います。 "Retry-After" ヘッダーが表示されない場合は、応答から 5 秒以上経過した後に最初の再試行で指数バックオフ再試行を実装します。

要求がタイムアウトした場合、すぐに再試行することは推奨されません。応答から 5 秒以上経過した後に最初の再試行で指数バックオフ再試行を実装します。

多くのアプリケーションと API では、認証するためにユーザー情報が必要です。使用可能なメソッドには、長所と短所があります。

トークン

ID トークンとアクセストークンには、情報を提供する標準の要求があります。必要な情報がトークン内にある場合、最も効率的な手法はトークン要求です。これにより、別のネットワーク呼び出しを防ぐことができます。ネットワーク呼び出しの数が少ないほど、回復性が向上します。

詳細情報:

Note

一部のアプリケーションでは、認証されたユーザーに関する要求を取得するために、UserInfo エンドポイントを呼び出します。 ID トークンの情報は、UserInfo エンドポイントからの情報のスーパーセットです。 UserInfo エンドポイントを呼び出す代わりに、アプリで ID トークンを使用できるようにします。

標準トークン要求を、グループなどの省略可能な要求で拡張できます。 [アプリケーショングループ] オプションには、アプリケーションに割り当てられたグループが含まれます。 [すべて] または [セキュリティグループ] オプションには、同じテナント内のアプリのグループが含まれます。これにより、グループをトークンに追加できます。トークンが肥大化し、グループを取得するためにより多くの呼び出しを必要とすることで、トークンでグループを要求することによって得られる効率性が打ち消される可能性があるので、効果を評価してください。

詳細情報:

ポータルまたは API を使用して顧客が管理するアプリロールを使用して含めることをお勧めします。ユーザーとグループにロールを割り当ててアクセスを制御します。トークンが発行されると、割り当てられたロールはトークンロール要求に含まれます。トークンから派生した情報により、より多くの API 呼び出しを防ぐことができます。

「アプリケーションにアプリロールを追加してトークンで受け取る」を参照してください

テナント情報に基づいて要求を追加します。たとえば、拡張機能には企業固有のユーザー ID があります。

ディレクトリからトークンに情報を追加すると効率的であり、依存関係を減らすことで回復性を向上させることができます。トークンを取得取得できないことによる回復性の問題には対処しません。アプリケーションの主要なシナリオに対する省略可能な要求を追加します。アプリが管理機能の情報を必要とする場合、アプリケーションは必要に応じてその情報を取得できます。

Microsoft Graph

Microsoft Graph には、生産性パターン、ID、セキュリティに関する Microsoft 365 データにアクセスするための統合 API エンドポイントがあります。 Microsoft Graph を使用するアプリケーションでは、承認に Microsoft 365 情報を使用できます。

アプリは、Microsoft 365 にアクセスするために 1 つのトークンを必要とします。これは、複数のトークンを必要とする Microsoft Exchange や Microsoft SharePoint などの Microsoft 365 コンポーネントの以前の API よりも回復性が高くなります。

Microsoft Graph API を使用する場合は、Microsoft Graph にアクセスする回復性のあるアプリケーションの構築を簡略化する Microsoft Graph SDK を使用します。

「Microsoft Graph SDK の概要」を参照してください

承認のために、一部の Microsoft Graph 呼び出しの代わりにトークン要求を使用することを検討してください。トークン内でグループ、アプリロール、および省略可能な要求を要求する。承認のための Microsoft Graph では、Microsoft ID プラットフォームと Microsoft Graph に依存するより多くのネットワーク呼び出しが必要です。ただし、アプリケーションがデータレイヤーとして Microsoft Graph に依存している場合、承認のための Microsoft Graph のリスクは高くはありません。

モバイルデバイスでブローカー認証を使用する

モバイルデバイスでは、Microsoft Authenticator のような認証ブローカーが回復性を向上させます。認証ブローカーは、ユーザーとデバイスに関する要求を含むプライマリ更新トークン (PRT) を使用します。認証トークンに PRT を使用して、デバイスから他のアプリケーションにアクセスします。 PRT からアプリケーションアクセスを要求すると、Microsoft Entra ID ではそのデバイスと MFA 要求を信頼します。これにより、デバイスを認証するための手順を減らすことで、回復性が向上します。ユーザーは、同じデバイス上の複数の MFA プロンプトに悩まされることはありません。

「プライマリリフレッシュトークンとは」を参照してください。

アプリケーションを実行しているデバイス上のトークンキャッシュ、トークンストアおよび認証ブローカーを介して Microsoft ID プラットフォームを呼び出すアプリの図。

MSAL では、ブローカー認証がサポートされています。詳細情報:

継続的アクセス評価

継続的アクセス評価 (CAE) は、有効期間が長いトークンを使用してアプリケーションのセキュリティと回復性を高めることができます。 CAE では、短いトークンの有効期間ではなく、重大なイベントとポリシーの評価に基づいてアクセストークンを取り消すことができます。一部のリソース API については、リスクとポリシーがリアルタイムで評価されるため、CAE によりトークンの有効期間を最大 28 時間まで延長することができます。 MSAL は、有効期間の長いトークンを更新します。

詳細情報:

リソース API を開発する場合は、openid.net で「共有シグナル - セキュリティで保護された Webhooks Framework」を参照してください。

次の方法で共有

開発するクライアントアプリケーションで認証と認可の回復性を向上させる