Azure Active Directory 開発者向け用語集Azure Active Directory developer glossary

この記事では、Azure Active Directory (AD) 開発で重要となるいくつかの概念について定義しています。Azure AD のアプリケーション開発を習得する際の参考としてください。This article contains definitions for some of the core Azure Active Directory (AD) developer concepts, which are helpful when learning about application development for Azure AD.

Twitter アプリケーションのaccess token

承認サーバーによって発行されるセキュリティ トークンの一種。クライアント アプリケーションが、保護されたリソース サーバーにアクセスする目的で使用します。A type of security token issued by an authorization server, and used by a client application in order to access a protected resource server. 要求されたレベルのアクセスに関して、リソース所有者がクライアントに付与しているアクセス権限を通常 JSON Web トークン (JWT) の形式で 1 つにまとめたものがこのトークンです。Typically in the form of a JSON Web Token (JWT), the token embodies the authorization granted to the client by the resource owner, for a requested level of access. このトークンは、認証対象に関して当てはまる要求をすべて含んでおり、クライアント アプリケーションが特定のリソースにアクセスする際に一種の資格情報として使用することができます。The token contains all applicable claims about the subject, enabling the client application to use it as a form of credential when accessing a given resource. また、これを使用すると、リソース所有者がクライアントに資格情報を開示する必要がなくなります。This also eliminates the need for the resource owner to expose credentials to the client.

表現の対象となる資格情報によっては、アクセス トークンを "User+App" や "App-Only" と呼ぶこともあります。Access tokens are sometimes referred to as "User+App" or "App-Only", depending on the credentials being represented. たとえばクライアント アプリケーションが使用する承認付与には、次のようなタイプがあります。For example, when a client application uses the:

  • "承認コード" 型の承認付与: エンド ユーザーはまず、リソース所有者として認証を行い、リソースにアクセスするための承認をクライアントに委任します。"Authorization code" authorization grant, the end user authenticates first as the resource owner, delegating authorization to the client to access the resource. その後クライアントは、アクセス トークンを取得した時点で認証を行います。The client authenticates afterward when obtaining the access token. このトークンは、クライアント アプリケーションを承認したユーザーとアプリケーションの両方を表すことから、より具体的に "User+App" トークンと呼ばれることがあります。The token can sometimes be referred to more specifically as a "User+App" token, as it represents both the user that authorized the client application, and the application.
  • "クライアント資格情報" 型の承認付与: クライアントが行うのは単一の認証のみです。クライアントがリソース所有者の認証/承認なしで機能することから、このトークンは、"App-Only" トークンと呼ばれることがあります。"Client credentials" authorization grant, the client provides the sole authentication, functioning without the resource-owner's authentication/authorization, so the token can sometimes be referred to as an "App-Only" token.

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

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

Azure Portalに備わっている機能の 1 つで、アプリケーションの ID 構成が JSON 形式で生成されて表現されます。そのマニフェストが関連付けられている Application エンティティと ServicePrincipal エンティティを更新するための機構として使用されます。A feature provided by the Azure portal, which produces a JSON representation of the application's identity configuration, used as a mechanism for updating its associated Application and ServicePrincipal entities. 詳細については、「Azure Active Directory のアプリケーション マニフェストについて」を参照してください。See Understanding the Azure Active Directory application manifest for more details.

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

Azure Portal でアプリケーションを登録/更新すると、そのテナントを対象に、アプリケーション オブジェクトおよび対応するサービス プリンシパル オブジェクトの両方が作成/更新されます。When you register/update an application in the Azure portal, the portal creates/updates both an application object and a corresponding service principal object for that tenant. アプリケーション オブジェクトは、アプリケーションの ID 構成をグローバルに (そのアプリケーションがアクセスできるすべてのテナントに対して) "定義" します。このオブジェクトをテンプレートとして、対応するサービス プリンシパル オブジェクトが "生成" され、実行時にローカル (特定のテナント) で使用されます。The application object defines the application's identity configuration globally (across all tenants where it has access), providing a template from which its corresponding service principal object(s) are derived for use locally at run-time (in a specific tenant).

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

