プライマリ更新トークンとは

  • [アーティクル]

プライマリ更新トークン (PRT) は、Windows 10 以降、Windows Server 2016 以降のバージョン、iOS、および Android デバイスでの Azure AD 認証のキー アーティファクトです。 これは、これらのデバイスで使用されるアプリケーション間でシングル サインオン (SSO) を有効にするために、マイクロソフトのファースト パーティ トークン ブローカーに向けて特別に発行される JSON Web トークン (JWT) です。 この記事では、Windows 10 以降のデバイス上で PRT が どのように発行、使用、保護されるかについて詳しく説明します。 最良の SSO エクスペリエンスを得るために、最新バージョンの Windows 10、Windows 11、Windows Server 2019 以降を使用することをお勧めします。

この記事では、Azure AD で利用可能な各種のデバイス状態と、Windows 10 以降でのシングル サインオンのしくみについて、読者が既に理解していることを想定しています。 Azure AD でのデバイスの詳細については、「Azure Active Directory のデバイス管理とは」の記事を参照してください

主要な用語とコンポーネント

PRT の要求と使用においては、次の Windows コンポーネントが重要な役割を果たします。

  • クラウド認証プロバイダー (CloudAP): CloudAP は、Windows サインイン用の最新の認証プロバイダーであり、Windows 10 以降のデバイスにログインしているユーザーを検証します。 ID プロバイダーは、CloudAP が提供するプラグイン フレームワークを利用して、その ID プロバイダーの資格情報を使った Windows への認証を有効にすることができます。
  • Web アカウント マネージャー (WAM): WAM は、Windows 10 以降のデバイスでの既定のトークン ブローカーです。 また ID プロバイダーは、WAM が提供するプラグイン フレームワークを利用して、その ID プロバイダーを利用しているアプリケーションへの SSO を有効にすることができます。
  • Azure AD CloudAP プラグイン: CloudAP フレームワーク上に構築される Azure AD 固有のプラグインであり、Windows サインイン中に Azure AD を使用してユーザーの資格情報を検証します。
  • Azure AD WAM プラグイン: WAM フレームワーク上に構築される Azure AD 固有のプラグインであり、Azure AD を認証に利用するアプリケーションへの SSO を有効にします。
  • Dsreg: Windows 10 以降の Azure AD 固有のコンポーネントであり、すべてのデバイス状態のデバイス登録プロセスを処理します。
  • トラステッド プラットフォーム モジュール (TPM): TPM はデバイスに組み込まれるハードウェア コンポーネントであり、ユーザーとデバイスをシークレットにするためのハードウェア ベースのセキュリティ機能を提供します。 詳細については、「トラステッド プラットフォーム モジュール技術概要」の記事を参照してください。

PRT には何が含まれますか?

PRT には、ほとんどの Azure AD 更新トークンで検出された要求が含まれています。 さらに、PRT に含まれるデバイス固有の要求がいくつか存在します。 制限事項は次のとおりです。

  • デバイス ID: PRT は特定のデバイス上のユーザーに発行されます。 デバイス ID 要求 deviceID は、PRT がユーザーに発行されたデバイスを判別します。 この要求は、PRT 経由で取得したトークンに対して後から発行されます。 デバイス ID 要求は、デバイスの状態またはコンプライアンスに基づいて条件付きアクセスの認可を決定するために使用されます。
  • セッション キー: セッション キーは、Azure AD 認証サービスによって生成され、PRT の一部として発行される暗号化対称キーです。 セッション キーは、他のアプリケーション用のトークンを取得するために PRT が使用されるときに、所有の証明として機能します。 セッション キーは、30 日を超える場合は、Windows 10 以降の Azure AD 参加済みデバイスまたは Hybrid Azure AD 参加済みデバイスで回されます。

PRT の内容を見ることはできますか?

PRT は Azure AD から送信される不透明な BLOB であり、その内容はどのクライアント コンポーネントにも知られることはありません。 PRT の内容を見ることはできません。

