MSAL でサポートされている認証フロー
Microsoft Authentication Library (MSAL) では、さまざまなアプリケーションの種類とシナリオで使用するために、いくつかの承認許可と関連するトークン フローがサポートされています。
| Authentication flow | 可能になること | サポートされているアプリケーションの種類 |
|---|---|---|
| 承認コード | ユーザーがユーザーに代わってサインインし、Web API にアクセスする。 | * デスクトップ * モバイル * シングルページ アプリ (SPA) (PKCE が必要) * Web |
| クライアント資格情報 | アプリケーション自体の ID を使用して Web API にアクセスします。 通常は、サーバー間通信や、ユーザー操作を必要としない自動化されたスクリプトに使用されます。 | Daemon |
| デバイス コード | ユーザーは、スマートテレビやモノのインターネット (IoT) デバイスなど、入力に制約のあるデバイスでユーザーに代わって Web API にサインインしてアクセスします。 コマンド ライン インターフェイス (CLI) アプリケーションでも使用されます。 | デスクトップ、モバイル |
| 暗黙的な許可 | ユーザーに代わって、ユーザーのサインインと Web API へのアクセスを行います。 暗黙的な許可フローは推奨されなくなりました。代わりに Proof Key for Code Exchange (PKCE) で承認コードを使用してください。 | * シングルページ アプリ (SPA) * Web |
| On-behalf-of (OBO) | ユーザーに代わって、"アップストリーム" Web API から "ダウンストリーム" Web API にアクセスします。 ユーザーの ID と委任されたアクセス許可は、アップストリーム API からダウンストリーム API に渡されます。 | Web API |
| ユーザー名/パスワード (ROPC) | アプリケーションはパスワードを直接処理することによって、ユーザーをサインインさせることができます。 ROPC フローは推奨されません。 | デスクトップ、モバイル |
| 統合 Windows 認証 (IWA) | ドメインまたはMicrosoft Entra ID参加しているコンピューター上のアプリケーションが、(ユーザーからの UI 操作なしで) トークンをサイレントモードで取得できるようにします。 | デスクトップ、モバイル |
トークン
アプリケーションでは、1 つ以上の認証フローを使用できます。 各フローでは、認証、承認、トークンの更新に特定のトークンの種類が使用され、一部では承認コードも使用されます。
| 認証フローまたはアクション | 必要 | ID トークン | アクセス トークン | リフレッシュトークン | Authorization code (承認コード) |
|---|---|---|---|---|---|
| 承認コード フロー | ✅ | ✅ | ✅ | ✅ | |
| クライアントの資格情報 | ✅ (アプリのみ) | ||||
| デバイス コード フロー | ✅ | ✅ | ✅ | ||
| 暗黙的なフロー | ✅ | ✅ | |||
| On-Behalf-Of フロー | アクセス トークン | ✅ | ✅ | ✅ | |
| ユーザー名/パスワード (ROPC) | ユーザー名、パスワード | ✅ | ✅ | ✅ | |
| ハイブリッド OIDC フロー | ✅ | ✅ | |||
| 更新トークンの使用 | リフレッシュトークン | ✅ | ✅ | ✅ |
対話型と非対話型の認証
これらのフローのいくつかでは、対話型と非対話型の両方のトークンの取得がサポートされています。
- 対話型 - ユーザーに対して、承認サーバーから入力を求めるプロンプトが出される場合があります。 たとえば、サインインを要求したり、多要素認証 (MFA) を実行したり、追加のリソース アクセス許可に対する同意を付与したりすることができます。
- 非対話型 - ユーザーに入力を求めるプロンプトを出せません。 サイレント トークン取得とも呼ばれ、アプリケーションは、承認サーバーがユーザーに入力を求めないようにするメソッドを使用してトークンの取得を試みます。
MSAL ベースのアプリケーションでは、最初にトークンをサイレントで取得しようとします。その後、非対話型での試行が失敗した場合にのみ対話型の方法を試みます。 このパターンの詳細については、「Microsoft Authentication Library (MSAL) を使用してトークンを取得し、キャッシュする」を参照してください。
Authorization code (承認コード)
OAuth 2.0 承認コード許可は、Web アプリ、シングルページ アプリ (SPA)、ネイティブ (モバイルおよびデスクトップ) アプリケーションで使用して、Web API などの保護されたリソースにアクセスできます。
ユーザーが Web アプリケーションにサインインすると、アプリケーションは、Web API を呼び出すアクセス トークンに引き換えることができる承認コードを受け取ります。
前の図で、アプリケーションは:
- アクセス トークンと引き換えられる承認コードを要求します。
- アクセス トークンを使用して、Microsoft Graph などの Web API を呼び出します。
承認コードの制約
認証コード付与フローを使用する場合、シングルページ アプリケーションでは Proof Key for Code Exchange (PKCE) が必要です。 PKCE は MSAL でサポートされています。
OAuth 2.0 仕様では、承認コードを使用してアクセス トークンを 1 回だけ引き換える必要があります。
同じ認証コードでアクセス トークンを複数回取得しようとすると、Microsoft ID プラットフォームによって次のようなエラーが返されます。 一部のライブラリとフレームワークでは自動的に承認コードが要求されるため、そのような場合に手動でコードを要求した場合にもこのエラーが発生するので注意してください。
AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.
クライアントの資格情報
OAuth 2 クライアントの資格情報フローにより、アプリケーションの ID を使って Web でホストされているリソースにアクセスできます。 この種類の許可は、一般的に、ユーザーからの即時の操作なしでバックグラウンドで実行する必要があるサーバー間 (S2S) の対話に使用されます。 これらの種類のアプリケーションは、多くの場合、デーモンまたはサービスと呼ばれます。
クライアント資格情報許可フローでは、Web サービス (Confidential クライアント) が別の Web サービスを呼び出すときに、ユーザーを偽装する代わりに、独自の資格情報を使用して認証することができます。 このシナリオでは、クライアントは通常、中間層の Web サービス、デーモン サービス、または Web サイトです。 高いレベルの保証では、Microsoft ID プラットフォームにより、呼び出し元サービスが、資格情報として (共有シークレットではなく) 証明書を使用することもできます。
アプリケーション シークレット
前の図で、アプリケーションは:
- アプリケーション シークレットまたはパスワード資格情報を使用してトークンを取得します。
- トークンを使用してリソース要求を行います。
証明書
前の図で、アプリケーションは:
- 証明書の資格情報を使用してトークンを取得します。
- トークンを使用してリソース要求を行います。
この種類のクライアント資格情報は次のようにする必要があります。
- Azure AD に登録されている。
- コード内の機密クライアント アプリケーションのオブジェクトの構築時に渡される。
クライアント資格情報の制約
機密クライアント フローは、Android、iOS、ユニバーサル Windows プラットフォーム (UWP) などのモバイル プラットフォームではサポートされていません。 モバイル アプリケーションは、認証シークレットの機密性を保証できないパブリック クライアント アプリケーションと見なされます。
デバイス コード
OAuth 2 デバイス コード フローを使用すると、ユーザーはスマートテレビ、モノのインターネット (IoT) デバイス、プリンターなどの入力に制約のあるデバイスにサインインできます。 Microsoft Entra ID を使用した対話型認証には、Web ブラウザーが必要です。 デバイスまたはオペレーティング システムが Web ブラウザーを提供しない場合、デバイス コード フローを使用すると、コンピューターや携帯電話などの別のデバイスを使用して対話形式でサインインできます。
デバイス コード フローを使用すると、アプリケーションでは、これらのデバイスおよびオペレーティング システム用に設計された 2 ステップ プロセスを通じてトークンを取得します。
前の図で:
- ユーザー認証が必要になるたびに、アプリがコードを提供し、ユーザーに別のデバイス (インターネットに接続されたスマートフォンなど) を使用して特定の URL (たとえば、
https://microsoft.com/devicelogin) に移動するよう求めます。 その後、ユーザーはコードの入力を求め、必要に応じて同意プロンプトや多要素認証などの通常の認証エクスペリエンスを続行します。 - 認証が成功すると、要求元のアプリケーションはMicrosoft ID プラットフォームから必要なトークンを受け取り、それらを使用して必要な Web API 呼び出しを実行します。
デバイス コードの制約
- デバイス コード フローは、パブリック クライアント アプリケーションでのみ使用できます。
- MSAL でパブリック クライアント アプリケーションを初期化する場合は、次のいずれかの形式の機関を使用します。
- テナントベース:
https://login.microsoftonline.com/{tenant}/,は{tenant}、テナント ID を表す GUID またはテナントに関連付けられているドメイン名です。 - 職場または学校のアカウント:
https://login.microsoftonline.com/organizations/
- テナントベース:
Implicit grant (暗黙的な付与)
暗黙的な許可は、クライアント側のシングルページ アプリケーション (SPA) で推奨される、よりセキュアなトークン許可フローとして、PKCE を使用した承認コード フローに置き換えられました。 SPA を構築する場合は、代わりに PKCE を使用した承認コード フローを使用してください。
JavaScript で記述されたシングルページ Web アプリ (Angular、Vue.js、React.js などのフレームワークを含む) がサーバーからダウンロードされ、そのコードがブラウザーで直接実行されます。 クライアント側のコードが Web サーバーではなくブラウザーで実行されるため、従来のサーバー側の Web アプリケーションとは異なるセキュリティ特性を持ちます。 承認コード フローに対して Proof Key for Code Exchange (PKCE) が使用可能になる前は、アクセストークンを取得する際の応答性と効率を向上させるために、暗黙的な許可フローが SPA によって使用されていました。
OAuth 2 の暗黙的な許可のフローでは、バックエンド サーバーとの資格情報交換を実行しなくても、アプリによって Microsoft ID プラットフォームからアクセス トークンを取得できます。 暗黙的な許可フローを使用すると、アプリで、ユーザーのサインイン、セッションの維持、ユーザー エージェント (通常は Web ブラウザー) によってダウンロードおよび実行される JavaScript コード内からの他の Web API のトークンの取得が可能になります。
暗黙的な許可の制約
暗黙的な許可フローには、Electron や React Native などのクロスプラットフォーム JavaScript フレームワークを使用するアプリケーション シナリオは含まれていません。 このようなクロスプラットフォーム フレームワークでは、実行されるネイティブ デスクトップおよびモバイル プラットフォームとの対話に追加の機能が必要です。
暗黙的フロー モードを介して発行されたトークンは、URL (ここでresponse_mode、 または queryfragmentのいずれか) でブラウザーに返されるため、長さの制限があります。 一部のブラウザーでは、ブラウザーのバー内の URL の長さが制限され、長すぎると失敗します。 そのため、これらの暗黙的なフロー トークンには groups または wids 要求が含まれていません。
On-behalf-of (OBO)
OAuth 2 の代理認証フロー フローは、アプリケーションがサービスまたは Web API を呼び出すときに使用されます。これは、委任されたユーザー ID と、要求チェーン経由で伝達する必要があるアクセス許可を使用して別のサービスまたは Web API を呼び出す必要があります。 中間層サービスがダウンストリーム サービスに対して認証された要求を行うには、要求元のユーザーに代わって、Microsoft ID プラットフォームからのアクセス トークンをセキュリティで保護する必要があります。
前の図で:
- アプリケーションは Web API 用のアクセス トークンを取得します。
- クライアント (Web、デスクトップ、モバイル、またはシングルページ アプリケーション) が保護された Web API を呼び出し、HTTP 要求の認証ヘッダーのベアラー トークンとしてアクセス トークンを追加します。 Web API がユーザーを認証します。
- クライアントが Web API を呼び出すと、Web API はユーザーに代わって別のトークンを要求します。
- 保護された Web API は、このトークンを使用して、ユーザーの代わりにダウンストリーム Web API を呼び出します。 Web API は、他のダウンストリーム API のトークンを (ただし、ここでも同じユーザーの代わりとして) 後で要求することもできます。
ユーザー名/パスワード (ROPC)
警告
リソース所有者パスワード資格情報 (ROPC) フローは 推奨されなくなりました。 ROPC には、高度な信頼と資格情報の公開が要求されます。 ROPC は、より安全なフローを使用できない場合にのみ使用してください。 詳細については、深刻化するパスワードの問題の解決策に関する記事を参照してください。
OAuth 2 のリソース所有者のパスワード資格情報 (ROPC) の付与により、アプリケーションでは、ユーザーのパスワードを直接処理することでユーザーをサインインさせることができます。 デスクトップ アプリケーションでは、ユーザー名/パスワードのフローを使ってサイレントにトークンを取得できます。 アプリケーションを使用するときに UI は必要ありません。
DevOps などの一部のアプリケーション シナリオでは、ROPC が役に立つ場合がありますが、ユーザー サインイン用の対話型 UI を提供するアプリケーションでは避ける必要があります。
前の図で、アプリケーションは:
- ID プロバイダーにユーザー名とパスワードを送信することによって、トークンを取得します。
- トークンを使用して Web API を呼び出します。
Windows ドメインに参加しているマシンでトークンをサイレントモードで取得するには、ROPC ではなく Web アカウント マネージャー (WAM) を使用 することをお勧めします。 その他のシナリオでは、デバイス コード フローを使用してください。
ROPC の制約
ROPC フローを使用するアプリケーションには、次の制約が適用されます。
- シングル サインオンはサポートされません。
- 多要素認証 (MFA) はサポートされません。
- このフローを使用する前に、テナント管理者に確認してください。MFA は一般的に使用されている機能です。
- 条件付きアクセスはサポートされません。
- ROPC は職場および学校のアカウントにのみ有効です。
- ROPC では、個人の Microsoft アカウント (MSA) はサポートされません。
- ROPC は、.NET デスクトップ アプリケーションと .NET アプリケーションで サポートされています 。
- ROPC は、ユニバーサル Windows プラットフォーム (UWP) アプリケーションではサポートされません。
- Microsoft Entra 外部 IDの ROPC は、ローカル アカウントでのみサポートされます。
- MSAL.NET およびMicrosoft Entra 外部 IDの ROPC の詳細については、「リソース所有者パスワード資格情報 (ROPC) with B2C」を参照してください。
統合 Windows 認証 (IWA)
注意
統合 Windows 認証は、トークンをサイレントモードで取得するためのより信頼性の高い方法 ( WAM) に置き換えられました。 WAM は、現在の Windows ユーザーにサイレント ログインできます。 このワークフローは複雑なセットアップを必要とせず、個人 (Microsoft) アカウントでも機能します。 内部的には、Windows Broker (WAM) は、IWA や PRT の引き換えなど、現在の Windows ユーザーのトークンを取得するためのいくつかの戦略を試みます。 これにより、IWA の制限の大部分が排除されます。
MSAL では、ドメイン参加済みまたはMicrosoft Entra ID参加済みの Windows コンピューターで実行されるデスクトップ アプリケーションとモバイル アプリケーション用の統合Windows 認証 (IWA) がサポートされています。 IWA を使用すると、これらのアプリケーションは、ユーザーによる UI 操作なしでトークンをサイレントに取得します。
前の図で、アプリケーションは:
- 統合 Windows 認証を使用してトークンを取得します。
- トークンを使用してリソース要求を行います。
IWA の制約
- [互換性]。 統合Windows 認証 (IWA) は、.NET デスクトップ、.NET、ユニバーサル Windows プラットフォーム (UWP) アプリに対して有効になっています。 IWA では、ADFS フェデレーション ユーザーのみがサポートされます。Active Directory で作成され、Microsoft Entra IDによってサポートされるユーザーです。 Active Directory バッキング (マネージド ユーザー) なしでMicrosoft Entra IDで直接作成されたユーザーは、この認証フローを使用できません。
- 多要素認証 (MFA)。 MICROSOFT ENTRA ID テナントで MFA が有効で、Microsoft Entra IDによって MFA チャレンジが発行された場合、IWA 非対話型 (サイレント) 認証が失敗する可能性があります。 IWA が失敗した場合は、前述のように、対話型の認証方式に切り替える必要があります。 Microsoft Entra IDは AI を使用して、2 要素認証が必要なタイミングを判断します。 通常、2 要素認証は、ユーザーが異なる国/リージョンからサインインする場合および VPN を使用せずに企業ネットワークに接続している場合に必要ですが、VPN 経由で接続している場合でも必要になることがあります。 MFA の構成とチャレンジの頻度は開発者が制御できない可能性があるため、アプリケーションは IWA サイレント トークン取得の失敗を適切に処理する必要があります。
- 機関 URI の制限。 パブリック クライアント アプリケーションを構築するときに渡される機関は、次のいずれかである必要があります。
https://login.microsoftonline.com/{tenant}/- この権限は、サインイン対象ユーザーが指定されたMicrosoft Entra ID テナント内のユーザーに制限されているシングルテナント アプリケーションを示します。{tenant}の値には、GUID 形式のテナント ID、またはテナントに関連付けられているドメイン名を指定できます。https://login.microsoftonline.com/organizations/- この権限は、サインイン対象ユーザーが任意のMicrosoft Entra ID テナントのユーザーであるマルチテナント アプリケーションを示します。
- 個人用アカウント。 個人の Microsoft アカウント (MSA) が IWA でサポートされていないため、機関の値に または を含
/common/consumersめてはなりません。 - 同意の要件。 IWA はサイレント フローであるため、アプリケーションのユーザーはアプリケーションの使用に以前に同意しているか、テナント管理者がアプリケーションを使用するためにテナント内のすべてのユーザーに以前に同意している必要があります。 いずれかの要件を満たすには、次のいずれかの操作が完了している必要があります。
- アプリケーション開発者は、自分で Azure Portal で [許可 ] を選択しました。
- テナント管理者が Azure portal のアプリ登録の [API のアクセス許可] タブにある [{テナント ドメイン} の管理者の同意を付与/取り消す] を選択しておきます (「Web API にアクセスするためのアクセス許可を追加する」を参照)。
- ユーザーがアプリケーションに同意する方法を提供しました。Microsoft ID プラットフォームのアクセス許可と同意の概要に関するページを参照してください。
- テナント管理者がアプリケーションに同意する方法を提供しました。Microsoft ID プラットフォームのアクセス許可と同意の概要に関するページを参照してください。
次の手順
MSAL でサポートされている認証フローを確認したので、 これらのフローで使用されるトークンの取得とキャッシュについて学習します。