AD FS OpenID Connect/OAuth の概念

Active Directory フェデレーション サービス (AD FS) 2016 以降に適用されます

先進認証アクター

次の図は、アクター間の最も基本的な関係を示しています。

アプリケーションのタイプ

アプリケーション グループ

AD FS で構成されているすべてのネイティブまたは Web アプリの OAuth クライアントまたは Web API リソースにアプリケーション グループを関連付ける必要があります。 アプリケーション グループ内のクライアントを構成して、同じグループ内のリソースにアクセスします。 アプリケーション グループには、複数のクライアントとリソースを含めることができます。

セキュリティ トークン

先進認証では、次の種類のトークンが使用されます。

• id_token: 承認サーバー (AD FS) によって発行され、クライアントによって使用される JWT トークン。 ID トークンの要求には、クライアントが活用できるユーザー情報が含まれています。
• access_token: 承認サーバー (AD FS) によって発行され、リソースによって使用されることを意図した JWT トークン。 このトークンの 'aud' または audience 要求は、リソースまたは Web API の識別子と一致する必要があります。
• refresh_token: id_tokenとaccess_tokenを更新する必要があるときにクライアントが使用するために AD FS によって発行されます。 トークンはクライアントに対して不透明であり、AD FS によってのみ使用されます。

リフレッシュトークンの有効期間

• 単純なログオン、KMSI なし、デバイスが登録されていない: AD FS はSsoLifetimeとDeviceUsageWindowInDaysを適用します。 最初の更新トークンには lifetime=DeviceUsageWindowInDays または SsoLifetimeがあり、どのフィールドが低いかに基づいて行われますが、それ以上の更新トークンは発行 されません 。
• KMSI ログオン、AD FS 構成で EnableKmsi=true、kmsi=true がパラメーターとして渡される: AD FS は KmsiLifetimeMins と DeviceUsageWindowInDays を適用します。 最初の更新トークンには lifetime=DeviceUsageWindowInDays があり、後続の各 grant_type=refresh_token 要求は新しい更新トークンを取得します。 このプロセスは、ネイティブ クライアントまたは機密クライアントとデバイス認証でのみ行われます。
• 登録済みデバイス、デバイス認証: AD FS では、KMSI と同様の PersistentSsoLifetimeMins と DeviceUsageWindowInDays が使用されます。 ネイティブ クライアントと機密クライアントの両方が、デバイス認証に基づいて新しい更新トークンを取得する必要があります。

詳細については、 AD FS のシングル サインオンに関するドキュメントを参照してください。

スコープ

AD FS にリソースを登録するときに、AD FS が特定のアクションを実行できるようにスコープを構成できます。 スコープの構成と共に、アクションを実行するには、AD FS の要求でスコープ値を送信する必要があります。 たとえば、管理者はリソースの登録時にスコープを openid として構成し、アプリケーション (クライアント) は AD FS が ID トークンを発行するために認証要求の scope = openid を送信する必要があります。 AD FS で使用可能なスコープの詳細を次に示します。

• aza - ブローカー クライアントに OAuth 2.0 プロトコル拡張機能 を使用し、スコープ パラメーターにスコープ azaが含まれている場合、サーバーは新しいプライマリ更新トークンを発行します。 応答の refresh_token フィールドにトークンを設定し、新しいプライマリ更新トークンが適用されている場合は、 refresh_token_expires_in field を新しいプライマリ更新トークンの有効期間に設定します。
• openid - openid 接続認証プロトコルの使用をアプリケーション要求に許可します。
• logon_cert - 認証されたユーザーに対話形式でログオンするために使用できるサインイン証明書をアプリケーションが要求できるようにします。 AD FS サーバーは、応答から access_token パラメーターを省略し、代わりに base64 でエンコードされた CMS 証明書チェーンまたは CMC 完全 PKI 応答を提供します。 詳細については、「 MS-OAPX: OAuth 2.0 プロトコル拡張機能」を参照してください。
• user_impersonation - AD FS から代理アクセス トークンを要求します。 このスコープの使用方法の詳細については、「 AD FS 2016 で OAuth を使用して On-Behalf-Of (OBO) を使用して多層アプリケーションを構築する」を参照してください。
• allatclaims – アプリケーションがアクセス トークン内の要求を ID トークンにも追加できるようにします。
• vpn_cert - アプリケーションが VPN 証明書を要求できるようにします。これにより、EAP-TLS 認証を使用して VPN 接続が確立されます。 この機能はサポートされなくなりました。
• email - アプリケーションがサインインしているユーザーの電子メール要求を要求できるようにします。
• profile - アプリケーションがサインインしているユーザーのプロファイル関連の要求を要求できるようにします。

請求

AD FS によって発行されたセキュリティ トークン (アクセス トークンと ID トークン) には、認証されたサブジェクトに関する情報のクレームまたはアサーションが含まれます。 アプリケーションでは、次のようなさまざまなタスクに要求を使用できます。

• トークンを検証する
• サブジェクトのディレクトリ テナントを特定する
• ユーザー情報の表示
• サブジェクトの承認を判断する

特定のセキュリティ トークンに存在する要求は、トークンの種類、ユーザーの認証に使用される資格情報の種類、およびアプリケーション構成によって異なります。