PRT はどのようにして発行されますか?

デバイス登録は、Azure AD でのデバイス ベース認証の前提条件です。 PRT は登録済みデバイス上のユーザーにのみ発行されます。 デバイス登録の詳細については、「Windows Hello for Business とデバイスの登録」の記事を参照してください。 デバイス登録中、dsreg コンポーネントによって暗号化キーの組が 2 セット生成されます。

  • デバイス キー (dkpub/dkpriv)
  • トランスポート キー (tkpub/tkpriv)

有効であり機能している TPM がデバイスにある場合、秘密キーはデバイスの TPM にバインドされます。一方、公開キーはデバイス登録プロセスの間に Azure AD に送信されます。 これらのキーは、PRT 要求中にデバイスの状態を検証するために使用されます。

PRT は Windows 10 以降のデバイス上でのユーザー認証中に発行され、2 つのシナリオがあります。

  • Azure AD 参加済みまたはハイブリッド Azure AD 参加済み: PRT は、ユーザーが自分の組織の資格情報を使用してサインインするとき、Windows ログオン中に発行されます。 PRT は、パスワードや Windows Hello for Business など、Windows 10 以降でサポートされているすべての資格情報と共に発行されます。 このシナリオでは、Azure AD CloudAP プラグインが PRT のプライマリ機関です。
  • Azure AD 登録済みデバイス: PRT は、ユーザーが自分の Windows 10 以降のデバイスにセカンダリの職場アカウントを追加するときに発行されます。 ユーザーは 2 つの異なる方法で Windows 10 以降にアカウントを追加できます。
    • アプリ (Outlook など) にサインインした後で、 [組織がデバイスを管理できるようにする] プロンプトからアカウントを追加する
    • [設定]>[アカウント]>[Access Work or School](職場または学校にアクセスする)>[接続] からアカウントを追加する

Azure AD 登録済みデバイスのシナリオでは、この Azure AD アカウントで Windows ログオンは発生しないため、Azure AD WAM プラグインが PRT のプライマリ機関です。

注意

サード パーティの ID プロバイダーは、Windows 10 以降のデバイスで PRT 発行を有効にするために、WS-Trust プロトコルをサポートする必要があります。 WS-Trust がない場合、Hybrid Azure AD 参加済みまたは Azure AD 参加済みデバイスでユーザーに PRT を発行することはできません。 ADFS では、usernamemixed エンドポイントのみが必要です。 adfs/services/trust/2005/windowstransport と adfs/services/trust/13/windowstransport はどちらも、イントラネットに接続するエンドポイントとしてのみ有効にする必要があります。Web アプリケーション プロキシを介してエクストラネットに接続するエンドポイントとしては公開しないでください。

注意

PRT の発行時には、Azure AD 条件付きアクセス ポリシーが評価されません。

注意

Azure AD PRT の発行と更新では、サード パーティの資格情報プロバイダーがサポートされません。

PRT の有効期間はどれくらいですか?

発行された PRT は 14 日間有効であり、ユーザーがデバイスをアクティブに使用している限り継続的に更新されます。

PRT はどのように使用されますか?

Windows で、PRT は 2 つの主要コンポーネントによって使用されます。

  • Azure AD CloudAP プラグイン: Windows サインイン中に、Azure AD CloudAP プラグインが、ユーザーから提供された資格情報を使用して Azure AD から PRT を要求します。 また、PRT をキャッシュして、ユーザーがインターネット接続にアクセスできないときのキャッシュ サインインを有効にします。
  • Azure AD WAM プラグイン: ユーザーがアプリケーションにアクセスしようとすると、Azure AD WAM プラグインが PRT を使用して Windows 10 以降で SSO を有効にします。 Azure AD WAM プラグインは PRT を使用して、トークン要求を WAM に依存するアプリケーションについて更新トークンとアクセス トークンを要求します。 また、ブラウザーの要求に PRT を挿入して、ブラウザー上で SSO を有効にします。 Windows 10 以降のブラウザー SSO は Microsoft Edge (ネイティブ)、Chrome (Windows 10 Accounts または Office Online 拡張機能経由で) または Mozilla Firefox v 91 以上 (Firefox Windows SSO 設定) でサポートされています。

    Note

    ユーザーが同じ Azure AD テナントの 2 つのアカウントでブラウザー アプリケーションにサインインしている場合、プライマリ アカウントの PRT が提供するデバイス認証は、2 つ目のアカウントにも自動的に適用されます。 その結果、2 番目のアカウントも、テナントのデバイスベースの条件付きアクセス ポリシーに適合します。

