Microsoft ID プラットフォーム (v2.0) に更新する理由Why update to Microsoft identity platform (v2.0)?

新しいアプリケーションを開発する場合、Microsoft ID プラットフォーム (v2.0) エンドポイントと Azure Active Directory (v1.0) エンドポイントの相違点を把握しておくことが重要です。When developing a new application, it's important to know the differences between the Microsoft identity platform (v2.0) and Azure Active Directory (v1.0) endpoints. この記事では、各エンドポイントの主な相違点と、Microsoft ID プラットフォームに関する既存の制限について説明します。This article covers the main differences between the endpoints and some existing limitations for Microsoft identity platform.

注意

Microsoft ID プラットフォームのエンドポイントでは、すべての Azure AD シナリオや機能をサポートしているわけではありません。The Microsoft identity platform endpoint doesn't support all Azure AD scenarios and features. Microsoft ID プラットフォームのエンドポイントを使用する必要があるかどうかを判断するには、MicrosoftID プラットフォームの制限事項に関する記事を参照してください。To determine if you should use the Microsoft identity platform endpoint, read about Microsoft identity platform limitations.

サインインできるユーザーWho can sign in

v1.0 エンドポイントと v2.0 エンドポイントでサインインできるユーザー

  • v1.0 エンドポイントでは、職場と学校のアカウント (Azure AD) でのみ、ご利用のアプリケーションにサインインすることができます。The v1.0 endpoint allows only work and school accounts to sign in to your application (Azure AD)
  • Microsoft ID プラットフォーム エンドポイントでは、Azure AD からの職場と学校のアカウント、および個人の Microsoft アカウント (MSA) (hotmail.com、outlook.com、msn.com など) でサインインできます。The Microsoft identity platform endpoint allows work and school accounts from Azure AD and personal Microsoft accounts (MSA), such as hotmail.com, outlook.com, and msn.com, to sign in.
  • 両方のエンドポイントで、 シングルテナント として構成されているアプリケーション、またはテナント固有のエンドポイント (https://login.microsoftonline.com/{TenantId_or_Name}) を指すように構成されているマルチテナント アプリケーションに対する Azure AD ディレクトリの ゲスト ユーザー によるサインインも受け入れられます。Both endpoints also accept sign-ins of guest users of an Azure AD directory for applications configured as single-tenant or for multi-tenant applications configured to point to the tenant-specific endpoint (https://login.microsoftonline.com/{TenantId_or_Name}).

Microsoft ID プラットフォーム エンドポイントを使用した場合は、個人の Microsoft アカウントに加え、職場や学校のアカウントからのサインインを受け付けるアプリを記述することができます。The Microsoft identity platform endpoint allows you to write apps that accept sign-ins from personal Microsoft accounts, and work and school accounts. そのため、完全にアカウント非依存のアプリを作成することができます。This gives you the ability to write your app completely account-agnostic. たとえば、アプリで Microsoft Graph を呼び出す場合、SharePoint サイトやディレクトリ データなど、いくつかの追加の機能とデータを職場のアカウントで使用できます。For example, if your app calls the Microsoft Graph, some additional functionality and data will be available to work accounts, such as their SharePoint sites or directory data. しかし、ユーザーのメールの読み取りなど、多くのアクションでは、同じコードで個人アカウントおよび職場と学校のアカウントの両方のメールにアクセスすることができます。But for many actions, such as Reading a user's mail, the same code can access the email for both personal and work and school accounts.

Microsoft ID プラットフォーム エンドポイントの場合、Microsoft Authentication Library (MSAL) を使用して、コンシューマー向け、教育向け、エンタープライズ向けのいずれの環境にもアクセスできます。For Microsoft identity platform endpoint, you can use the Microsoft Authentication Library (MSAL) to gain access to the consumer, educational, and enterprise worlds. Azure AD v1.0 エンドポイントでは、職場と学校のアカウントのみからのサインインが受け入れられます。The Azure AD v1.0 endpoint accepts sign-ins from work and school accounts only.

必要な OAuth 2.0 アクセス許可を事前に指定するには、Azure AD v1.0 エンドポイントを使用するアプリが必要になります。その例を以下に示します。Apps using the Azure AD v1.0 endpoint are required to specify their required OAuth 2.0 permissions in advance, for example:

アクセス許可の登録 UI を示す例

アプリケーションの登録時に直接設定されるアクセス許可は静的となります。The permissions set directly on the application registration are static. アプリの静的アクセス許可は Azure portal で定義されており、コードを適切に維持できますが、開発者にとってはそれがいくつかの問題を引き起こす場合があります。While static permissions of the app defined in the Azure portal keep the code nice and simple, it presents some possible issues for developers:

  • アプリで、ユーザーの初回サインインの時点で必要になる可能性があるすべてのアクセス許可を要求する必要があります。The app needs to request all the permissions it would ever need upon the user's first sign-in. アクセス許可のリストは長くなる場合があり、エンドユーザーが初回サインイン時にアプリのアクセスを承認することを阻げる要因となります。This can lead to a long list of permissions that discourages end users from approving the app's access on initial sign-in.

  • アプリでアクセスする可能性のあるすべてのリソースが事前にわかっている必要があります。The app needs to know all of the resources it would ever access ahead of time. 任意の数のリソースにアクセスするアプリを作成することは、困難でした。It was difficult to create apps that could access an arbitrary number of resources.

Microsoft ID プラットフォーム エンドポイントでは、Azure portal のアプリ登録情報で定義された静的アクセス許可を無視し、代わりにアクセス許可を追加的に要求することができます。つまり、最初は最小限の権限セットを要求し、その後、お客様が使用する追加のアプリ機能に応じて要求を追加することができます。With the Microsoft identity platform endpoint, you can ignore the static permissions defined in the app registration information in the Azure portal and request permissions incrementally instead, which means asking for a bare minimum set of permissions upfront and growing more over time as the customer uses additional app features. これを行うために、任意の時点でアプリに必要なスコープを指定できます。その場合、アクセス トークンの要求時に scope パラメーターに新しいスコープを含めます。アプリケーションの登録情報で事前に定義する必要はありません。To do so, you can specify the scopes your app needs at any time by including the new scopes in the scope parameter when requesting an access token - without the need to pre-define them in the application registration information. 要求に追加された新しいスコープにユーザーがまだ同意していない場合、新しいアクセス許可のみの同意を求められます。If the user hasn't yet consented to new scopes added to the request, they'll be prompted to consent only to the new permissions. 詳細については、アクセス許可、同意、スコープの説明を参照してください。To learn more, see permissions, consent, and scopes.

scope パラメーターを使用してアプリからアクセス許可を動的に要求できるため、開発者はユーザーの操作を完全に制御できます。Allowing an app to request permissions dynamically through the scope parameter gives developers full control over your user's experience. 同意操作を初期段階に組み込み、1 回の初期承認要求ですべてのアクセス許可を求めることもできます。You can also front load your consent experience and ask for all permissions in one initial authorization request. アプリで多数のアクセス許可が必要な場合は、時間の経過と共に、ユーザーがアプリの特定の機能を使用するときにアクセス許可を集めることができます。If your app requires a large number of permissions, you can gather those permissions from the user incrementally as they try to use certain features of the app over time.

組織に代わって行われる管理者の同意では、引き続き、アプリ用に登録された静的アクセス許可が要求されるため、組織全体に代わり、管理者が同意する必要がある場合は、アプリ登録ポータル内のアプリに対してこれらのアクセス許可を設定するようにしてください。Admin consent done on behalf of an organization still requires the static permissions registered for the app, so you should set those permissions for apps in the app registration portal if you need an admin to give consent on behalf of the entire organization. これにより、アプリケーションを設定するために組織の管理者に必要なサイクルが減ります。This reduces the cycles required by the organization admin to set up the application.

リソースではなくスコープScopes, not resources

v1.0 エンドポイントを使用するアプリの場合、アプリは、リソース、またはトークンの受信者として動作できます。For apps using the v1.0 endpoint, an app can behave as a resource, or a recipient of tokens. リソースには、リソースで識別できる多数のスコープまたは oAuth2Permissions を定義できます。それによりクライアント アプリは、そのリソースから特定のスコープのセットのトークンを要求できます。A resource can define a number of scopes or oAuth2Permissions that it understands, allowing client apps to request tokens from that resource for a certain set of scopes. リソースの例として、Azure AD Graph API があります。Consider the Azure AD Graph API as an example of a resource:

  • リソース識別子、または AppID URI: https://graph.windows.net/Resource identifier, or AppID URI: https://graph.windows.net/
  • スコープ、または oAuth2Permissions: Directory.ReadDirectory.Write など。Scopes, or oAuth2Permissions: Directory.Read, Directory.Write, and so on.

これは、Microsoft ID プラットフォーム エンドポイントの場合に該当します。This holds true for the Microsoft identity platform endpoint. アプリはリソースとして動作し、スコープを定義することができ、URI によって識別できます。An app can still behave as a resource, define scopes, and be identified by a URI. また、クライアント アプリは、スコープへのアクセスを要求できます。Client apps can still request access to those scopes. ただし、クライアントがそれらのアクセス許可を要求する方法が変更されました。However, the way that a client requests those permissions have changed.

v1.0 エンドポイントでは、Azure AD への OAuth 2.0 承認要求は、次のようになっていました。For the v1.0 endpoint, an OAuth 2.0 authorize request to Azure AD might have looked like:

GET https://login.microsoftonline.com/common/oauth2/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&resource=https://graph.windows.net/
...

ここで、resource パラメーターは、クライアント アプリが認証を求めている対象のリソースを示します。Here, the resource parameter indicated which resource the client app is requesting authorization. Azure AD は、Azure Portal での静的な構成に基づいて、アプリによって要求されたアクセス許可を計算し、適切なトークンを発行していました。Azure AD computed the permissions required by the app based on static configuration in the Azure portal, and issued tokens accordingly.

Microsoft ID プラットフォーム エンドポイントを使用するアプリケーションでは、同じ OAuth 2.0 承認要求が次のようになります。For applications using the Microsoft identity platform endpoint, the same OAuth 2.0 authorize request looks like:

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&scope=https://graph.windows.net/directory.read%20https://graph.windows.net/directory.write
...

ここで、scope パラメーターは、アプリで承認を要求している対象のリソースとアクセス許可を示します。Here, the scope parameter indicates which resource and permissions the app is requesting authorization. 要求されているリソースはまだ要求内に存在していて、scope パラメーターの各値の中に含まれています。The desired resource is still present in the request - it's encompassed in each of the values of the scope parameter. このように scope パラメーターを使用すると、Microsoft ID プラットフォーム エンドポイントの OAuth 2.0 仕様への準拠を高め、一般的な業界の慣行に近づけることができます。Using the scope parameter in this manner allows the Microsoft identity platform endpoint to be more compliant with the OAuth 2.0 specification, and aligns more closely with common industry practices. また、アプリで増分同意を行うこともできます。つまり、アプリケーションで最初の要求以外のアクセス許可が必要な場合にのみ、それらのアクセス許可を要求することもできます。It also enables apps to do incremental consent - only requesting permissions when the application requires them as opposed to up front.

既知のスコープWell-known scopes

オフライン アクセスOffline access

Microsoft ID プラットフォーム エンドポイントを使用するアプリでは、アプリ向けで既知の新たなアクセス許可 (offline_access スコープ) を使用する必要がある場合があります。Apps using the Microsoft identity platform endpoint may require the use of a new well-known permission for apps - the offline_access scope. すべてのアプリは、ユーザーがアプリを積極的に利用しない可能性がある場合でも、長期間ユーザーに代わってリソースにアクセスするために必要な、このアクセス許可を要求する必要があります。All apps will need to request this permission if they need to access resources on the behalf of a user for a prolonged period of time, even when the user may not be actively using the app. offline_access スコープは、同意ダイアログで "いつでもデータにアクセスできます" と表示され、ユーザーはこれに同意する必要があります。The offline_access scope will appear to the user in consent dialogs as Access your data anytime, which the user must agree to. offline_access アクセス許可を要求すると、Web アプリで Microsoft ID プラットフォーム エンドポイントから OAuth 2.0 の refresh_tokens を受け取ることができます。Requesting the offline_access permission will enable your web app to receive OAuth 2.0 refresh_tokens from the Microsoft identity platform endpoint. 更新トークンは長期間維持され、アクセスの期間を延長するために新しい OAuth 2.0 のアクセス トークンと交換することができます。Refresh tokens are long-lived, and can be exchanged for new OAuth 2.0 access tokens for extended periods of access.

アプリが offline_access スコープを要求しない場合、更新トークンを受け取ることはありません。If your app doesn't request the offline_access scope, it won't receive refresh tokens. つまり、OAuth 2.0 承認コード フローの承認コードを使用すると、/token エンドポイントからのアクセス トークンのみを受け取ることになります。This means that when you redeem an authorization code in the OAuth 2.0 authorization code flow, you'll only receive back an access token from the /token endpoint. そのアクセス トークンは短時間 (通常は 1 時間) 有効ですが、最終的には期限が切れます。That access token remains valid for a short period of time (typically one hour), but will eventually expire. その時点で、アプリでユーザーを /authorize エンドポイントにリダイレクトし、新しい承認コードを取得する必要があります。At that point in time, your app will need to redirect the user back to the /authorize endpoint to retrieve a new authorization code. このリダイレクト中に、アプリの種類によっては、ユーザーが資格情報を再入力したり、アクセス許可に再同意したりする必要がある場合もあります。During this redirect, the user may or may not need to enter their credentials again or reconsent to permissions, depending on the type of app.

OAuth 2.0、refresh_tokens、および access_tokens の詳細については、Microsoft ID プラットフォーム プロトコルのリファレンスを参照してください。To learn more about OAuth 2.0, refresh_tokens, and access_tokens, check out the Microsoft identity platform protocol reference.

OpenID、プロファイル、および電子メールOpenID, profile, and email

これまでは、Microsoft ID プラットフォームを使用する最も基本的な OpenID 接続サインイン フローによって、結果の id_token 内でユーザーに関する多くの情報が提供されていました。Historically, the most basic OpenID Connect sign-in flow with Microsoft identity platform would provide a lot of information about the user in the resulting id_token. id_token 内の要求には、ユーザー名、推奨ユーザー名、電子メール アドレス、オブジェクト ID などを含めることができます。The claims in an id_token can include the user's name, preferred username, email address, object ID, and more.

アプリが openid のスコープでアクセスできる情報は、現在では制限されています。The information that the openid scope affords your app access to is now restricted. openid スコープでアプリに許可されるのは、ユーザーのサインインと、ユーザーのためにアプリ固有の ID を受信することだけです。The openid scope will only allow your app to sign in the user and receive an app-specific identifier for the user. アプリでユーザーに関する個人データを取得する場合は、アプリからユーザーに追加のアクセス許可を要求する必要があります。If you want to get personal data about the user in your app, your app needs to request additional permissions from the user. 2 つの新しいスコープである emailprofile を使用すると、追加のアクセス許可を要求できます。Two new scopes, email and profile, will allow you to request additional permissions.

  • email スコープでは、アプリは id_token の email 要求を使用して、ユーザーのプライマリ電子メール アドレスにアクセスできます (アドレス指定可能な電子メール アドレスをユーザーが持っている場合)。The email scope allows your app access to the user’s primary email address through the email claim in the id_token, assuming the user has an addressable email address.
  • profile スコープでは、id_token 内の名前、推奨ユーザー名、オブジェクト ID など、ユーザーに関するその他のすべての基本的な情報へのアクセスをアプリに許可します。The profile scope affords your app access to all other basic information about the user, such as their name, preferred username, object ID, and so on, in the id_token.

これらのスコープにより、情報の公開を最小限にとどめる方法でアプリを記述し、アプリがジョブを実行するために必要な情報セットのみをユーザーに要求することができます。These scopes allow you to code your app in a minimal-disclosure fashion so you can only ask the user for the set of information that your app needs to do its job. これらのスコープの詳細については、Microsoft ID プラットフォーム スコープのリファレンスを参照してください。For more information on these scopes, see the Microsoft identity platform scope reference.

トークン要求Token claims

Microsoft ID プラットフォーム エンドポイントでは、ペイロードを小さくするため、トークン内の一部の要求のみが既定で発行されます。The Microsoft identity platform endpoint issues a smaller set of claims in its tokens by default to keep payloads small. Microsoft ID プラットフォーム トークンの既定では提供されない v1.0 トークン内の特定の要求に依存するアプリやサービスがある場合は、省略可能な要求の機能を使用してそのクレームを含めることを検討してください。If you have apps and services that have a dependency on a particular claim in a v1.0 token that is no longer provided by default in a Microsoft identity platform token, consider using the optional claims feature to include that claim.

重要

v1.0 および v2.0 のトークンは、v1.0 と v2.0 のどちらのエンドポイントからでも発行できます。v1.0 and v2.0 tokens can be issued by both the v1.0 and v2.0 endpoints! id_tokens は "必ず" その要求元のエンドポイントと一致し、アクセス トークンは "必ず"、そのトークンを使用してクライアントが呼び出す Web API で想定された形式と一致します。id_tokens always match the endpoint they're requested from, and access tokens always match the format expected by the Web API your client will call using that token. そのため、アプリで v2.0 エンドポイントを使用して、Microsoft Graph を呼び出すためのトークンを取得する場合、そこで想定されるのは v1.0 形式のアクセス トークンなので、アプリには v1.0 形式でトークンが返されます。So if your app uses the v2.0 endpoiont to get a token to call Microsoft Graph, which expects v1.0 format access tokens, your app will recieve a token in the v1.0 format.

制限事項Limitations

Microsoft ID プラットフォーム を使用する場合に注意する必要があるいくつかの制限があります。There are a few restrictions to be aware of when using Microsoft identity platform.

Microsoft ID プラットフォームと統合するアプリケーションを構築する場合は、Microsoft ID プラットフォーム エンドポイントと認証プロトコルがニーズを満たすかどうかを判断する必要があります。When you build applications that integrate with the Microsoft identity platform, you need to decide whether the Microsoft identity platform endpoint and authentication protocols meet your needs. v1.0 エンドポイントとプラットフォームは引き続き完全にサポートされ、いくつかの点では Microsoft ID プラットフォームよりも機能が豊富です。The v1.0 endpoint and platform is still fully supported and, in some respects, is more feature rich than Microsoft identity platform. ただし、Microsoft ID プラットフォームは、開発者に大きなメリットを提供します。However, Microsoft identity platform introduces significant benefits for developers.

現在の開発者向けの推奨は、下記のようにシンプルです。Here's a simplified recommendation for developers now:

  • アプリケーションで個人の Microsoft アカウントをサポートする必要がある場合や、新しいアプリケーションを作成する場合は、Microsoft ID プラットフォームを使用してください。If you want or need to support personal Microsoft accounts in your application, or you're writing a new application, use Microsoft identity platform. ただしその準備として、この記事で説明する制限事項を必ず理解してください。But before you do, make sure you understand the limitations discussed in this article.
  • SAML に依存するアプリケーションを移行または更新する場合には、Microsoft ID プラットフォームを使用することはできません。If you're migrating or updating an application that relies on SAML, you can't use Microsoft identity platform. 代わりに、Azure AD 1.0 ガイドに関するページを参照してください。Instead, refer to the Azure AD v1.0 guide.

Microsoft ID プラットフォーム エンドポイントはこの一覧に記載された制限事項をなくすように進化するため、Microsoft ID プラットフォーム エンドポイントのみを使用すればよくなる予定です。The Microsoft identity platform endpoint will evolve to eliminate the restrictions listed here, so that you'll only ever need to use the Microsoft identity platform endpoint. 当面は、この記事を参照して、Microsoft ID プラットフォーム エンドポイントがニーズを満たしているかどうかを判断してください。In the meantime, use this article to determine whether the Microsoft identity platform endpoint is right for you. Microsoft ID プラットフォーム エンドポイントの現在の状態を反映するように、この記事を引き続き更新する予定です。We'll continue to update this article to reflect the current state of the Microsoft identity platform endpoint. Microsoft ID プラットフォームの機能に対して、要件を再確認してください。Check back to reevaluate your requirements against Microsoft identity platform capabilities.

アプリの登録に関する制限事項Restrictions on app registrations

Microsoft ID プラットフォーム エンドポイントと統合するアプリごとに、Azure portal の新しいアプリ登録エクスペリエンスでアプリの登録を作成することができます。For each app that you want to integrate with the Microsoft identity platform endpoint, you can create an app registration in the new App registrations experience in the Azure portal. 既存の Microsoft アカウント アプリはポータルとの互換性がありませんが、Azure AD アプリはすべて、登録された日時や場所に関係なく互換性があります。Existing Microsoft account apps aren't compatible with the portal, but all Azure AD apps are, regardless of where or when they were registered.

職場や学校のアカウントと個人用アカウントをサポートするアプリの登録については、次の注意事項があります。App registrations that support work and school accounts and personal accounts have the following caveats:

  • アプリケーション ID ごとに許可されるアプリ シークレットは 2 種類のみです。Only two app secrets are allowed per application ID.
  • テナントに登録されなかったアプリケーションは、それを登録したアカウントによってのみ管理できます。An application that wasn't registered in a tenant can only be managed by the account that registered it. これは他の開発者とは共有できません。It can’t be shared with other developers. アプリ登録ポータルで個人の Microsoft アカウントを使用して登録されたアプリの多くは、これに該当します。This is the case for most apps that were registered using a personal Microsoft account in the App Registration Portal. アプリの登録を複数の開発者と共有したい場合は、Azure portal の新しい [アプリの登録] セクションを使用して、アプリケーションをテナントに登録してください。If you’d like to share your app registration with multiple developers, register the application in a tenant using the new App registrations section of the Azure portal.
  • 許可されるリダイレクト URL の形式には、いくつかの制限事項があります。There are several restrictions on the format of the redirect URL that is allowed. リダイレクト URL の詳細については、次のセクションを参照してください。For more information about redirect URL, see the next section.

リダイレクト URL に関する制限事項Restrictions on redirect URLs

Microsoft ID プラットフォーム用に登録されるアプリは、限られたリダイレクト URL 値に限定されています。Apps that are registered for Microsoft identity platform are restricted to a limited set of redirect URL values. Web アプリおよびサービスのリダイレクト URL はスキーム https で始める必要があり、すべてのリダイレクト URL 値で単一の DNS ドメインを共有する必要があります。The redirect URL for web apps and services must begin with the scheme https, and all redirect URL values must share a single DNS domain. 登録システムによって、既存のリダイレクト URL の DNS 名全体と、追加するリダイレクト URL の DNS 名が比較されます。The registration system compares the whole DNS name of the existing redirect URL to the DNS name of the redirect URL that you're adding. http://localhost はリダイレクト URL としてもサポートされます。http://localhost is also supported as a redirect URL.

次のいずれかの条件に当てはまる場合、DNS 名を追加する要求は失敗します。The request to add the DNS name will fail if either of the following conditions is true:

  • 新しいリダイレクト URL の DNS 名全体が、既存のリダイレクト URL の DNS 名と一致しない。The whole DNS name of the new redirect URL doesn't match the DNS name of the existing redirect URL.
  • 新しいリダイレクト URL の DNS 名全体が、既存のリダイレクト URL のサブドメインではない。The whole DNS name of the new redirect URL isn't a subdomain of the existing redirect URL.

例 1Example 1

アプリに https://login.contoso.com のリダイレクト URL がある場合は、次の例のように、DNS 名が完全に一致するリダイレクト URL を追加することができます。If the app has a redirect URL of https://login.contoso.com, you can add a redirect URL where the DNS name matches exactly, as shown in the following example:

https://login.contoso.com/new

また、次の例のように、login.contoso.com の DNS サブドメインを参照することもできます。Or, you can refer to a DNS subdomain of login.contoso.com, as shown in the following example:

https://new.login.contoso.com

例 2Example 2

リダイレクト URL として login-east.contoso.comlogin-west.contoso.com を含むアプリが必要な場合は、それらのリダイレクト URL を次の順序で追加する必要があります。If you want to have an app that has login-east.contoso.com and login-west.contoso.com as redirect URLs, you must add those redirect URLs in the following order:

https://contoso.com
https://login-east.contoso.com
https://login-west.contoso.com

後の 2 つを追加できるのは、それらが 1 つ目の contoso.com というリダイレクト URL のサブドメインであるためです。You can add the latter two because they're subdomains of the first redirect URL, contoso.com.

特定のアプリケーションに対して使用できる応答 URL は 20 個のみです。この制限は、登録でサポートされるすべての種類のアプリ (シングルページ アプリケーション (SPA)、ネイティブ クライアント、Web アプリ、およびサービス) に適用されます。You can have only 20 reply URLs for a particular application - this limit applies across all app types that the registration supports (single-page application (SPA), native client, web app, and service).

Microsoft ID プラットフォームで使用するアプリを登録する方法については、新しいアプリ登録エクスペリエンスを使用したアプリの登録に関するページを参照してください。To learn how to register an app for use with Microsoft identity platform, see Register an app using the new App registrations experience.

ライブラリと SDK に関する制限事項Restrictions on libraries and SDKs

現時点では、Microsoft ID プラットフォーム エンドポイントのライブラリ サポートは制限されています。Currently, library support for the Microsoft identity platform endpoint is limited. 運用環境のアプリケーションで Microsoft ID プラットフォーム エンドポイントを使用する場合は、次の選択肢があります。If you want to use the Microsoft identity platform endpoint in a production application, you have these options:

  • Web アプリケーションを構築する場合は、一般提供されているサーバー側のミドルウェアを使用して、サインインとトークンの検証を安全に実行できます。If you're building a web application, you can safely use the generally available server-side middleware to do sign-in and token validation. このようなミドルウェアには、OWIN の ASP.NET 用 OpenID Connect ミドルウェアや Node.js 用 Passport プラグインなどがあります。These include the OWIN OpenID Connect middleware for ASP.NET and the Node.js Passport plug-in. Microsoft のミドルウェアを使用するコード サンプルについては、Microsoft ID プラットフォームの「使用の開始」セクションを参照してください。For code samples that use Microsoft middleware, see the Microsoft identity platform getting started section.
  • デスクトップまたはモバイル アプリケーションを構築する場合は、Microsoft の認証ライブラリ (MSAL) のいずれかを使用できます。If you're building a desktop or mobile application, you can use one of the Microsoft Authentication Libraries (MSAL). これらのライブラリは、一般提供されているか運用環境でサポートされているプレビュー版なので、実稼働アプリケーションで使用しても安全です。These libraries are generally available or in a production-supported preview, so it is safe to use them in production applications. プレビューの使用条件と使用可能なライブラリの詳細については、認証ライブラリのリファレンスに関するページをご覧ください。You can read more about the terms of the preview and the available libraries in authentication libraries reference.
  • Microsoft ライブラリの対象ではないプラットフォームでは、アプリケーション コードで直接プロトコル メッセージを送受信することで Microsoft ID プラットフォーム エンドポイントと統合できます。For platforms not covered by Microsoft libraries, you can integrate with the Microsoft identity platform endpoint by directly sending and receiving protocol messages in your application code. OpenID Connect プロトコルと OAuth プロトコルについては、このような統合の実施に役立つように、明確に文書化されています。The OpenID Connect and OAuth protocols are explicitly documented to help you do such an integration.
  • オープン ソースの OpenID Connect および OAuth のライブラリを使用して、Microsoft ID プラットフォーム エンドポイントと統合できます。Finally, you can use open-source OpenID Connect and OAuth libraries to integrate with the Microsoft identity platform endpoint. Microsoft ID プラットフォームのエンドポイントは通常、変更を加えなくても、多数のオープンソース プロトコル ライブラリと互換性があります。The Microsoft identity platform endpoint should be compatible with many open-source protocol libraries without changes. これらのライブラリが使用可能かどうかは、言語とプラットフォームによって異なります。The availability of these kinds of libraries varies by language and platform. OpenID Connect および OAuth 2.0 の Web サイトでは、一般的な実装のリストを公開しています。The OpenID Connect and OAuth 2.0 websites maintain a list of popular implementations. 詳細については、Microsoft ID プラットフォームと認証ライブラリに関するページと、Microsoft ID プラットフォーム エンドポイントでテスト済みのオープンソース クライアント ライブラリとサンプルの一覧を参照してください。For more information, see Microsoft identity platform and authentication libraries, and the list of open-source client libraries and samples that have been tested with the Microsoft identity platform endpoint.
  • 参照情報: Microsoft ID プラットフォーム共通エンドポイントの .well-known エンドポイントは https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration です。For reference, the .well-known endpoint for the Microsoft identity platform common endpoint is https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. common とテナント ID を置き換えて、お使いのテナントに固有のデータを取得します。Replace common with your tenant ID to get data specific to your tenant.

プロトコルの変更Protocol changes

Microsoft ID プラットフォーム エンドポイントは SAML と WS-Federation をサポートしていません。OpenID 接続と OAuth 2.0 のみをサポートしています。The Microsoft identity platform endpoint does not support SAML or WS-Federation; it only supports OpenID Connect and OAuth 2.0. OAuth 2.0 プロトコルに加えられた、v1.0 エンドポイントからの主な変更点は次のとおりです。The notable changes to the OAuth 2.0 protocols from the v1.0 endpoint are:

  • email 要求は、省略可能な要求が構成されている場合、またはその要求の中で scope=email が指定されている場合に返されます。The email claim is returned if an optional claim is configured or scope=email was specified in the request.
  • resource パラメーターに代わって、scope パラメーターがサポートされるようになりました。The scope parameter is now supported in place of the resource parameter.
  • OAuth 2.0 仕様への準拠性を高めるため、多くの応答に変更が加えられました (たとえば、expires_in を文字列ではなく整数として正しく返すなど)。Many responses have been modified to make them more compliant with the OAuth 2.0 specification, for example, correctly returning expires_in as an int instead of a string.

Microsoft ID プラットフォーム エンドポイントでサポートされているプロトコル機能の範囲について詳しく理解するには、OpenID Connect および OAuth 2.0 プロトコルに関するリファレンスを参照してください。To better understand the scope of protocol functionality supported in the Microsoft identity platform endpoint, see OpenID Connect and OAuth 2.0 protocol reference.

SAML の制限事項SAML restrictions

Windows アプリケーションで Active Directory Authentication Library (ADAL) を使用している場合は、Windows 統合認証を活用している可能性がありますが、これは Security Assertion Markup Language (SAML) アサーション付与を使用しています。If you've used Active Directory Authentication Library (ADAL) in Windows applications, you might have taken advantage of Windows Integrated authentication, which uses the Security Assertion Markup Language (SAML) assertion grant. この付与により、フェデレーション Azure AD テナントのユーザーは資格情報を入力せずに、オンプレミスの Active Directory インスタンスで自動的に認証できます。With this grant, users of federated Azure AD tenants can silently authenticate with their on-premises Active Directory instance without entering credentials. SAML アサーションの付与は、Microsoft ID プラットフォーム エンドポイントではサポートされていません。The SAML assertion grant isn't supported on the Microsoft identity platform endpoint.