高レベルの AD FS 認証フロー

大まかなフローの図を次に示します。

1. AD FS は、クライアントから認証要求を受け取ります。

2. AD FS は、認証要求のクライアント ID を、クライアントと AD FS のリソース登録中に取得したクライアント ID で検証します。 機密クライアントを使用している場合、AD FS は認証要求で指定されたクライアント シークレットも検証します。 AD FS は、クライアントのリダイレクト URI も検証します。

3. AD FS は、認証要求で渡されるリソース パラメーターを介してクライアントがアクセスするリソースを識別します。 MSAL クライアント ライブラリを使用する場合、リソース パラメーターは送信されません。 代わりに、リソース URL はスコープ パラメーターの一部として送信されます。 scope = [resource url]/[scope values, example, openid].

   リソースまたはスコープ のパラメーターを使用してリソースが渡されない場合、AD FS は既定のリソース urn:microsoft:userinfo を使用します。そのポリシー (MFA、発行、承認ポリシーなど) を構成できません。

4. 次の AD FS は、クライアントがリソースにアクセスするためのアクセス許可を持っているかどうかを検証します。 AD FS は、認証要求で渡されたスコープが、リソースの登録中に構成されたスコープと一致するかどうかを検証します。 クライアントにアクセス許可がない場合、または認証要求で適切なスコープが送信されない場合、認証フローは終了します。

5. アクセス許可とスコープが検証されると、AD FS は構成された 認証方法を使用してユーザーを認証します。

6. リソース ポリシーまたはグローバル認証ポリシーに従って 別の認証方法 が必要な場合、AD FS によって追加の認証がトリガーされます。

7. AD FS では、 Microsoft Entra 多要素認証 または サード パーティの多要素認証 を使用して認証を行います。

8. ユーザーが認証されると、AD FS によって 要求規則が適用されます。 要求規則は、セキュリティ トークンの一部としてリソースに送信される要求を決定します。 AD FS は、ユーザーがリソースにアクセスするために必要な条件を満たしていることを確認する アクセス制御ポリシー も適用します。

9. 次に、AD FS によってアクセスが生成され、トークンが更新されます。 AD FS は ID トークンも生成します。

10. AD FS は認証要求を受け取ります。

11. 認証要求に scope = allatclaims を含める場合、ID トークン は、定義された要求規則に基づいてアクセス トークンに要求を含むようにカスタマイズされます。

12. 必要なトークンが生成されてカスタマイズされると、AD FS はクライアントに応答し、トークンを含めます。 ID トークンの応答は、認証要求に scope = openidが含まれている場合にのみ応答に含まれます。 クライアントは、トークン エンドポイントを使用して、認証後に常に ID トークンを取得できます。

ライブラリの種類

AD FS では、次の 2 種類のライブラリを使用します。

• クライアント ライブラリ: ネイティブ クライアントとサーバー アプリは、クライアント ライブラリを使用して、Web API などのリソースを呼び出すためのアクセス トークンを取得します。 MICROSOFT Authentication Library (MSAL) は、AD FS 2019 を使用する場合に推奨される最新のクライアント ライブラリです。

• サーバー ミドルウェア ライブラリ: Web アプリは、ユーザー サインインにサーバー ミドルウェア ライブラリを使用します。 Web API は、サーバー ミドルウェア ライブラリを使用して、ネイティブ クライアントまたは他のサーバーによって送信されたトークンを検証します。 .NET 用の Open Web Interface (OWIN) は、推奨されるミドルウェア ライブラリです。

ID トークンをカスタマイズする (ID トークン内の追加の要求)

特定のシナリオでは、Web アプリ クライアントが機能に役立つ ID トークンに追加の要求を必要とする可能性があります。 次のいずれかのオプションを使用して、ID トークンに追加の要求を設定します。

オプション 1: このオプションは、パブリック クライアントがあり、Web アプリにアクセスしようとしているリソースがない場合に使用します。 このオプションには以下が必要です。

• response_mode は次のように設定されます。 form_post
• 証明書利用者識別子 (Web API 識別子) はクライアント識別子と同じです

オプション 2: このオプションは、Web アプリにアクセスしようとしているリソースがあり、ID トークンを介して追加の要求を渡す必要がある場合に使用します。 パブリック クライアントと機密クライアントの両方を使用できます。 このオプションには以下が必要です。

• response_mode は次のように設定されます。 form_post

• KB4019472が AD FS サーバーにインストールされている

• スコープ allatclaims は、クライアントと RP のペアに割り当てられます。 Grant-ADFSApplicationPermissionを使用してスコープを割り当てることができます。 既に 1 回付与されている場合は、 Set-AdfsApplicationPermission を使用します。 PowerShell コマンドレットは、次の例で示されています。

  Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
  

カスタマイズされた ID トークンを取得するように AD FS で Web アプリを構成する方法を理解するには、 AD FS 2016 以降のカスタム ID トークンに関するページを参照してください。

1 回のログアウト

1 回のログアウトでは、セッション ID を使用するすべてのクライアント セッションが終了します。 AD FS 2016 以降では、OpenID Connect/OAuth のシングル ログアウトがサポートされています。 詳細については、「 AD FS を使用した OpenID Connect のシングル ログアウト」を参照してください。

AD FS のエンドポイント