PRT はどのように更新されますか?

PRT は 2 つの異なる方法で更新されます。

  • Azure AD CloudAP プラグイン (4 時間ごと) : Windows サインイン中、CloudAP プラグインが 4 時間ごとに PRT を更新します。 その期間中にユーザーがインターネットに接続できない場合、CloudAP プラグインはデバイスがインターネットに接続した後に PRT を更新します。
  • Azure AD WAM プラグイン (アプリ トークンの要求中): WAM プラグインは、アプリケーションに対するサイレント トークン要求を有効にすることによって、Windows 10 以降のデバイス上で SSO を有効にします。 WAM プラグインは、これらのトークン要求中に 2 つの異なる方法で PRT を更新できます。
    • アプリは WAM にアクセス トークンをサイレントに要求しますが、そのアプリに対して利用可能な更新トークンがありません。 この場合、WAM は PRT を使用してアプリのトークンを要求し、応答で新しい PRT を再取得します。
    • アプリが WAM にアクセス トークンを要求しますが、PRT が無効であるか、または Azure AD が (Azure AD Multifactor Authentication などの) 追加の認可を要求しています。 このシナリオでは、WAM は対話型ログオンを開始し、再認証または追加認証の提供をユーザーに要求し、認証が成功したら新しい PRT が発行されます。

ADFS 環境では、PRT を更新するために、ドメイン コントローラーへの直接の通信経路を確保する必要はありません。 PRT の更新には、WS-Trust プロトコルを使用してプロキシで有効になっている /adfs/services/trust/2005/usernamemixed と /adfs/services/trust/13/usernamemixed エンドポイントのみが必要です。

Windows トランスポート エンドポイントは、パスワードが変更された場合にのみパスワード認証に必要であり、PRT の更新には必要ありません。

注意

Azure AD 条件付きアクセス ポリシーは、PRT の更新時、評価されません。

重要な考慮事項

  • PRT はネイティブ アプリの認証中にのみ発行および更新されます。 PRT はブラウザー セッション中は更新も発行もされません。
  • Azure AD 参加済みデバイスおよびハイブリッド Azure AD 参加済みデバイスでは、CloudAP プラグインが PRT のプライマリ機関です。 WAM ベースのトークン要求中に PRT が更新された場合、PRT は CloudAP プラグインに返送され、受け入れ前に Azure AD での PRT の有効性が検証されます。

PRT はどのように保護されますか?

PRT は、ユーザーがサインインしたデバイスにバインドすることによって保護されます。 Azure AD と Windows 10 以降では、次の方法によって PRT 保護を有効にします。

  • 初回サインイン中: 初回サインイン中、暗号化形式でデバイス登録中に生成されたデバイス キーを使用して要求に署名することによって PRT が発行されます。 TPM が有効に動作しているデバイスでは、デバイス キーは TPM によってセキュリティで保護され、悪意のあるアクセスを防ぎます。 対応するデバイス キーの署名を検証できない場合、PRT は発行されません。
  • トークンの要求および更新中: PRT が発行されると、Azure AD は暗号化されたセッション キーもデバイスに発行します。 それは生成されたパブリック トランスポート キー (tkpub) を使用して暗号化され、デバイス登録の一環として Azure AD に送信されます。 このセッション キーは、TPM によってセキュリティで保護されたプライベート トランスポート キー (tkpriv) によってのみ復号化できます。 セッション キーは、Azure AD に送信されるすべての要求に対しての所有証明 (POP) キーです。 セッション キーも TPM によって保護され、他の OS コンポーネントからアクセスできません。 トークン要求または PRT 更新要求は、TPM を使用してこのセッション キーによって安全に署名されるため、改ざんできません。 Azure AD では、対応するセッション キーによって署名されていないデバイスからの要求が無効になります。

