ユーザー名とパスワード認証

以下の内容は、MSAL Pythonだけでなく、すべての MSAL ライブラリに適用されます。

ユーザー名とパスワードのフローは推奨されません

Microsoftでは、ユーザー名とパスワードのフローを使用しないことをお勧めします。 ほとんどのシナリオでは、より安全な代替手段が利用でき、推奨されます。 このフローでは、アプリケーションに非常に高い信頼が必要であり、他のフローに存在しないリスクが伴います。 このフローは、より安全なフローが実行可能ではない場合にのみ使用してください。 この許可の使用を避けたい理由の詳細については、パスワードを過去のものにするためにMicrosoftが取り組んでいる理由を参照してください。

制約

• 設計とポリシーにより、ユーザー名/パスワード認証は職場および学校アカウントでのみ機能しますが、Microsoft アカウント (MSA) では機能しません。 この 2 種類のアカウントの定義については、こちらをご覧ください。
• ユーザー名/パスワード認証は、条件付きアクセスと多要素認証と互換性がありません。これは対話型フローではないため、Microsoft ID プラットフォームはエンド ユーザーが対話するための Web ベースのダイアログを表示する機会がありません。 その結果、テナント管理者が多要素認証を必要とするMicrosoft Entra テナントでアプリが実行されている場合 (多くの組織で行われます)、このフローは機能しません。
• ユーザー名パスワード認証は非対話型フローであるため、
  • アプリケーションのユーザーは、アプリケーションの使用に以前に同意している必要があります
  • または、テナント管理者が、アプリケーションを使用するためにテナント内のすべてのユーザーに以前に同意している必要があります。
  • これは、次のことを意味します。
    • 開発者として、Azure ポータルの [許可] ボタンを自分で押した場合
    • または、テナント管理者が、アプリケーションの登録の API アクセス許可タブにある {tenant domain} に対する管理者の同意の付与/取り消しボタンを押しました (Web API にアクセスするためのアクセス許可の追加を参照)
    • または、ユーザーがアプリケーションに同意する方法を提供している場合 ( 「個々のユーザーの同意を要求する」を参照)
    • または、テナント管理者がアプリケーションに同意する方法を提供している場合 (管理者の 同意を参照)

推奨事項

ユーザー名パスワード認証を使用する場合でも、エンド ユーザーのパスワードを保持しないでください。 最初のユーザー名パスワード認証が成功すると、MSAL のトークン キャッシュが開始され、更新トークン (RT) が自動的にキャッシュされます。 今後、アプリは MSAL の acquire_token_silent() を呼び出して、ユーザー名とパスワードなしで新しいアクセス トークンを取得できます。

セットアップ

Microsoft ID プラットフォームでは、パブリック クライアント アプリケーションと Confidential クライアント アプリケーションでのユーザー名パスワード フローがサポートされます。 アプリをパブリック クライアント アプリケーションとして構成する必要がある場合は、次のスクリーンショットのスイッチをオンにして許可します。