アプリケーションの登録application registration

アプリケーションの "ID とアクセス管理" の機能を Azure AD で行うためには、そのアプリケーションを Azure AD テナントに登録する必要があります。In order to allow an application to integrate with and delegate Identity and Access Management functions to Azure AD, it must be registered with an Azure AD tenant. アプリケーションを Azure AD に登録するとき、アプリケーションに使用する ID 構成を指定します。これによって Azure AD との連携が可能となり、次のような機能が使用できるようになります。When you register your application with Azure AD, you are providing an identity configuration for your application, allowing it to integrate with Azure AD and use features such as:

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

authenticationauthentication

特定の当事者に対し、本物の資格情報の提示を要求する行為。ID 管理とアクセス制御に必要なセキュリティ プリンシパルの拠り所となります。The act of challenging a party for legitimate credentials, providing the basis for creation of a security principal to be used for identity and access control. たとえば OAuth2 承認付与時には、使用する付与形態に応じて、リソース所有者またはクライアント アプリケーションの役割を果たす当事者が、本物であることを証明する側になります。During an OAuth2 authorization grant for example, the party authenticating is filling the role of either resource owner or client application, depending on the grant used.

authorizationauthorization

認証済みのセキュリティ プリンシパルに対し、何かを実行する権限を付与する行為。The act of granting an authenticated security principal permission to do something. Azure AD プログラミング モデルでは、主に次の 2 つの使用ケースが存在します。There are two primary use cases in the Azure AD programming model:

承認コードauthorization code

"承認コード" 型 (4 種類ある OAuth2 承認付与の 1 つ) のフローの過程で承認エンドポイントからクライアント アプリケーションに提供される有効期間の短い "トークン"。A short lived "token" provided to a client application by the authorization endpoint, as part of the "authorization code" flow, one of the four OAuth2 authorization grants. リソース所有者の認証に対する応答としてこのコードがクライアント アプリケーションに返されることで、要求されたリソースにアクセスするための承認がリソース所有者から委任されていることが示されます。The code is returned to the client application in response to authentication of a resource owner, indicating the resource owner has delegated authorization to access the requested resources. このフローの中で、このコードは後で アクセス トークンと引き換えられます。As part of the flow, the code is later redeemed for an access token.

承認エンドポイントauthorization endpoint

承認サーバーによって実装されるエンドポイントの 1 つ。OAuth2 承認付与フローの過程で承認付与を提供するための、リソース所有者との対話に使用されます。One of the endpoints implemented by the authorization server, used to interact with the resource owner in order to provide an authorization grant during an OAuth2 authorization grant flow. 実際に付与される内容は、使用されている承認付与フローによって異なる場合があります (承認コードセキュリティ トークンなど)。Depending on the authorization grant flow used, the actual grant provided can vary, including an authorization code or security token.

詳細については、OAuth2 仕様の承認付与タイプ承認エンドポイントに関するセクションおよび OpenIDConnect 仕様を参照してください。See the OAuth2 specification's authorization grant types and authorization endpoint sections, and the OpenIDConnect specification for more details.

承認付与authorization grant

リソース所有者の保護されたリソースにアクセスしてよいという承認を表す資格情報。クライアント アプリケーションに対して付与されます。A credential representing the resource owner's authorization to access its protected resources, granted to a client application. クライアント アプリケーションは、その種類や要件に応じて、OAuth2 Authorization Framework によって規定された 4 つの付与タイプ ("承認コード付与"、"クライアント資格情報付与"、"暗黙的付与"、"リソース所有者パスワード資格情報付与") のいずれかを使ってアクセス許可を得ることができます。A client application can use one of the four grant types defined by the OAuth2 Authorization Framework to obtain a grant, depending on client type/requirements: "authorization code grant", "client credentials grant", "implicit grant", and "resource owner password credentials grant". クライアントに返される資格情報は、使用された承認付与のタイプに応じて、アクセス トークン承認コード (その後アクセス トークンに交換される) のいずれかになります。The credential returned to the client is either an access token, or an authorization code (exchanged later for an access token), depending on the type of authorization grant used.