TPM を使用してこれらのキーをセキュリティで保護することにより、キーを盗んだり PRT を再生したりしようとする悪意のあるアクターに対して PRT のセキュリティを強化します。 したがって、TPM を使用すれば、Azure AD 参加済み、ハイブリッド Azure AD 参加済み、および Azure AD 登録済みの各デバイスで、資格情報の盗難に対するセキュリティが大幅に向上します。 パフォーマンスと信頼性の面から、Windows 10 以降のすべての Azure AD デバイス登録シナリオで、TPM 2.0 が推奨バージョンです。 Windows 10 1903 更新プログラム以降、Azure AD では、信頼性の問題により、上記のいずれのキーにも TPM 1.2 は使用されません。

アプリ トークンとブラウザーの Cookie はどのように保護されますか?

アプリ トークン: アプリが WAM 経由でトークンを要求すると、Azure AD は更新トークンとアクセス トークンを発行します。 ただし、WAM はアクセス トークンをアプリに返すだけであり、そのキャッシュ内の更新トークンは、ユーザーのデータ保護アプリケーション プログラミング インターフェイス (DPAPI) キーで暗号化することによってセキュリティで保護します。 WAM は、セッション キーを使用して要求に署名し、さらにアクセス トークンを発行することによって、更新トークンを安全に使用します。 DPAPI キーは、Azure AD 自体で Azure AD ベースの対称キーによってセキュリティで保護されます。 デバイスが DPAPI キーを使用してユーザー プロファイルを復号化する必要がある場合、セッション キーによって暗号化された DPAPI キーを Azure AD が提供し、CloudAP プラグインがこれの復号化を TPM に要求します。 この機能によって、更新トークンのセキュリティ保護の整合性が確保され、アプリケーションで独自の保護メカニズムが実装されるのを回避します。

ブラウザーの Cookie: Windows 10 以降の Azure AD では、ブラウザー SSO は Internet Explorer と Microsoft Edge ではネイティブで、Google Chrome では Windows 10 アカウント拡張機能を介して、Mozilla Firefox v 91 以上ではブラウザー設定を介してサポートされます。 Cookie だけでなく Cookie が送信されるエンドポイントも保護するようにセキュリティが構築されています。 ブラウザーの Cookie の保護方法は PRT と同じであり、セッション キーを利用して Cookie に署名することによって保護されます。

ユーザーがブラウザーとの対話を開始すると、ブラウザー (または拡張機能) が COM ネイティブ クライアント ホストを呼び出します。 ネイティブ クライアント ホストは、許可されているドメインのいずれかの配下にあるページであることを確認します。 ブラウザーは nonce を含むその他のパラメーターをネイティブ クライアント ホストに送信できますが、ネイティブ クライアント ホストはホスト名の検証を保証します。 ネイティブ クライアント ホストは PRT Cookie を CloudAP プラグインに要求し、プラグインは TPM で保護されたセッション キーを使用して Cookie を作成し、署名します。 PRT Cookie はセッション キーによって署名されるため、改ざんは非常に困難です。 この PRT Cookie は、Azure AD で発信元デバイスを検証するための要求ヘッダーに含まれます。 Chrome ブラウザーを使用している場合、ネイティブ クライアント ホストのマニフェストで明示的に定義されている拡張機能のみがそれを呼び出すことができ、任意の拡張機能がこれらの要求を行うことを防ぎます。 Azure AD は PRT Cookie を検証したら、セッション Cookie をブラウザーに発行します。 このセッション Cookie には、PRT を使用して発行されたのと同じセッション キーも含まれています。 後続の要求の間、セッション キーが検証されます。このとき、Cookie は事実上デバイスにバインドされ、他の場所からの再生を防ぎます。

