Azure Active Directory 開発者向け用語集

この記事では、Azure Active Directory (AD) 開発で重要となるいくつかの概念について定義しています。Azure AD のアプリケーション開発を習得する際の参考としてください。

Twitter アプリケーションの

承認サーバーによって発行されるセキュリティ トークンの一種。クライアント アプリケーションが、保護されたリソース サーバーにアクセスする目的で使用します。 要求されたレベルのアクセスに関して、リソース所有者がクライアントに付与しているアクセス権限を通常 JSON Web トークン (JWT) の形式で 1 つにまとめたものがこのトークンです。 このトークンは、認証対象に関して当てはまる要求をすべて含んでおり、クライアント アプリケーションが特定のリソースにアクセスする際に一種の資格情報として使用することができます。 また、これを使用すると、リソース所有者がクライアントに資格情報を開示する必要がなくなります。

表現の対象となる資格情報によっては、アクセス トークンを "User+App" や "App-Only" と呼ぶこともあります。 たとえばクライアント アプリケーションが使用する承認付与には、次のようなタイプがあります。

  • "承認コード" 型の承認付与: エンド ユーザーはまず、リソース所有者として認証を行い、リソースにアクセスするための承認をクライアントに委任します。 その後クライアントは、アクセス トークンを取得した時点で認証を行います。 このトークンは、クライアント アプリケーションを承認したユーザーとアプリケーションの両方を表すことから、より具体的に "User+App" トークンと呼ばれることがあります。
  • "クライアント資格情報" 型の承認付与: クライアントが行うのは単一の認証のみです。クライアントがリソース所有者の認証/承認なしで機能することから、このトークンは、"App-Only" トークンと呼ばれることがあります。

詳細については、「Azure AD のトークン リファレンス」を参照してください。

アプリケーション マニフェスト

Azure Portalに備わっている機能の 1 つで、アプリケーションの ID 構成が JSON 形式で生成されて表現されます。そのマニフェストが関連付けられている Application エンティティと ServicePrincipal エンティティを更新するための機構として使用されます。 詳細については、「Azure Active Directory のアプリケーション マニフェストについて」を参照してください。

アプリケーション オブジェクト

Azure Portal でアプリケーションを登録/更新すると、そのテナントを対象に、アプリケーション オブジェクトおよび対応するサービス プリンシパル オブジェクトの両方が作成/更新されます。 アプリケーション オブジェクトは、アプリケーションの ID 構成をグローバルに (そのアプリケーションがアクセスできるすべてのテナントに対して) "定義" します。このオブジェクトをテンプレートとして、対応するサービス プリンシパル オブジェクトが "生成" され、実行時にローカル (特定のテナント) で使用されます。

詳細については、「アプリケーション オブジェクトおよびサービス プリンシパル オブジェクト」を参照してください。

アプリケーションの登録

アプリケーションの "ID とアクセス管理" の機能を Azure AD で行うためには、そのアプリケーションを Azure AD テナントに登録する必要があります。 アプリケーションを Azure AD に登録するとき、アプリケーションに使用する ID 構成を指定します。これによって Azure AD との連携が可能となり、次のような機能が使用できるようになります。

詳細については、「Azure Active Directory とアプリケーションの統合」を参照してください。

authentication

特定の当事者に対し、本物の資格情報の提示を要求する行為。ID 管理とアクセス制御に必要なセキュリティ プリンシパルの拠り所となります。 たとえば OAuth2 承認付与時には、使用する付与形態に応じて、リソース所有者またはクライアント アプリケーションの役割を果たす当事者が、本物であることを証明する側になります。

authorization

認証済みのセキュリティ プリンシパルに対し、何かを実行する権限を付与する行為。 Azure AD プログラミング モデルでは、主に次の 2 つの使用ケースが存在します。

承認コード