承認サーバーauthorization server

OAuth2 Authorization Framework の定義によれば、リソース所有者を認証し、その承認を得た後にアクセス トークンをクライアントに発行するサーバーをいいます。As defined by the OAuth2 Authorization Framework, the server responsible for issuing access tokens to the client after successfully authenticating the resource owner and obtaining its authorization. クライアント アプリケーションは実行時に、その承認エンドポイントおよびトークン エンドポイントを介し、OAuth2 によって定義された承認付与に従って承認サーバーと対話します。A client application interacts with the authorization server at runtime via its authorization and token endpoints, in accordance with the OAuth2 defined authorization grants.

Azure AD アプリケーション統合の場合、Azure AD アプリケーションと Microsoft サービス API (Microsoft Graph API など) に使用する承認サーバーの役割を Azure AD が実装します。In the case of Azure AD application integration, Azure AD implements the authorization server role for Azure AD applications and Microsoft service APIs, for example Microsoft Graph APIs.

要求claim

セキュリティ トークンには要求が格納されます。この要求を通じて、一方のエンティティ (クライアント アプリケーションリソース所有者など) に関するアサーションが、もう一方のエンティティ (リソース サーバーなど) に渡されます。A security token contains claims, which provide assertions about one entity (such as a client application or resource owner) to another entity (such as the resource server). 要求は、トークンのサブジェクト (承認サーバーによって認証されたセキュリティ プリンシパルなど) に関する事実を伝達する名前と値のペアです。Claims are name/value pairs that relay facts about the token subject (for example, the security principal that was authenticated by the authorization server). 特定のトークンとして提示される要求は、いくつかの不確定要素 (トークンの種類、サブジェクトの認証に使用された資格情報の種類、アプリケーション構成など) に依存します。The claims present in a given token are dependent upon several variables, including the type of token, the type of credential used to authenticate the subject, the application configuration, etc.

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

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

OAuth2 Authorization Framework の定義によれば、リソース所有者に代わって、保護されたリソースを要求するアプリケーションをいいます。As defined by the OAuth2 Authorization Framework, an application that makes protected resource requests on behalf of the resource owner. "クライアント" という言葉の意味には、特定のハードウェア実装上の特性 (アプリケーションがサーバーで実行されるのか、デスクトップで実行されるのか、またはそれ以外のデバイスで実行されるのか、など) は含まれません。The term "client" does not imply any particular hardware implementation characteristics (for instance, whether the application executes on a server, a desktop, or other devices).

クライアント アプリケーションは、リソース所有者に承認を要求することによって、OAuth2 承認付与フローに参加し、リソース所有者に代わって API やデータにアクセスすることができます。A client application requests authorization from a resource owner to participate in an OAuth2 authorization grant flow, and may access APIs/data on the resource owner's behalf. OAuth2 Authorization Framework では、資格情報の機密維持に対するクライアントの能力に基づき、"confidential" と "public" という 2 種類のクライアントを定義しています。The OAuth2 Authorization Framework defines two types of clients, "confidential" and "public", based on the client's ability to maintain the confidentiality of its credentials. アプリケーションは、Web サーバー上で実行される Web クライアント (confidential)、デバイス上にインストールされるネイティブ クライアント (public)、またはデバイスのブラウザーで実行されるユーザーエージェントベース クライアント (public) を実装できます。Applications can implement a web client (confidential) which runs on a web server, a native client (public) installed on a device, or a user-agent-based client (public) which runs in a device's browser.

