認証とは
警告
このコンテンツは、以前の Azure AD v1.0 エンドポイント用です。 新しいプロジェクトには Microsoft ID プラットフォームを使用します。
認証とは、特定の当事者に対し、本物の資格情報の提示を要求する行為であり、ID 管理とアクセス制御に必要なセキュリティ プリンシパルの拠り所となります。 簡単に言うと、ユーザーが身元を証明するプロセスです。 認証は AuthN と短縮される場合があります。
承認は、認証済みのセキュリティ プリンシパルに対し、何かを実行する権限を付与する行為です。 これにより、アクセスが許可されているデータと、そのデータで実行できる操作が指定されます。 承認は AuthZ と短縮される場合があります。
開発者向け Azure Active Directory (v1.0) (Azure AD) は、OAuth 2.0 や OpenID Connect などの業界標準プロトコルをサポートする Identity as a Service と、コーディングを手軽に開始するうえで役立つ、さまざまなプラットフォーム向けのオープン ソース ライブラリを提供することで、アプリケーション開発者のために認証を簡素化します。
Azure AD プログラミング モデルでは、主に次の 2 つの使用ケースが存在します。
- OAuth 2.0 認可付与フローの中で - リソース所有者がクライアント アプリケーションに認可を付与すると、その所有者のリソースにクライアントがアクセスできます。
- クライアントによるリソース アクセス時 - リソース サーバー側で実装されます。アクセス トークン内に存在する要求値に基づいてアクセス制御の判断を行います。
Azure AD での認証の基本
ID が必要とされる最も基本的なシナリオについて考えてみましょう。たとえば、Web ブラウザーのユーザーが Web アプリケーションに対して認証する必要があるとします。 次の図に、このシナリオを示します。
図に示されているさまざまなコンポーネントについて、次のことを理解しておく必要があります。
- Azure AD は ID プロバイダーです。 ID プロバイダーは、組織のディレクトリに存在するユーザーとアプリケーションの ID を確認し、それらのユーザーやアプリケーションの認証が成功したらセキュリティ トークンを発行する役割を担います。
- Azure AD に認証を委託するアプリケーションを、Azure Active Directory (Azure AD) に登録する必要があります。 Azure AD は、アプリをディレクトリに登録し、一意に識別します。
- 開発者は、オープン ソース Azure AD 認証ライブラリを使用して、プロトコルの詳細を処理することで認証を容易にすることができます。 詳細については、Microsoft ID プラットフォームの v2.0 認証ライブラリと v1.0 認証ライブラリを参照してください。
- ユーザーが認証されたら、アプリケーションは認証が成功したことを確認するために、ユーザーのセキュリティ トークンを検証する必要があります。 さまざまな言語やフレームワークのクイック スタート、チュートリアル、およびコード サンプルを参照できます。これらは、アプリケーションが何を行う必要があるかを示しています。
- 迅速にアプリを構築し、トークンの取得、トークンの更新、ユーザーへのサインイン、ユーザー情報の表示などの機能を追加するには、このドキュメントの「クイック スタート」のセクションを参照してください。
- アクセス トークンの取得と Microsoft Graph API などの API への呼び出しでの使用、OpenID Connect を使用する従来の Web ブラウザー ベースのアプリでの Microsoft によるサインインの実装など、認証開発者の上位のタスクの詳細なシナリオ ベースの手順を取得するには、このドキュメントの「チュートリアル」のセクションを参照してください。
- コード サンプルをダウンロードするには、GitHub にアクセスしてください。
- 認証プロセスの要求と応答のフローは、使用した認証プロトコル (OAuth 2.0、OpenID Connect、WS-Federation、SAML 2.0 など) によって決まります。 プロトコルの詳細については、このドキュメントの「概念」の「認証プロトコル」セクションを参照してください。
上記の例のシナリオでは、次の 2 つの役割に基づいてアプリを分類することができます。
- リソースに安全にアクセスする必要があるアプリ
- リソース自体の役割を果たすアプリ
各フローがトークンとコードを生成する方法
クライアントの構築方法に応じて、Azure AD でサポートされている認証フローの 1 つ (または複数) を使用できます。 これらのフローでは、さまざまなトークン (id_tokens、更新トークン、アクセス トークン) と承認コードを生成し、異なるトークンを使用して動作させるようにすることができます。 このグラフで概要を示します。
| Flow | 必要 | id_token | アクセス トークン | 更新トークン | 承認コード |
|---|---|---|---|---|---|
| 承認コード フロー | x | x | x | x | |
| 暗黙的なフロー | x | x | |||
| ハイブリッド OIDC フロー | x | x | |||
| 更新トークンの使用 | 更新トークン | x | x | x | |
| On-Behalf-Of フロー | アクセス トークン | x | x | x | |
| クライアントの資格情報 | x (アプリのみ) |
暗黙的モードで発行されたトークンには、URL を介してブラウザーに返されるために長さの制限があります (response_mode は query または fragment)。 一部のブラウザーでは、ブラウザーのバーに入力できる URL のサイズに制限があり、長すぎると失敗します。 したがって、これらのトークンには groups または wids 要求がありません。
基本の説明は以上です。以降では、ID アプリ モデルと API、Azure AD でのプロビジョニングのしくみ、および Azure AD がサポートする一般的なシナリオに関する詳細情報へのリンクの理解について説明します。
アプリケーション モデル
Azure AD は、次の 2 つの主な機能を満たすように設計された特定のモデルに従うアプリケーションを表します。
サポートする認証プロトコルに従ってアプリを識別する - これには、認証時に必要な識別子、URL、シークレット、および関連情報をすべて列挙する必要があります。 この場合、Azure AD は次の処理を行います。
- 実行時に認証をサポートするために必要なすべてのデータを保持します。
- アプリでアクセスする必要のあるリソースと、特定の要求がどのような状況下で満たされる必要があるかどうかを決定するための、すべてのデータを保持します。
- アプリ開発者のテナント内とその他の任意の Azure AD テナントにアプリ プロビジョニングを実装するためのインフラストラクチャを提供します。
トークンの要求時にユーザーの同意を処理し、テナント間でのアプリの動的プロビジョニングを容易にする - この場合、Azure AD は次の処理を行います。
- ユーザーと管理者が、その代理としてアプリがリソースにアクセスすることの同意を、動的に付与または拒否できるようにします。
- 管理者が、アプリに許可する操作と特定のアプリを使用できるユーザー、およびディレクトリのリソースにアクセスする方法を、最終的に決定できるようにします。
Azure AD では、アプリケーション オブジェクトはアプリケーションを抽象エンティティとして記述します。 開発者は、アプリケーションを操作します。 デプロイ時に、Azure AD が特定の アプリケーション オブジェクトをブループリントとして使用して、ディレクトリまたはテナント内でアプリケーションの具体的なインスタンスを表すサービス プリンシパルを作成します。 これは、特定のターゲット ディレクトリでアプリが実際に何ができるか、誰がそれを使用できるか、どのリソースにアクセスできるのか、などを定義するサービス プリンシパルです。 Azure AD は、同意によってアプリケーション オブジェクトからサービス プリンシパルを作成します。
次の図は、同意に基づくシンプルな Azure AD プロビジョニングの流れを示しています。 ここには、2 つのテナント (A、B) が存在します。テナント A はアプリケーションを所有し、テナント B はサービス プリンシパルを介してアプリケーションをインスタンス化します。
このプロビジョニングの流れは次のとおりです。
- テナント B のユーザーがアプリでサインインしようとすると、承認エンドポイントがアプリケーションのトークンを要求します。
- 認証のためにユーザーの資格情報が取得および検証されます
- ユーザーが、アプリがテナント B にアクセスすることの同意を求められます
- Azure AD が、テナント B にサービス プリンシパルを作成するためのブループリントとして、テナント A のアプリケーション オブジェクトを使用します
- ユーザーが要求されたトークンを受け取ります
その他のテナント (C、D など) に必要な回数だけ、このプロセスを繰り返すことができます。 テナント A は、アプリ (アプリケーション オブジェクト) のブループリントを保持します。 アプリが特定の同意である他のすべてのテナントのユーザーと管理者は、アプリケーションが各テナントの対応するサービス プリンシパル オブジェクトによって実行できる操作を引き続き制御します。 詳細については、Microsoft ID プラットフォームのアプリケーション オブジェクトとサービス プリンシパル オブジェクトに関するページを参照してください。
Azure AD のセキュリティ トークンの要求
Azure AD によって発行されるセキュリティ トークン (アクセス トークンと ID トークン) には、要求 (認証済みのサブジェクトに関する情報のアサーション) が含まれています。 アプリケーションは、次のようなさまざまなタスクの要求を使用できます。
- トークンを検証する
- サブジェクトのディレクトリ テナントを識別する
- ユーザー情報を表示する
- サブジェクトの承認を判断する
セキュリティ トークンに含まれる要求は、トークンの種類、ユーザーの認証に使用する資格情報の種類、アプリケーションの構成によって異なります。
Azure AD によって生成される各種要求の簡単な説明を次の表に示します。 詳細については、Azure AD によって発行されるアクセス トークンと ID トークンを参照してください。
| 要求 | 説明 |
|---|---|
| アプリケーション ID | トークンを使用しているアプリケーションを識別します。 |
| 対象ユーザー | トークンの対象である受信者のリソースを識別します。 |
| アプリケーションの認証コンテキスト クラスの参照 | クライアントが認証された方法 (パブリック クライアント対秘密のクライアント) を示します。 |
| 認証のインスタント | 認証が行われた日時を記録します。 |
| 認証方法 | トークンのサブジェクトが認証された方法 (パスワード、証明書など) を示します。 |
| 名 | Azure AD で設定されたユーザーの名を提供します。 |
| グループ | ユーザーがメンバーとして属する Azure AD グループのオブジェクト ID が含まれます。 |
| ID プロバイダー | トークンのサブジェクトを認証した ID プロバイダーを記録します。 |
| 発行時刻 | トークンが発行された時刻を記録します。多くの場合、トークンの鮮度を表すために使用されます。 |
| 発行者 | トークンを発行した STS と Azure AD テナントを識別します。 |
| 姓 | Azure AD で設定されたユーザーの姓を提供します。 |
| 名前 | トークンのサブジェクトを識別する、人が判読できる値を提供します。 |
| オブジェクト ID | Azure AD 内のサブジェクトの変更できない一意の識別子が含まれます。 |
| ロール | ユーザーに付与されている Azure AD アプリケーション ロールのフレンドリ名が含まれます。 |
| Scope | クライアント アプリケーションに付与されるアクセス許可を示します。 |
| サブジェクト | トークンが情報をアサートするプリンシパルを示します。 |
| テナント ID | トークンを発行したディレクトリ テナントの変更できない一意の識別子が含まれます。 |
| トークンの有効期間 | トークンが有効である期間を定義します。 |
| ユーザー プリンシパル名 | サブジェクトのユーザー プリンシパル名が含まれます。 |
| バージョン | トークンのバージョン番号が含まれます。 |