"承認コード" 型 (4 種類ある OAuth2 承認付与の 1 つ) のフローの過程で承認エンドポイントからクライアント アプリケーションに提供される有効期間の短い "トークン"。 リソース所有者の認証に対する応答としてこのコードがクライアント アプリケーションに返されることで、要求されたリソースにアクセスするための承認がリソース所有者から委任されていることが示されます。 このフローの中で、このコードは後で アクセス トークンと引き換えられます。

承認エンドポイント

承認サーバーによって実装されるエンドポイントの 1 つ。OAuth2 承認付与フローの過程で承認付与を提供するための、リソース所有者との対話に使用されます。 実際に付与される内容は、使用されている承認付与フローによって異なる場合があります (承認コードセキュリティ トークンなど)。

詳細については、OAuth2 仕様の承認付与タイプ承認エンドポイントに関するセクションおよび OpenIDConnect 仕様を参照してください。

承認付与

リソース所有者の保護されたリソースにアクセスしてよいという承認を表す資格情報。クライアント アプリケーションに対して付与されます。 クライアント アプリケーションは、その種類や要件に応じて、OAuth2 Authorization Framework によって規定された 4 つの付与タイプ ("承認コード付与"、"クライアント資格情報付与"、"暗黙的付与"、"リソース所有者パスワード資格情報付与") のいずれかを使ってアクセス許可を得ることができます。 クライアントに返される資格情報は、使用された承認付与のタイプに応じて、アクセス トークン承認コード (その後アクセス トークンに交換される) のいずれかになります。

承認サーバー

OAuth2 Authorization Framework の定義によれば、リソース所有者を認証し、その承認を得た後にアクセス トークンをクライアントに発行するサーバーをいいます。 クライアント アプリケーションは実行時に、その承認エンドポイントおよびトークン エンドポイントを介し、OAuth2 によって定義された承認付与に従って承認サーバーと対話します。

Azure AD アプリケーション統合の場合、Azure AD アプリケーションと Microsoft サービス API (Microsoft Graph API など) に使用する承認サーバーの役割を Azure AD が実装します。

要求

セキュリティ トークンには要求が格納されます。この要求を通じて、一方のエンティティ (クライアント アプリケーションリソース所有者など) に関するアサーションが、もう一方のエンティティ (リソース サーバーなど) に渡されます。 要求は、トークンのサブジェクト (承認サーバーによって認証されたセキュリティ プリンシパルなど) に関する事実を伝達する名前と値のペアです。 特定のトークンとして提示される要求は、いくつかの不確定要素 (トークンの種類、サブジェクトの認証に使用された資格情報の種類、アプリケーション構成など) に依存します。

詳細については、「Azure AD のトークン リファレンス」を参照してください。

クライアント アプリケーション

OAuth2 Authorization Framework の定義によれば、リソース所有者に代わって、保護されたリソースを要求するアプリケーションをいいます。 "クライアント" という言葉の意味には、特定のハードウェア実装上の特性 (アプリケーションがサーバーで実行されるのか、デスクトップで実行されるのか、またはそれ以外のデバイスで実行されるのか、など) は含まれません。

クライアント アプリケーションは、リソース所有者に承認を要求することによって、OAuth2 承認付与フローに参加し、リソース所有者に代わって API やデータにアクセスすることができます。 OAuth2 Authorization Framework では、資格情報の機密維持に対するクライアントの能力に基づき、"confidential" と "public" という 2 種類のクライアントを定義しています。 アプリケーションは、Web サーバー上で実行される Web クライアント (confidential)、デバイス上にインストールされるネイティブ クライアント (public)、またはデバイスのブラウザーで実行されるユーザーエージェントベース クライアント (public) を実装できます。

リソース所有者からクライアント アプリケーションに承認 (リソース所有者に代わって特定の権限で保護されたリソースにアクセスするための) を付与するプロセス。 クライアントから要求された権限によっては、組織データまたは個人データへのアクセスを許可することへの同意が管理者 (組織データの場合) またはユーザー (個人データの場合) に求められます。 さらに、マルチテナントのシナリオでは、同意するユーザーのテナントにアプリケーションのサービス プリンシパルが記録されます。

