次の方法で共有

ゼロ トラストのためのユーザー認証

  • [アーティクル]

この記事は、開発者がゼロ トラスト アプリケーション開発においてアプリケーション ユーザー認証のベスト プラクティスを学習するのに役立ちます。 常に最小特権と明示的検証のゼロ トラスト原則に基づいてアプリケーションのセキュリティ強化に努めてください。

ユーザー認証における ID トークン

ユーザーがアプリを認証する必要がある場合、ユーザー名とパスワードを収集するのではなく、アプリケーションは ID トークンを要求することができます。 Microsoft ID プラットフォームを使用してユーザー認証を行うことで、ユーザー認証情報がアプリケーション内に保持される場合に発生するセキュリティ リスクを回避することができます。 ID トークンを要求する場合、悪意のある行為者がアプリケーションを侵害したり漏洩させたりした場合でも、アプリにはユーザー名と対応するパスワードが存在しません。

Microsoft ID プラットフォーム ID トークンは、ID トークンを JSON Web トークン (JWT) として指定する OpenID Connect (OIDC) 標準の一部です。 JWT の長い文字列は、次の 3 つのコンポーネントで構成されます。

  1. ヘッダークレーム。 ID トークン内に存在するヘッダークレームには、typ (型クレーム)、 alg (トークンに署名するためのアルゴリズム)、および kid (トークンの署名を検証するための公開キーのサムプリント) が含まれます。
  2. ペイロードクレーム。 ペイロード (JSON Web トークンの中央部分) には、一連の名前属性ペアが含まれます。 この標準では、トークンを発行したアプリケーション (aud、または対象ユーザーの要求) に移動する iss (発行者名) を含む要求があることが必要です。
  3. 署名。 Microsoft Entra ID は、トークンが改変されておらず信頼できることをアプリケーション側で確認するためのトークン署名を生成します。

以下の例は、ユーザーに関する情報を示し、アプリケーション使用のための認証を確認する ID トークンを示します。

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[Signature]

アクセス管理における ID トークン

アプリケーション (クライアント) ID を受け取るには、まず Microsoft ID プラットフォームにアプリケーションを登録します。 アプリのクライアント ID と一致する対象ユーザーの要求 (aud) を含むトークンを受け取ると、トークン内で識別されたユーザーがアプリを認証します。 IT 管理者は、テナント内のすべてのユーザーにアプリの使用を許可することができます。 ユーザーがメンバーであるグループがアプリを使用することを許可することもできます。

オーディエンスクレームがアプリケーションのクライアント ID と異なるトークンを受け取った場合は、すぐにトークンを拒否すること。 ユーザーは他のアプリにサインインしたため、アプリで認証されていません。 ユーザーがそのアプリを使用するアクセス許可を持っているかを常に確認してください。

これらのクレームの詳細は、ユーザー認証において重要となります。

  • JSON Web トークンは、その有効期限が切れるまで有効です。 exp (有効期限) クレームは 、トークンの有効期間が切れる日時を示します。 現在の時刻が exp クレーム内の時刻より前の場合、トークンは有効です。
  • nbf （この時刻までは未認証）クレーム内に指定される時刻に到達していなければ、そのユーザーが認証されていると見なさないこと。 トークン内の nbf 時刻および exp 時刻はトークンの有効期間を定義します。 有効期限が間近に迫っている場合は、新しい ID トークンを取得してください。
  • sub (サブジェクトクレーム) は、アプリケーション ユーザーを示す一意の識別子です。 同じユーザーが他のアプリケーションについて異なる sub クレームを持っている。 データを格納してユーザーに関連付けし直し、攻撃者が関連付けできないようにするには、サブジェクトクレームを使用します。 サブジェクトクレームによりユーザーの Microsoft Entra ID が公開されることはないため、ユーザーにデータを関連付ける最もプライベートな方法となります。 sub クレームはイミュ―タブル (不変) なオブジェクです。
  • 複数のアプリケーション間で情報を共有する場合は、テナント ID (tid) クレームとそのユーザーに固有のオブジェクト ID (oid) クレームの組み合わせを使用します。 このテナント ID とオブジェクト ID の組み合わせはイミュータブル (不変) です。
  • 後でそのユーザーの ID に何が起こっても、sub、oid、tidの各クレームはイミュータブルとなります。 後からユーザーに関する何らかの変更が生じても、サブジェクトクレーム、もしくはtid クレームと oid クレームの組み合わせに基づくデータを入力してユーザー認証を行うことができます。

OIDC を使用した認証

ユーザー認証の例として、OIDC を使用してユーザーを認証するアプリケーションを見てみましょう。 同じ原則が、Security Assertion Markup Language (SAML) や WS-Federation を使用するアプリにも当てはまります。

アプリケーションがMicrosoft ID プラットフォームに対して ID トークンを要求する時、アプリケーションはユーザーの認証を行います。 ワークロード (ユーザーが存在せず、サービス、バックグラウンド プロセス、デーモンとして実行されるアプリケーション) は、この手順をスキップします。

常に、最初にこのトークンをサイレントに要求する必要があります。 Microsoft Authentication Libraries (MSAL) でトークンをサイレント モードで取得するには、アプリケーション側で AcquireTokenSilent メソッドを開始することができます。 アプリケーションがユーザーとの対話なしに認証を完了できる場合は、要求された ID トークンを受け取ります。

Microsoft ID プラットフォームがユーザーと対話せずに要求を完了できない場合、アプリは MSAL AcquireTokenInteractive メソッドにフォールバックする必要があります。 トークンを対話形式で取得するには、https://login.microsoftonline.com ドメイン下のアドレスに Web サーフェスを開いて要求を実行します。

