認証とは
警告
このコンテンツは、以前の Azure AD v1.0 エンドポイント用です。 新しいプロジェクトには Microsoft ID プラットフォームを使用します。
認証 は、正当な資格情報をパーティーに要求する行為であり、ID とアクセス制御に使用されるセキュリティ プリンシパルを作成するための基礎を提供します。 簡単に言えば、自分が自分であることを証明するプロセスです。 認証は AuthN と短縮される場合があります。
承認 とは、認証されたセキュリティ プリンシパルに何かを行うアクセス許可を付与する行為です。 アクセスが許可されているデータと、それに対して実行できる操作を指定します。 認可は AuthZ と短縮される場合があります。
開発者向け Azure Active Directory (v1.0) (Azure AD) は、OAuth 2.0 や OpenID Connect などの業界標準のプロトコルと、コーディングを迅速に開始するのに役立つさまざまなプラットフォーム用のオープンソース ライブラリをサポートすることで、サービスとしての ID を提供することで、アプリケーション開発者の認証を簡素化します。
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、更新トークン、アクセス トークン) と承認コードを生成でき、それらを機能させるために異なるトークンが必要になります。 このグラフでは、次の概要を示します。
| 流れ | 必須事項 | IDトークン (id_token) | アクセス トークン | 更新トークン | 承認コード |
|---|---|---|---|---|---|
| 認可コードフロー | x | x | x | x | |
| 暗黙的なフロー | x | x | |||
| ハイブリッド OIDC フロー | x | x | |||
| 更新トークンの引き換え | 更新トークン | x | x | x | |
| 代理フロー | アクセス トークン | 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 プロビジョニング フローを示しています。 その中に、テナント A がアプリケーションを所有し、テナント B がサービス プリンシパルを介してアプリケーションをインスタンス化している 2 つのテナント (A と B) が存在します。
このプロビジョニング フローでは、次の操作を行います。
- テナント B のユーザーがアプリでサインインを試みると、承認エンドポイントはアプリケーションのトークンを要求します。
- ユーザー資格情報が取得され、認証用に検証されます
- ユーザーは、アプリがテナント B にアクセスするための同意を求められます
- Azure AD は、テナント A のアプリケーション オブジェクトを、テナント B にサービス プリンシパルを作成するためのブループリントとして使用します
- ユーザーが要求されたトークンを受け取る
このプロセスは、他のテナント (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 アプリケーション ロールのフレンドリ名が含まれます。 |
| 範囲 | クライアント アプリケーションに付与されたアクセス許可を示します。 |
| サブジェクト | トークンが情報を示す主対象を示します。 |
| テナント ID | トークンを発行したディレクトリ テナントの一意で不変な識別子が含まれています。 |
| トークンの有効期間 | トークンが有効な時間間隔を定義します。 |
| ユーザー プリンシパル名 | サブジェクトのユーザー プリンシパル名を格納します。 |
| バージョン | トークンのバージョン番号を格納します。 |