PRT が MFA 要求を受けるのはいつですか?

特定のシナリオで、PRT が多要素認証 (MFA) 要求を受けることがあります。 アプリケーションのトークンを要求するために MFA ベースの PRT が使用されると、MFA 要求がアプリ トークンに転送されます。 この機能は、それが必要なすべてのアプリでの MFA チャレンジを防ぐことによって、シームレスなエクスペリエンスをユーザーに提供します。 PRT は次の方法で MFA 要求を取得できます。

  • Windows Hello for Business を使用してサインイン: Windows Hello for Business は、パスワードを置き換え、暗号化キーを使用して強力な 2 要素認証を提供します。 Windows Hello for Business はデバイス上のユーザーに固有であり、それ自体がプロビジョニングのために MFA を必要とします。 ユーザーが Windows Hello for Business を使用してログインすると、ユーザーの PRT が MFA 要求を取得します。 スマート カード認証が ADFS から MFA 要求を生成する場合、このシナリオはスマート カードでログインしているユーザーにも当てはまります。
    • Windows Hello for Business は多要素認証と見なされ、PRT 自体が更新されると MFA 要求が更新されるため、ユーザーが Windows Hello for Business を使用してサインインすると MFA の期間は継続的に延長されます。
  • WAM 対話型サインイン中の MFA: WAM を通じたトークン要求中に、ユーザーがアプリにアクセスするために MFA を実行する必要がある場合、この対話中に更新される PRT には MFA 要求が刻印されます。
    • この場合、MFA 要求は継続的に更新されないため、MFA 期間はディレクトリで設定された有効期間に基づきます。
    • 以前の既存の PRT と RT がアプリへのアクセスに使用されている場合、PRT と RT は最初の認証の証明と見なされます。 2 番目の証明と刻印された MFA 要求で、新しい AT が必要になります。 このプロセスにより、新しい PRT と RT も発行されます。

Windows 10 以降では、PRT のパーティション分割されたリストを資格情報ごとに保持します。 したがって、Windows Hello for Business、パスワード、またはスマート カードのそれぞれに PRT があります。 このパーティション分割により、使用する資格情報に基づいて MFA 要求が分離され、トークン要求中に混同されないことが保証されます。

注意

パスワードを使用して、Windows 10 またはそれ以降の Azure AD 参加済みデバイスまたは Hybrid Azure AD 参加済みデバイスにサインインする場合、PRT に関連付けられているセッション キーが回された後に、WAM 対話型サインイン中の MFA が必要になる場合があります。

PRT はどのようにして無効になりますか?