ID トークン

承認サーバー承認エンドポイントから提供される OpenID Connect セキュリティ トークン。このトークンには、エンド ユーザーのリソース所有者の認証に関連した要求が格納されます。 ID トークンもアクセス トークンと同様、デジタル署名された JSON Web トークン (JWT) として表現されます。 ただし、アクセス トークンとは異なり、ID トークンの要求は、リソース アクセス (特にアクセス制御) に関連した目的には使用されません。

詳細については、「Azure AD のトークン リファレンス」を参照してください。

マルチテナント アプリケーション

クライアントが登録されたテナントに限らず、任意の Azure AD テナントにプロビジョニングされたユーザーによるサインインと同意を有効にするアプリケーションのクラス。 ネイティブ クライアント アプリケーションは、既定ではマルチテナントとなります。これに対し、Web クライアントWeb リソース/API アプリケーションは、シングル テナントまたはマルチテナントを選択できるようになっています。 一方シングル テナントとして登録される Web アプリケーションの場合は、アプリケーションの登録先と同じテナントにプロビジョニングされたユーザー アカウントからのみサインインが許可されます。

詳細については、「マルチテナント アプリケーション パターンを使用してすべての Azure Active Directory (AD) ユーザーがサインインできるようにする方法」を参照してください。

ネイティブ クライアント

デバイス上にネイティブでインストールされるタイプの クライアント アプリケーション 。 すべてのコードがデバイス上で実行され、機密性を保った状態でプライベートに資格情報を保存することができないため、"public" クライアントと見なされます。 詳細については、OAuth2 のクライアント タイプとプロファイルに関するページを参照してください。

アクセス許可

クライアント アプリケーションは、アクセス許可要求を宣言することでリソース サーバーへのアクセス権を取得します。 次の 2 種類があります。

  • "委任" されたアクセス許可。サインインしたリソース所有者から委任された承認を使用して、スコープに基づくアクセス権を指定します。実行時には、クライアントのアクセス トークン"scp" 要求としてリソースに提示されます。
  • "アプリケーション" のアクセス許可。クライアント アプリケーションの資格情報/ID を使用してロールベースのアクセス権を指定します。実行時には、クライアントのアクセス トークンの "roles" 要求としてリソースに提示されます。

これらの要求は 同意 プロセス時にも出現し、管理者またはリソース所有者には、そのテナント内のリソースに対するクライアント アクセスを許可/拒否する機会が与えられます。

アクセス許可要求の構成は、Azure Portal の [アプリケーション] タブまたは [設定] タブにある [必要なアクセス許可] で、必要な "委任されたアクセス許可" と "アプリケーションのアクセス許可" (後者には全体管理者ロールのメンバーシップが必要) を選択することによって行います。 public クライアントは、資格情報を安全に維持できないため、要求できるのは委任されたアクセス許可のみです。一方 confidential クライアントは、委任されたアクセス許可とアプリケーションのアクセス許可のどちらでも要求することができます。 クライアントのアプリケーション オブジェクトは、宣言された権限をその requiredResourceAccess プロパティに格納します。

リソース所有者

OAuth2 Authorization Framework の定義によれば、保護されたリソースへのアクセス権を付与することのできるエンティティをいいます。 リソース所有者が人である場合は、"エンド ユーザー" と呼ばれます。 たとえばクライアント アプリケーションは、Microsoft Graph API を介してユーザーのメールボックスにアクセスする必要があるとき、そのメールボックスのリソース所有者に権限を要求する必要があります。

リソース サーバー

OAuth2 Authorization Framework の定義によれば、保護されたリソースのホストとして、アクセス トークンを提示するクライアント アプリケーションからのリソース要求 (保護されたリソースに対する要求) を受理し、応答する機能を備えたサーバーをいいます。 保護されたリソース サーバーまたはリソース アプリケーションと呼ばれることもあります。

