用語集: Microsoft ID プラットフォーム

  • [アーティクル]

これらの用語は、ドキュメント、Microsoft Entra 管理センター、Microsoft の認証ライブラリ、および Microsoft Graph API を使用するときに表示されます。 一部の用語は Microsoft 固有ですが、OAuth などのプロトコルや、Microsoft ID プラットフォームで使用するその他のテクノロジに関連する用語もあります。

アクセス トークン

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

アクセス トークンは短時間のみ有効で、取り消すことはできません。 承認サーバーは、アクセス トークンが発行されたときに更新トークンを発行することもあります。 更新トークンは、通常、confidential クライアント アプリケーションにのみ提供されます。

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

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

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

Actor

クライアント アプリケーションのもう 1 つの用語。 アクターは、サブジェクト (リソース所有者) に代わって行動するパーティです。

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

アプリケーション ID (クライアント ID) は、アプリケーションを Microsoft Entra ID に登録するときにMicrosoft ID プラットフォームがアプリケーションに割り当てる値です。 アプリケーション ID は、ID プラットフォーム内でアプリケーションとその構成を一意に識別する GUID 値です。 アプリケーションのコードにアプリ ID を追加します。認証ライブラリには、アプリケーションの実行時に ID プラットフォームへの要求に値が含まれます。 アプリケーション (クライアント) ID はシークレットではありません。パスワードやその他の資格情報として使用しないでください。

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

アプリケーション マニフェストは、関連する Application と ServicePrincipal エンティティを更新するメカニズムとして使用される、アプリケーションの ID 構成の JSON 表現を生成する機能です。 詳細については、「Microsoft Entra のアプリケーション マニフェストについて」を参照してください。

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

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

詳細については、アプリケーション オブジェクトとサービス プリンシパル オブジェクトに関するページを参照してください。

アプリケーションの登録

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

詳細については、「Microsoft Entra ID を使用したアプリケーションの統合」を参照してください。

認証

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

承認

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

Authorization code (承認コード)

OAuth 2.0 承認コード付与フロー中に、承認エンドポイントによってクライアント アプリケーションに提供される有効期間の短い値。4 つの OAuth 2.0 承認許可のいずれか。 認証コードとも呼ばれる承認コードは、リソース所有者の認証に応答してクライアント アプリケーションに返されます。 認証コードは、リソース所有者がリソースにアクセスするための承認をクライアント アプリケーションに委任したことを示します。 このフローの中で、承認コードは後で アクセス トークンと引き換えられます。

Authorization endpoint (承認エンドポイント)

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

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

承認付与

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

リソース所有者のパスワード資格情報の付与は、他のフローを使用できないシナリオを除いて使用しないでください。 SPA を構築する場合は、暗黙的な許可ではなく PKCE で承認コード フローを使用します。

承認サーバー

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

Microsoft ID プラットフォーム アプリケーション統合の場合、Microsoft Entra アプリケーションと Microsoft サービス API (Microsoft Graph API など) に使用する承認サーバー ロールは、Microsoft ID プラットフォームで実装されます。

要求

要求は、あるエンティティによって作成されたアサーションを別のエンティティに提供する セキュリティ トークン内の名前と値のペアです。 通常これらのエンティティは、リソース サーバーにアサーションを提供するクライアント アプリケーション または リソース サーバーです。 要求は、承認サーバーによって認証されたセキュリティ プリンシパルの ID など に関する事実を伝達します。 トークンに存在する要求は、トークンの種類、サブジェクトの認証に使用される資格情報の種類、アプリケーション構成など、いくつかの要因によって異なる場合があります。

詳細については、Microsoft ID プラットフォーム トークンのリファレンスに関するページを参照してください。

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

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

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

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

詳細については、「同意フレームワーク」を参照してください。

ID トークン

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

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

マネージド ID

開発者は資格情報を管理する必要がなくなります。 マネージド ID は、Microsoft Entra 認証をサポートするリソースに接続するときに使用する ID をアプリケーションに提供します。 アプリケーションは、マネージド ID を使用して Microsoft ID プラットフォーム トークンを取得できます。 たとえば、アプリケーションはマネージド ID を使用することで、開発者が安全に資格情報を格納できる Azure キー コンテナーなどのリソースにアクセスしたり、ストレージ アカウントにアクセスしたりできるようになります。 詳細については、マネージド ID の概要に関するページを参照してください。

Microsoft ID プラットフォーム

Microsoft ID プラットフォームは、Microsoft Entra ID サービスおよび開発者プラットフォームの進化版です。 これにより、開発者はすべての Microsoft ID にサインインし、Microsoft Graph、その他の Microsoft API、または開発者が作成した API を呼び出すトークンを取得することができます。 これは多彩な機能を備えたプラットフォームであり、認証サービス、ライブラリ、アプリケーションの登録と構成、完全な開発者向けドキュメント、サンプル コード、およびその他の開発者向けコンテンツによって構成されています。 Microsoft ID プラットフォームでは、OAuth 2.0 や OpenID Connect など業界標準のプロトコルがサポートされています。

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

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