次のシナリオでは、PRT が無効になります。

  • 無効なユーザー: ユーザーが Azure AD で削除または無効化された場合、そのユーザーの PRT は無効になり、アプリケーションのトークンを取得するために使用できません。 削除または無効化されたユーザーがデバイスに既にサインインしていた場合、CloudAP が無効状態を認識するまで、そのユーザーはキャッシュ サインインによってログイン可能です。 CloudAP は、ユーザーが無効であると判断すると、それ以降のログオンをブロックします。 無効なユーザーは、資格情報がキャッシュされていない新しいデバイスへのサインインを自動的にブロックされます。
  • 無効なデバイス: Azure AD でデバイスが削除または無効化された場合、そのデバイスで取得された PRT は無効になり、他のアプリケーションのトークンを取得するために使用できません。 無効なデバイスにユーザーが既にサインインしている場合、その状態を継続できます。 ただし、デバイス上のすべてのトークンは無効になり、ユーザーはそのデバイスのリソースに対する SSO を失います。
  • パスワードの変更: ユーザーがパスワードを使用して PRT を取得した場合、ユーザーがパスワードを変更すると、Azure AD によって PRT が無効になります。 パスワードを変更すると、ユーザーは新しい PRT を取得することになります。 この無効化には 2 つの形態があります。
    • ユーザーが新しいパスワードを使用して Windows にサインインした場合、CloudAP は古い PRT を破棄し、ユーザーの新しいパスワードを使用して新しい PRT を発行するよう Azure AD に要求します。 ユーザーがインターネットに接続していない場合、新しいパスワードを検証できないため、Windows は古いパスワードの入力をユーザーに要求することがあります。
    • ユーザーが古いパスワードを使用してログインしていたか、または Windows へのサインイン後にパスワードを変更した場合、WAM ベースのトークン要求には古い PRT が使用されます。 このシナリオでは、ユーザーは WAM トークンの要求中に再認証を求められ、新しい PRT が発行されます。
  • TPM の問題: デバイスの TPM の不具合または故障により、TPM によってセキュリティで保護されているキーにアクセスできなくなることがあります。 この場合、暗号キーの所有を証明できないため、デバイスは PRT を取得できず、既存の PRT を使用してトークンを要求することもできません。 その結果、既存の PRT はすべて Azure AD によって無効化されます。 Windows 10 が障害を検出すると、新しい暗号化キーを使用してデバイスを再登録するための復旧フローが開始します。 ハイブリッド Azure AD 参加では、初回登録と同様、ユーザーの入力なしでサイレントに復旧が行われます。 Azure AD 参加済みまたは Azure AD 登録済みデバイスの場合、そのデバイスに対する管理者特権を持つユーザーが復旧を実行する必要があります。 このシナリオでは、復旧フローは、デバイスを正常に復旧できるようユーザーをガイドする Windows プロンプトによって開始されます。

詳細なフロー

以下の図は、アプリケーションのアクセス トークンを要求するために PRT を発行、更新、および使用する際の基本的な詳細を示しています。 さらに、以下の手順では、これらの対話中に前述のセキュリティ メカニズムがどのように適用されるかも説明します。

初回サインイン中の PRT 発行

初回サインイン中の PRT 発行の詳細フロー

注意

Azure AD 参加済みデバイスでは、ユーザーが Windows にログオンする前に、Azure AD PRT の発行 (手順 A から F) が同期的に行われます。 ハイブリッド Azure AD 参加済みデバイスでは、オンプレミスの Active Directory がプライマリ機関です。 そのため、PRT の発行は非同期に行われますが、ユーザーは TGT を取得してログインできるようになったら、Hybrid Azure AD 参加済み Windows にログインできます。 ログオンでは Azure AD 資格情報を使用しないため、このシナリオは Azure AD 登録済みデバイスには当てはまりません。

手順 説明
A ユーザーがサインイン UI で自分のパスワードを入力します。 LogonUI は認証バッファー内の認証情報を LSA に渡し、LSA はそれを内部で CloudAP に渡します。 CloudAP はこの要求を CloudAP プラグインに転送します。
B CloudAP プラグインは、ユーザーの ID プロバイダーを識別するためにレルム検出要求を開始します。 ユーザーのテナントにフェデレーション プロバイダーのセットアップがある場合、Azure AD はフェデレーション プロバイダーの Metadata Exchange (MEX) エンドポイントを返します。 ない場合、Azure AD はユーザーが管理対象であることを返し、ユーザーを Azure AD で認証できることを示します。
C ユーザーが管理対象の場合、CloudAP は Azure AD から nonce を取得します。 ユーザーがフェデレーションされている場合、CloudAP プラグインはユーザーの認証情報を使用して SAML トークンをフェデレーション プロバイダーから要求します。 SAML トークンが Azure AD に送信される前に nonce が要求されます。
D CloudAP プラグインは、ユーザーの資格情報、nonce、およびブローカー スコープを使用して認証要求を構築し、デバイス キー (dkpriv) を使用して要求に署名し、それを Azure AD に送信します。 フェデレーション環境では、CloudAP プラグインはユーザーの資格情報の代わりに、フェデレーション プロバイダーから返された SAML トークンを使用します。
E Azure AD は、ユーザーの資格情報、nonce、およびデバイスの署名を検証し、デバイスがテナント内で有効であることを確認し、暗号化された PRT を発行します。 Azure AD は、PRT と共に、セッション キーと呼ばれる対称キーも発行します。これは、トランスポート キー (tkpub) を使用して Azure AD によって暗号化されます。 さらに、セッション キーも PRT に埋め込まれます。 このセッション キーは、PRT を使用した後続の要求に対する所有証明 (PoP) キーとして機能します。
F CloudAP プラグインは、暗号化された PRT とセッション キーを CloudAP に渡します。 トランスポート キー (tkpriv) を使用してセッション キーを復号化し、TPM 自身のキーを使用してそれを再暗号化するよう、CloudAP が TPM に要求します。 CloudAP は、暗号化されたセッション キーをそのキャッシュに PRT と共に保存します。

後続のログオンでの PRT 更新

後続のログオンでの PRT 更新

手順 説明
A ユーザーがサインイン UI で自分のパスワードを入力します。 LogonUI は認証バッファー内の認証情報を LSA に渡し、LSA はそれを内部で CloudAP に渡します。 CloudAP はこの要求を CloudAP プラグインに転送します。
B ユーザーが以前にこのユーザーにログオンしたことがある場合、Windows はキャッシュ サインインを開始し、資格情報を検証してユーザーをログインさせます。 4 時間ごとに、CloudAP プラグインは PRT の更新を非同期的に開始します。
C CloudAP プラグインは、ユーザーの ID プロバイダーを識別するためにレルム検出要求を開始します。 ユーザーのテナントにフェデレーション プロバイダーのセットアップがある場合、Azure AD はフェデレーション プロバイダーの Metadata Exchange (MEX) エンドポイントを返します。 ない場合、Azure AD はユーザーが管理対象であることを返し、ユーザーを Azure AD で認証できることを示します。
D ユーザーがフェデレーションされている場合、CloudAP プラグインはユーザーの認証情報を使用して SAML トークンをフェデレーション プロバイダーから要求します。 SAML トークンが Azure AD に送信される前に nonce が要求されます。 ユーザーが管理対象の場合、CloudAP は直接、Azure AD から nonce を取得します。
E CloudAP プラグインは、ユーザーの資格情報、nonce、および既存の PRT を使用して認証要求を構築し、セッション キーを使用して要求に署名し、それを Azure AD に送信します。 フェデレーション環境では、CloudAP プラグインはユーザーの資格情報の代わりに、フェデレーション プロバイダーから返された SAML トークンを使用します。
F Azure AD は、PRT に埋め込まれたセッション キーと比較することによってセッション キーの署名を検証し、nonce を検証し、デバイスがテナント内で有効であることを確認し、新しい PRT を発行します。 前述のように、PRT はやはり、トランスポート キー (tkpub) によって暗号化されたセッション キーを伴います。
G CloudAP プラグインは、暗号化された PRT とセッション キーを CloudAP に渡します。 トランスポート キー (tkpriv) を使用してセッション キーを復号化し、TPM 自身のキーを使用してそれを再暗号化するよう、CloudAP が TPM に要求します。 CloudAP は、暗号化されたセッション キーをそのキャッシュに PRT と共に保存します。

注意

usernamemixed エンドポイントが外部で有効になっている場合、VPN 接続を必要とせずに、PRT を外部で更新できます。

アプリ トークン要求中の PRT 使用状況

アプリ トークン要求中の PRT 使用状況