リソース所有者からクライアント アプリケーションに承認 (リソース所有者に代わって特定の権限で保護されたリソースにアクセスするための) を付与するプロセス。The process of a resource owner granting authorization to a client application, to access protected resources under specific permissions, on behalf of the resource owner. クライアントから要求された権限によっては、組織データまたは個人データへのアクセスを許可することへの同意が管理者 (組織データの場合) またはユーザー (個人データの場合) に求められます。Depending on the permissions requested by the client, an administrator or user will be asked for consent to allow access to their organization/individual data respectively. さらに、マルチテナントのシナリオでは、同意するユーザーのテナントにアプリケーションのサービス プリンシパルが記録されます。Note, in a multi-tenant scenario, the application's service principal is also recorded in the tenant of the consenting user.

ID トークンID token

承認サーバー承認エンドポイントから提供される OpenID Connect セキュリティ トークン。このトークンには、エンド ユーザーのリソース所有者の認証に関連した要求が格納されます。An OpenID Connect security token provided by an authorization server's authorization endpoint, which contains claims pertaining to the authentication of an end user resource owner. ID トークンもアクセス トークンと同様、デジタル署名された JSON Web トークン (JWT) として表現されます。Like an access token, ID tokens are also represented as a digitally signed JSON Web Token (JWT). ただし、アクセス トークンとは異なり、ID トークンの要求は、リソース アクセス (特にアクセス制御) に関連した目的には使用されません。Unlike an access token though, an ID token's claims are not used for purposes related to resource access and specifically access control.

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

マルチテナント アプリケーションmulti-tenant application

クライアントが登録されたテナントに限らず、任意の Azure AD テナントにプロビジョニングされたユーザーによるサインインと同意を有効にするアプリケーションのクラス。A class of application that enables sign in and consent by users provisioned in any Azure AD tenant, including tenants other than the one where the client is registered. ネイティブ クライアント アプリケーションは、既定ではマルチテナントとなります。これに対し、Web クライアントWeb リソース/API アプリケーションは、シングル テナントまたはマルチテナントを選択できるようになっています。Native client applications are multi-tenant by default, whereas web client and web resource/API applications have the ability to select between single or multi-tenant. 一方シングル テナントとして登録される Web アプリケーションの場合は、アプリケーションの登録先と同じテナントにプロビジョニングされたユーザー アカウントからのみサインインが許可されます。By contrast, a web application registered as single-tenant, would only allow sign-ins from user accounts provisioned in the same tenant as the one where the application is registered.

詳細については、「マルチテナント アプリケーション パターンを使用してすべての Azure Active Directory (AD) ユーザーがサインインできるようにする方法」を参照してください。See How to sign in any Azure AD user using the multi-tenant application pattern for more details.

ネイティブ クライアントnative client

デバイス上にネイティブでインストールされるタイプの クライアント アプリケーションA type of client application that is installed natively on a device. すべてのコードがデバイス上で実行され、機密性を保った状態でプライベートに資格情報を保存することができないため、"public" クライアントと見なされます。Since all code is executed on a device, it is considered a "public" client due to its inability to store credentials privately/confidentially. 詳細については、OAuth2 のクライアント タイプとプロファイルに関するページを参照してください。See OAuth2 client types and profiles for more details.

アクセス許可permissions

クライアント アプリケーションは、アクセス許可要求を宣言することでリソース サーバーへのアクセス権を取得します。A client application gains access to a resource server by declaring permission requests. 次の 2 種類があります。Two types are available:

  • "委任" されたアクセス許可。サインインしたリソース所有者から委任された承認を使用して、スコープに基づくアクセス権を指定します。実行時には、クライアントのアクセス トークン"scp" 要求としてリソースに提示されます。"Delegated" permissions, which specify scope-based access using delegated authorization from the signed-in resource owner, are presented to the resource at run-time as "scp" claims in the client's access token.
  • "アプリケーション" のアクセス許可。クライアント アプリケーションの資格情報/ID を使用してロールベースのアクセス権を指定します。実行時には、クライアントのアクセス トークンの "roles" 要求としてリソースに提示されます。"Application" permissions, which specify role-based access using the client application's credentials/identity, are presented to the resource at run-time as "roles" claims in the client's access token.