リソース サーバーは API を公開しており、そこで保護されているリソースに対しては、OAuth 2.0 Authorization Framework を使用して、スコープロールを介したアクセスが強制的に適用されます。 たとえば、Azure AD テナント データへのアクセスを提供する Azure AD Graph API や、メール、カレンダーなどのデータへのアクセスを提供する Office 365 API があります。 これらの API はどちらも Microsoft Graph API から利用することができます。

リソース アプリケーションの ID 構成は、クライアント アプリケーションと同様、Azure AD テナントへの 登録 を通じて確立され、アプリケーション オブジェクトとサービス プリンシパル オブジェクトの両方が得られます。 Azure AD Graph API など、Microsoft が提供している一部の API には、あらかじめ登録されているサービス プリンシパルが存在し、プロビジョニング時にすべてのテナントで利用できるようになっています。

roles

ロールは、スコープと同様、リソース サーバーの保護されたリソースへのアクセスを管理するための手段です。 ロールには、"ユーザー" ロールと "アプリケーション" ロールの 2 種類があります。ユーザー ロールでは、リソースへのアクセスを必要とするユーザー/グループに関してロールベースのアクセス制御を実装します。これに対してアプリケーション ロールで実装するのは、アクセスを要求するクライアント アプリケーションの場合と同じです。

ロールは、リソースによって定義される文字列 ("経費承認者"、"読み取り専用"、"Directory.ReadWrite.All" など) です。Azure Portal からリソースのアプリケーション マニフェストを介して管理され、リソースの appRoles プロパティに格納されます。 Azure Portal は、ユーザーを "ユーザー" ロールに割り当てたり、"アプリケーション" ロールに対するクライアント アプリケーションのアクセス許可を構成したりするためにも使用します。

Azure AD の Graph API によって公開されているアプリケーション ロールの詳しい説明については、Graph API のアクセス許可スコープに関するページを参照してください。 具体的な実装例については、「Role based access control in cloud applications using Azure AD」(Azure AD を使用したクラウド アプリケーションでのロール ベースのアクセス制御) を参照してください。

スコープ

スコープは、ロールと同様、リソース サーバーの保護されたリソースへのアクセスを管理するための手段です。 リソースへの委任されたアクセス権を所有者から付与されているクライアント アプリケーションに対し、スコープベースのアクセス制御を実装する目的で使用されます。

スコープは、リソースによって定義される文字列 ("Mail.Read"、"Directory.ReadWrite.All" など) です。Azure Portal からリソースのアプリケーション マニフェストを介して管理され、リソースの oauth2Permissions プロパティに格納されます。 Azure Portal は、クライアント アプリケーションの、スコープに対する委任されたアクセス許可を構成するためにも使用します。

推奨される名前付け規則は、"resource.operation.constraint" 形式です。 Azure AD の Graph API によって公開されているスコープの詳しい説明については、Graph API のアクセス許可スコープに関するページを参照してください。 Office 365 サービスによって公開されているスコープについては、Office 365 API アクセス許可に関するリファレンスを参照してください。

セキュリティ トークン

要求を含んだ署名付きのドキュメント (OAuth2 トークン、SAML 2.0 アサーションなど)。 OAuth2 承認付与の場合、アクセス トークン (OAuth2) と ID トークンがセキュリティ トークンの種類になります。どちらも JSON Web トークン (JWT) として実装されます。

サービス プリンシパル オブジェクト

Azure Portal でアプリケーションを登録/更新すると、そのテナントを対象に、アプリケーション オブジェクトおよび対応するサービス プリンシパル オブジェクトの両方が作成/更新されます。 アプリケーション オブジェクトは、アプリケーションの ID 構成をグローバルに (関連するアプリケーションがアクセスできるすべてのテナントに対して) "定義" します。このオブジェクトをテンプレートとして、対応するサービス プリンシパル オブジェクトが "生成" され、実行時にローカル (特定のテナント) で使用されます。

詳細については、「アプリケーション オブジェクトおよびサービス プリンシパル オブジェクト」を参照してください。