手順 説明
A (Outlook、OneNote などの) アプリケーションが WAM に対するトークン要求を開始します。 WAM はさらに、トークン要求の処理を Azure AD WAM プラグインに依頼します。
B アプリケーションの更新トークンが既に利用可能な場合、Azure AD WAM プラグインはそれを使用してアクセス トークンを要求します。 デバイス バインディングの証明を提供するために、WAM プラグインはセッション キーを使用して要求に署名します。 Azure AD はセッション キーを検証し、アプリのアクセス トークンと新しい更新トークンを、セッション キーによって暗号化して発行します。 WAM プラグインはトークンの復号化を CloudAP プラグインに要求し、次に CloudAP プラグインがセッション キーを使用した復号化を TPM に要求します。その結果、WAM プラグインは両方のトークンを取得します。 次に、WAM プラグインはアクセス トークンのみをアプリケーションに提供する一方で、更新トークンを DPAPI で再暗号化してそれ自身のキャッシュに保存します
C アプリケーションの更新トークンがまだ利用できない場合、Azure AD WAM プラグインは PRT を使用してアクセス トークンを要求します。 所有の証明を提供するために、WAM プラグインはセッション キーを使用して、PRT が含まれている要求に署名します。 Azure AD は、PRT に埋め込まれたセッション キーと比較することによってセッション キーの署名を検証し、デバイスが有効であることを確認し、アプリケーションのアクセス トークンと更新トークンを発行します。 さらに、Azure AD は (更新サイクルに基づいて) 新しい PRT を発行でき、それらはすべてセッション キーによって暗号化されます。
D WAM プラグインはトークンの復号化を CloudAP プラグインに要求し、次に CloudAP プラグインがセッション キーを使用した復号化を TPM に要求します。その結果、WAM プラグインは両方のトークンを取得します。 次に、WAM プラグインはアクセス トークンのみをアプリケーションに提供する一方で、更新トークンを DPAPI で再暗号化してそれ自身のキャッシュに保存します。 WAM プラグインはこのアプリケーションに対して、今後は更新トークンを使用します。 WAM プラグインはさらに、新しい PRT を CloudAP プラグインに返します。CloudAP プラグインは、自身のキャッシュ内でそれを更新する前に、Azure AD で PRT を検証します。 これ以降、CloudAP プラグインは新しい PRT を使用します。
E WAM は新しく発行されたアクセス トークンを WAM に提供し、次に WAM がそれを呼び出し元のアプリケーションに返します

PRT を使用したブラウザー SSO

PRT を使用したブラウザー SSO

手順 説明
A ユーザーは自分の資格情報を使用して Windows にログインし、PRT を取得します。 ユーザーがブラウザーを開くと、ブラウザー (または拡張機能) がレジストリから URL を読み込みます。
B ユーザーが Azure AD ログイン URL を開くと、ブラウザーまたは拡張機能がその URL を、レジストリから取得したものと比較検証します。 一致する場合、ブラウザーはトークンを取得するためにネイティブ クライアント ホストを呼び出します。
C ネイティブ クライアント ホストは、URL が Microsoft ID プロバイダー (Microsoft アカウントまたは Azure AD) に属していることを検証し、URL から送信された nonce を抽出し、CloudAP プラグインの呼び出しを実行して PRT Cookie を取得します。
D CloudAP プラグインは PRT Cookie を作成し、TPM にバインドされたセッション キーを使用してそれに署名し、ネイティブ クライアント ホストに返送します。
E ネイティブ クライアント ホストはこの PRT Cookie をブラウザーに返します。ブラウザーはそれを x-ms-RefreshTokenCredential という要求ヘッダーの一部として含め、Azure AD からトークンを要求します。
F Azure AD は PRT Cookie のセッション キー署名を検証し、nonce を検証し、デバイスがテナント内で有効であることを確認し、Web ページの ID トークンと、ブラウザーの暗号化されたセッション Cookie を発行します。

注意

上の手順で説明されているブラウザー SSO フローは、Microsoft Edge の InPrivate、Google Chrome のシークレット モード (Microsoft Accounts または Office Online 拡張機能の使用時)、Mozilla Firefox v 91 以上のプライベート モードなどのプライベート モードのセッションには該当しません

次の手順

PRT 関連の問題のトラブルシューティングについては、ハイブリッド Azure Active Directory 参加済み Windows 10 以降および Windows Server 2016 デバイスのトラブルシューティングに関する記事を参照してください。