これらの要求は 同意 プロセス時にも出現し、管理者またはリソース所有者には、そのテナント内のリソースに対するクライアント アクセスを許可/拒否する機会が与えられます。They also surface during the consent process, giving the administrator or resource owner the opportunity to grant/deny the client access to resources in their tenant.

アクセス許可要求の構成は、Azure Portal の [アプリケーション] タブまたは [設定] タブにある [必要なアクセス許可] で、必要な "委任されたアクセス許可" と "アプリケーションのアクセス許可" (後者には全体管理者ロールのメンバーシップが必要) を選択することによって行います。Permission requests are configured on the "Applications" / "Settings" tab in the Azure portal, under "Required Permissions", by selecting the desired "Delegated Permissions" and "Application Permissions" (the latter requires membership in the Global Admin role). public クライアントは、資格情報を安全に維持できないため、要求できるのは委任されたアクセス許可のみです。一方 confidential クライアントは、委任されたアクセス許可とアプリケーションのアクセス許可のどちらでも要求することができます。Because a public client can't securely maintain credentials, it can only request delegated permissions, while a confidential client has the ability to request both delegated and application permissions. クライアントのアプリケーション オブジェクトは、宣言された権限をその requiredResourceAccess プロパティに格納します。The client's application object stores the declared permissions in its requiredResourceAccess property.

リソース所有者resource owner

OAuth2 Authorization Framework の定義によれば、保護されたリソースへのアクセス権を付与することのできるエンティティをいいます。As defined by the OAuth2 Authorization Framework, an entity capable of granting access to a protected resource. リソース所有者が人である場合は、"エンド ユーザー" と呼ばれます。When the resource owner is a person, it is referred to as an end user. たとえばクライアント アプリケーションは、Microsoft Graph API を介してユーザーのメールボックスにアクセスする必要があるとき、そのメールボックスのリソース所有者に権限を要求する必要があります。For example, when a client application wants to access a user's mailbox through the Microsoft Graph API, it requires permission from the resource owner of the mailbox.

リソース サーバーresource server

OAuth2 Authorization Framework の定義によれば、保護されたリソースのホストとして、アクセス トークンを提示するクライアント アプリケーションからのリソース要求 (保護されたリソースに対する要求) を受理し、応答する機能を備えたサーバーをいいます。As defined by the OAuth2 Authorization Framework, a server that hosts protected resources, capable of accepting and responding to protected resource requests by client applications that present an access token. 保護されたリソース サーバーまたはリソース アプリケーションと呼ばれることもあります。Also known as a protected resource server, or resource application.

リソース サーバーは API を公開しており、そこで保護されているリソースに対しては、OAuth 2.0 Authorization Framework を使用して、スコープロールを介したアクセスが強制的に適用されます。A resource server exposes APIs and enforces access to its protected resources through scopes and roles, using the OAuth 2.0 Authorization Framework. たとえば、Azure AD テナント データへのアクセスを提供する Azure AD Graph API や、メール、カレンダーなどのデータへのアクセスを提供する Office 365 API があります。Examples include the Azure AD Graph API which provides access to Azure AD tenant data, and the Office 365 APIs that provide access to data such as mail and calendar. これらの API はどちらも Microsoft Graph API から利用することができます。Both of these are also accessible via the Microsoft Graph API.