この Web サーフェスから、ユーザーはMicrosoft ID プラットフォームとのプライベートな会話を行います。 アプリケーションはこの会話を閲覧することはできず、会話をコントロールすることもできません。 Microsoft ID プラットフォームは、ユーザー ID とパスワード、多要素認証 (MFA)、パスワードレス認証、または IT 管理者やユーザーが設定したその他の認証の対話を要求できます。

ユーザーが必要な認証の手順を実行した後、アプリケーションは ID トークンを受け取ります。 アプリがトークンを受け取ると、ユーザーが Microsoft ID プラットフォームで認証されたことを確認できます。 アプリが ID トークンを受け取らない場合、ユーザーは Microsoft ID プラットフォームで認証されていません。 認証されていないユーザーがアプリケーションのセキュリティで保護された領域に進むのを許可しないでください。

Microsoft Entra ID から ID トークンを受け取った後にのみ、アプリケーション側でユーザー向けセッションを作成するようにするのがベストプラクティスです。 アプリケーションが受け取る ID トークン内に、Unix タイムスタンプを持つ有効期限 (exp) クレームがあります。 それは、それ以降 JWT を受け入れて処理できなくなる時刻を指定します。 このトークンの有効期限に基づいて、ユーザー セッションの有効期間を管理してください。 exp クレームは、明示的に検証されたユーザーに対するアプリケーションの認証を適切な特権と適切な時間で維持するのに重要な役割を果たします。

シングル サインオンのサポート

シングル サインオン (SSO) は、ユーザーが 1 セットの認証情報で複数の独立したソフトウェア システムにサインインできるようにする認証方法です。 SSO の使用により、アプリケーション開発者は、ユーザーがすべてのアプリケーションに個別にサインインするよう要求する必要はなくなります。 SSO の基本として、開発者は、ユーザーのデバイス上のすべてのアプリケーションが、そのユーザーを認証する Web サーフェスを共有することを確認してください。 認証ドライブの SSO が成功した後の Web サーフェイス上のアーティファクト (セッションの状態や Cookie など)。

次の図に示すように、共有 Web サーフェスの最も単純なユース ケースは、Web ブラウザー (Microsoft Edge、Google Chrome、Firefox、Safari など) で実行されるアプリケーションです。 ブラウザーのタブで SSO の状態が共有されます。

図は、ブラウザーでアプリが実行されている場合の、共有 Web サーフェスのシナリオを示しています。

Microsoft ID プラットフォームは、ユーザーが同じデバイスで別のブラウザーを開いている場合を除き、特定の一つのブラウザー内で SSO 状態を管理します。 Windows 10 以降では、Microsoft ID プラットフォームはブラウザー SSO Microsoft Edge をネイティブにサポートしています。 ユーザーが Windows にサインインすると、Google Chrome (Windows10 アカウント拡張機能経由) と Mozilla Firefox v91 以降 (ブラウザー設定経由) の特別な機能で各ブラウザーが Windows 自体の SSO 状態を共有できるようになります。

次の図に示すように、ネイティブ アプリケーションのユース ケースはより複雑です。

図は、SSO を使用しない埋め込みブラウザーの複雑なネイティブ アプリケーションのユース ケースを示しています。

認証ブローカーのアプローチ

一般的なパターンは、ネイティブ アプリごとに、SSO に参加できないように独自の埋め込み WebView を持たせるやり方です。 このシナリオに対処するため、Microsoft Entra ID は、次の図に示すように、ネイティブ アプリケーション用の認証ブローカーアプローチを使用します。

図は、ネイティブ アプリケーションでの認証ブローカーの使用を示しています。

認証ブローカーを設置すると、アプリケーションは、Microsoft ID プラットフォームに直接ではなく認証ブローカーに認証要求を送信します。 このようにして、認証ブローカーはデバイス上のすべての認証向けの共有サーフェスになります。

認証ブローカーは、共有サーフェスの提供に加えて、他のメリットも提供します。 ゼロ トラストを採用する場合、企業は企業のマネージド デバイスからのみアプリケーションを実行させようとする場合があります。 そのようなエンタープライズ デバイス管理の例としては、完全なモバイルデバイス管理 (MDM) や、ユーザーが自分のデバイスをモバイル アプリケーション管理 (MAM) に参加させるシナリオなどがあります。

設計上、基になるオペレーティング システム (OS) によってブラウザーが分離されます。 開発者は、デバイスの詳細に完全にアクセスするには、OS とのより緊密な接続を必要とします。 Windows では、Windows Web アカウント マネージャー (WAM) が認証ブローカーとなります。 他のデバイスでは、Microsoft Authenticator アプリケーション (iOS または Android を実行しているデバイスの場合)、または 事業者ポータル アプリケーション (Android を実行しているデバイスの場合) のいずれかが認証ブローカーとなります。 アプリケーションは、MSAL を使用して認証ブローカーにアクセスします。 Windows では、アプリケーションが MSAL なしで WAM にアクセスすることは可能です。 ただし、MSAL は、アプリケーションが認証ブローカー (特にユニバーサル Windows プラットフォームアプリではないアプリケーションの場合) にアクセスするための最も簡単な方法です。

認証ブローカーが Microsoft Entra ID と連動してプライマリ更新トークン (PRT) を利用することにより、ユーザーが複数回認証する必要が減ります。 PRT は、ユーザーがマネージド デバイス上にあるかどうかを判断することができます。 Microsoft Entra ID は、現在普及しているベアラー トークンよりも安全なオプションである所有権証明トークンを導入するのに認証ブローカーを必要とします。

次のステップ