サインイン

クライアント アプリケーションがエンド ユーザーの認証を開始し、関連する状態を収集するプロセス。セキュリティ トークンを取得すると共に、アプリケーションのセッションをその状態に限定することを目的としています。 状態には、ユーザー プロファイル情報などのアーティファクトや、トークンの要求から生成される情報が含まれている場合があります。

アプリケーションのサインイン機能は通常、シングル サインオン (SSO) を実装するために使用されます。 また、この機能は、エンド ユーザーが (初回サインイン時に) アプリケーションにアクセスするためのエントリ ポイントとして "サインアップ" 機能の前に実行されることがあります。 サインアップ機能は、ユーザーごとの特別な状態を収集して永続化するために使用され、 ユーザーの同意を必要とする場合があります。

サインアウト

エンド ユーザーの認証を取り消し、サインインの過程でクライアント アプリケーションのセッションに関連付けられたユーザーの状態を解除するプロセス。

テナント

Azure AD ディレクトリのインスタンスを "Azure AD テナント" といいます。 テナントには、次のようなさまざまな機能が備わっています。

また、テナントはサブスクリプションのプロビジョニング中に Azure AD または Office 365 のサブスクリプションに関連付けられるため、サブスクリプションの ID 管理機能とアクセス管理機能が利用できるようになります。 テナントを利用するための各種方法について詳しくは、「Azure Active Directory テナントを取得する方法」をご覧ください。 サブスクリプションと Azure AD テナントの関係について詳しくは、「Azure サブスクリプションを Azure Active Directory に関連付ける方法」をご覧ください。

トークン エンドポイント

承認サーバーによって実装されるエンドポイントの 1 つ。OAuth2 承認付与をサポートするために使用されます。 付与された承認によっては、クライアントへのアクセス トークン (と関連する "更新" トークン) を取得したり、OpenID Connect プロトコルと共に使用する場合に ID トークンを取得したりできます。

ユーザー エージェント ベースのクライアント

Web サーバーからコードをダウンロードしてユーザー エージェント (Web ブラウザーなど) 内で実行するクライアント アプリケーションの一種。その例としてシングル ページ アプリケーション (SPA) が挙げられます。 すべてのコードがデバイス上で実行され、機密性を保った状態でプライベートに資格情報を保存することができないため、"public" クライアントと見なされます。 詳細については、OAuth2 のクライアント タイプとプロファイルに関するページを参照してください。

ユーザー プリンシパル

サービス プリンシパル オブジェクトはアプリケーション インスタンスを表現するためのセキュリティ プリンシパルです。一方、ユーザー プリンシパル オブジェクトも、セキュリティ プリンシパルのひとつですが、表現の対象となるのはユーザーです。 ユーザー オブジェクトのスキーマは、Azure AD Graph のユーザー エンティティによって定義されます (姓や名をはじめとするユーザー関連のプロパティ、ユーザー プリンシパル名、ディレクトリ ロール メンバーシップなど)。これにより、実行時にユーザー プリンシパルを設定するための Azure AD のユーザー ID 構成が提供されます。 ユーザー プリンシパルは、シングル サインオン、同意の委任の記録、アクセス制御の意思決定などの際に、認証済みのユーザーを表す目的で使用されます。

Web クライアント

Web サーバーですべてのコードを実行するクライアント アプリケーションの一種。資格情報をサーバー上に安全に保存することで、"confidential" クライアントとして動作することができます。 詳細については、OAuth2 のクライアント タイプとプロファイルに関するページを参照してください。

次のステップ

Azure Active Directory 開発者ガイド」をお読みください。Azure AD とアプリケーションの統合や、Azure AD 認証の基礎、サポートされる認証シナリオなど、Azure AD 開発に関連したあらゆるトピックへの入口となっています。

Microsoft のコンテンツ改善のため、以下のコメント セクションよりご意見をお寄せください。新しい定義に関するリクエストのほか、既存の定義の更新のリクエストもお待ちしております。