リソース アプリケーションの ID 構成は、クライアント アプリケーションと同様、Azure AD テナントへの 登録 を通じて確立され、アプリケーション オブジェクトとサービス プリンシパル オブジェクトの両方が得られます。Just like a client application, resource application's identity configuration is established via registration in an Azure AD tenant, providing both the application and service principal object. Azure AD Graph API など、Microsoft が提供している一部の API には、あらかじめ登録されているサービス プリンシパルが存在し、プロビジョニング時にすべてのテナントで利用できるようになっています。Some Microsoft-provided APIs, such as the Azure AD Graph API, have pre-registered service principals made available in all tenants during provisioning.

rolesroles

ロールは、スコープと同様、リソース サーバーの保護されたリソースへのアクセスを管理するための手段です。Like scopes, roles provide a way for a resource server to govern access to its protected resources. ロールには、"ユーザー" ロールと "アプリケーション" ロールの 2 種類があります。ユーザー ロールでは、リソースへのアクセスを必要とするユーザー/グループに関してロールベースのアクセス制御を実装します。これに対してアプリケーション ロールで実装するのは、アクセスを要求するクライアント アプリケーションの場合と同じです。There are two types: a "user" role implements role-based access control for users/groups that require access to the resource, while an "application" role implements the same for client applications that require access.

ロールは、リソースによって定義される文字列 ("経費承認者"、"読み取り専用"、"Directory.ReadWrite.All" など) です。Azure Portal からリソースのアプリケーション マニフェストを介して管理され、リソースの appRoles プロパティに格納されます。Roles are resource-defined strings (for example "Expense approver", "Read-only", "Directory.ReadWrite.All"), managed in the Azure portal via the resource's application manifest, and stored in the resource's appRoles property. Azure Portal は、ユーザーを "ユーザー" ロールに割り当てたり、"アプリケーション" ロールに対するクライアント アプリケーションのアクセス許可を構成したりするためにも使用します。The Azure portal is also used to assign users to "user" roles, and configure client application permissions to access an "application" role.

Azure AD の Graph API によって公開されているアプリケーション ロールの詳しい説明については、Graph API のアクセス許可スコープに関するページを参照してください。For a detailed discussion of the application roles exposed by Azure AD's Graph API, see Graph API Permission Scopes. 具体的な実装例については、「Role based access control in cloud applications using Azure AD」(Azure AD を使用したクラウド アプリケーションでのロール ベースのアクセス制御) を参照してください。For a step-by-step implementation example, see Role based access control in cloud applications using Azure AD.

スコープscopes

スコープは、ロールと同様、リソース サーバーの保護されたリソースへのアクセスを管理するための手段です。Like roles, scopes provide a way for a resource server to govern access to its protected resources. リソースへの委任されたアクセス権を所有者から付与されているクライアント アプリケーションに対し、スコープベースのアクセス制御を実装する目的で使用されます。Scopes are used to implement scope-based access control, for a client application that has been given delegated access to the resource by its owner.

スコープは、リソースによって定義される文字列 ("Mail.Read"、"Directory.ReadWrite.All" など) です。Azure Portal からリソースのアプリケーション マニフェストを介して管理され、リソースの oauth2Permissions プロパティに格納されます。Scopes are resource-defined strings (for example "Mail.Read", "Directory.ReadWrite.All"), managed in the Azure portal via the resource's application manifest, and stored in the resource's oauth2Permissions property. Azure Portal は、クライアント アプリケーションの、スコープに対する委任されたアクセス許可を構成するためにも使用します。The Azure portal is also used to configure client application delegated permissions to access a scope.

推奨される名前付け規則は、"resource.operation.constraint" 形式です。A best practice naming convention, is to use a "resource.operation.constraint" format. Azure AD の Graph API によって公開されているスコープの詳しい説明については、Graph API のアクセス許可スコープに関するページを参照してください。For a detailed discussion of the scopes exposed by Azure AD's Graph API, see Graph API Permission Scopes. Office 365 サービスによって公開されているスコープについては、Office 365 API アクセス許可に関するリファレンスを参照してください。For scopes exposed by Office 365 services, see Office 365 API permissions reference.

セキュリティ トークンsecurity token

要求を含んだ署名付きのドキュメント (OAuth2 トークン、SAML 2.0 アサーションなど)。A signed document containing claims, such as an OAuth2 token or SAML 2.0 assertion. OAuth2 承認付与の場合、アクセス トークン (OAuth2) と ID トークンがセキュリティ トークンの種類になります。どちらも JSON Web トークン (JWT) として実装されます。For an OAuth2 authorization grant, an access token (OAuth2) and an ID Token are types of security tokens, both of which are implemented as a JSON Web Token (JWT).

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

Azure Portal でアプリケーションを登録/更新すると、そのテナントを対象に、アプリケーション オブジェクトおよび対応するサービス プリンシパル オブジェクトの両方が作成/更新されます。When you register/update an application in the Azure portal, the portal creates/updates both an application object and a corresponding service principal object for that tenant. アプリケーション オブジェクトは、アプリケーションの ID 構成をグローバルに (関連するアプリケーションがアクセスできるすべてのテナントに対して) "定義" します。このオブジェクトをテンプレートとして、対応するサービス プリンシパル オブジェクトが "生成" され、実行時にローカル (特定のテナント) で使用されます。The application object defines the application's identity configuration globally (across all tenants where the associated application has been granted access), and is the template from which its corresponding service principal object(s) are derived for use locally at run-time (in a specific tenant).

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

サインインsign-in

クライアント アプリケーションがエンド ユーザーの認証を開始し、関連する状態を収集するプロセス。セキュリティ トークンを取得すると共に、アプリケーションのセッションをその状態に限定することを目的としています。The process of a client application initiating end user authentication and capturing related state, for the purpose of acquiring a security token and scoping the application session to that state. 状態には、ユーザー プロファイル情報などのアーティファクトや、トークンの要求から生成される情報が含まれている場合があります。State can include artifacts such as user profile information, and information derived from token claims.

アプリケーションのサインイン機能は通常、シングル サインオン (SSO) を実装するために使用されます。The sign-in function of an application is typically used to implement single-sign-on (SSO). また、この機能は、エンド ユーザーが (初回サインイン時に) アプリケーションにアクセスするためのエントリ ポイントとして "サインアップ" 機能の前に実行されることがあります。It may also be preceded by a "sign-up" function, as the entry point for an end user to gain access to an application (upon first sign-in). サインアップ機能は、ユーザーごとの特別な状態を収集して永続化するために使用され、 ユーザーの同意を必要とする場合があります。The sign-up function is used to gather and persist additional state specific to the user, and may require user consent.

サインアウトsign-out

エンド ユーザーの認証を取り消し、サインインの過程でクライアント アプリケーションのセッションに関連付けられたユーザーの状態を解除するプロセス。The process of un-authenticating an end user, detaching the user state associated with the client application session during sign-in

テナントtenant

Azure AD ディレクトリのインスタンスを "Azure AD テナント" といいます。An instance of an Azure AD directory is referred to as an Azure AD tenant. 次のような機能が用意されています。It provides several features, including:

Azure AD テナントはサインアップ時に作成され、Azure サブスクリプションおよび Office 365 サブスクリプションに関連付けられます。これにより、そのサブスクリプションの ID およびアクセス管理機能が提供されます。Azure AD tenants are created/associated with Azure and Office 365 subscriptions during sign-up, providing Identity & Access Management features for the subscription. Azure サブスクリプション管理者は、Azure Portal を使用して追加の Azure AD テナントを作成することもできます。Azure subscription administrators can also create additional Azure AD tenants via the Azure portal. テナントを利用するための各種方法について詳しくは、「Azure Active Directory テナントを取得する方法」をご覧ください。See How to get an Azure Active Directory tenant for details on the various ways you can get access to a tenant. サブスクリプションと Azure AD テナントの関係について詳しくは、「Azure サブスクリプションを Azure Active Directory に関連付ける方法」をご覧ください。See How Azure subscriptions are associated with Azure Active Directory for details on the relationship between subscriptions and an Azure AD tenant.

トークン エンドポイントtoken endpoint

承認サーバーによって実装されるエンドポイントの 1 つ。OAuth2 承認付与をサポートするために使用されます。One of the endpoints implemented by the authorization server to support OAuth2 authorization grants. 付与された承認によっては、クライアントへのアクセス トークン (と関連する "更新" トークン) を取得したり、OpenID Connect プロトコルと共に使用する場合に ID トークンを取得したりできます。Depending on the grant, it can be used to acquire an access token (and related "refresh" token) to a client, or ID token when used with the OpenID Connect protocol.

ユーザー エージェント ベースのクライアントUser-agent-based client

Web サーバーからコードをダウンロードしてユーザー エージェント (Web ブラウザーなど) 内で実行するクライアント アプリケーションの一種。その例としてシングル ページ アプリケーション (SPA) が挙げられます。A type of client application that downloads code from a web server and executes within a user-agent (for instance, a web browser), such as a Single Page Application (SPA). すべてのコードがデバイス上で実行され、機密性を保った状態でプライベートに資格情報を保存することができないため、"public" クライアントと見なされます。Since all code is executed on a device, it is considered a "public" client due to its inability to store credentials privately/confidentially. 詳細については、OAuth2 のクライアント タイプとプロファイルに関するページを参照してください。See OAuth2 client types and profiles for more details.

ユーザー プリンシパルuser principal

サービス プリンシパル オブジェクトはアプリケーション インスタンスを表現するためのセキュリティ プリンシパルです。一方、ユーザー プリンシパル オブジェクトも、セキュリティ プリンシパルのひとつですが、表現の対象となるのはユーザーです。Similar to the way a service principal object is used to represent an application instance, a user principal object is another type of security principal, which represents a user. ユーザー オブジェクトのスキーマは、Azure AD Graph のユーザー エンティティによって定義されます (姓や名をはじめとするユーザー関連のプロパティ、ユーザー プリンシパル名、ディレクトリ ロール メンバーシップなど)。これにより、実行時にユーザー プリンシパルを設定するための Azure AD のユーザー ID 構成が提供されます。The Azure AD Graph User entity defines the schema for a user object, including user-related properties such as first and last name, user principal name, directory role membership, etc. This provides the user identity configuration for Azure AD to establish a user principal at run-time. ユーザー プリンシパルは、シングル サインオン、同意の委任の記録、アクセス制御の意思決定などの際に、認証済みのユーザーを表す目的で使用されます。The user principal is used to represent an authenticated user for Single Sign-On, recording consent delegation, making access control decisions, etc.

Web クライアントweb client

Web サーバーですべてのコードを実行するクライアント アプリケーションの一種。資格情報をサーバー上に安全に保存することで、"confidential" クライアントとして動作することができます。A type of client application that executes all code on a web server, and able to function as a "confidential" client by securely storing its credentials on the server. 詳細については、OAuth2 のクライアント タイプとプロファイルに関するページを参照してください。See OAuth2 client types and profiles for more details.

次のステップNext steps

Azure Active Directory 開発者ガイド」をお読みください。Azure AD とアプリケーションの統合や、Azure AD 認証の基礎、サポートされる認証シナリオなど、Azure AD 開発に関連したあらゆるトピックへの入口となっています。The Azure AD Developer's Guide is the portal to use for all Azure AD development related topics, including an overview of application integration and the basics of Azure AD authentication and supported authentication scenarios.

Microsoft のコンテンツ改善のため、以下のコメント セクションよりご意見をお寄せください。新しい定義に関するリクエストのほか、既存の定義の更新のリクエストもお待ちしております。Please use the following comments section to provide feedback and help us refine and shape our content, including requests for new definitions or updating existing ones!