詳細については、「マルチテナント アプリケーション パターンを使用して Microsoft Entra ユーザーをサインインさせる方法」を参照してください。

ネイティブ クライアント

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

アクセス許可

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

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

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

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

リフレッシュトークン

承認サーバーによって発行されるセキュリティ トークンの種類。 アクセス トークンの有効期限が切れる前に、承認サーバーから新しいアクセス トークンを要求するときに、関連付けられている更新トークンがクライアント アプリケーションに含まれます。 更新トークンは通常、 JSON Web トークン (JWT) として書式設定されます。

アクセス トークンとは異なり、更新トークンは取り消すことができます。 承認サーバーは、取り消された更新トークンを含むクライアント アプリケーションからの要求を拒否します。 承認サーバーが取り消された更新トークンを含む要求を拒否すると、クライアント アプリケーションはリソース所有者の代わりにリソース サーバーにアクセスするアクセス許可を失います。

詳細については、更新トークンに関するセクションをご覧ください。

リソース所有者

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

すべてのセキュリティ トークンは、リソース所有者を表します。 リソース所有者は、トークン内のサブジェクトのクレーム、オブジェクト ID のクレーム、および個人データが表すものです。 リソース所有者は、委任されたアクセス許可をクライアント アプリケーションにスコープの形式で付与するパーティです。 リソース所有者は、テナントまたはアプリケーション内の拡張されたアクセス許可を示すロールの受信者でもあります。

リソース サーバー

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

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

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

ロール

アプリ ロールは、スコープと同様、リソース サーバーの保護されたリソースへのアクセスを管理するための手段です。 スコープとは異なり、ロールは、ベースラインを超えてサブジェクトに付与されている特権を表します。つまり、自分の電子メールを読み取ることがスコープであり、全員の電子メールを読み取ることができる電子メール管理者であることがロールであるということです。

アプリ ロールでは、2 つの割り当てタイプをサポートできます。"ユーザー" 割り当ては、リソースへのアクセスを必要とするユーザー/グループに対してロールベースのアクセス制御を実装します。これに対して "アプリケーション" 割り当てで実装するのは、アクセスを要求するクライアント アプリケーションの場合と同じです。 アプリ ロールは、ユーザー割り当て可能、アプリ割り当て可能、またはその両方として定義できます。

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

Microsoft Graph API によって公開されているアプリケーション ロールの詳しい説明については、Graph API のアクセス許可スコープに関するページを参照してください。 実装手順の例については、「Azure ロールの割り当てを追加または削除する」をご覧ください。

スコープ

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

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

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

セキュリティ トークン

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

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

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

詳細については、アプリケーション オブジェクトとサービス プリンシパル オブジェクトに関するページを参照してください。

サインイン

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

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

サインアウト

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

サブジェクト

リソース所有者とも呼ばれます。

テナント

Microsoft Entra ディレクトリのインスタンスは、Microsoft Entra テナントと呼ばれます。 次のような機能が用意されています。

Microsoft Entra テナントはサインアップ時に作成され、Azure サブスクリプションおよび Microsoft 365 サブスクリプションに関連付けられます。これにより、そのサブスクリプションの ID およびアクセス管理機能が提供されます。 Azure サブスクリプション管理者は、追加の Microsoft Entra テナントを作成することもできます。 テナントを利用するための各種方法の詳細については、「Microsoft Entra テナントを取得する方法」を参照してください。 サブスクリプションと Microsoft Entra テナントの関係と、サブスクリプションの Microsoft Entra テナントへの関連付けまたは追加の方法については、「Azure サブスクリプションを Microsoft Entra テナントに関連付けるまたは追加する」を参照してください。

Token endpoint (トークン エンドポイント)

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

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

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

ユーザー プリンシパル

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

Web クライアント

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

ワークロード ID

他のサービスやリソースを認証してアクセスするためにソフトウェア ワークロード (アプリケーション、サービス、スクリプト、コンテナーなど) によって使用される ID。 Microsoft Entra では、ワークロード ID はアプリ、サービス プリンシパル、マネージド ID です。 詳細については、ワークロード ID の概要に関する記事を参照してください。

ワークロード ID フェデレーション

(サポートされるシナリオ用に) シークレットを管理することなく、外部のアプリやサービスから Microsoft Entra によって保護されたリソースに安全にアクセスできるようにします。 詳細については、ワークロード ID フェデレーションに関する記事を参照してください。

次のステップ

この用語集の用語の多くは、OAuth 2.0 と OpenID Connect プロトコルに関連しています。 ID プラットフォームを使用するためにプロトコルがどのように "ネットワーク上で" 動作するかを知る必要はありませんが、プロトコルの基本を理解すると、アプリでの認証と承認の構築とデバッグをより簡単に行うのに役立ちます: