Microsoft ID プラットフォームにおける OAuth 2.0 プロトコルと OpenID Connect プロトコルOAuth 2.0 and OpenID Connect protocols on Microsoft identity platform

Identity-as-a-service (サービスとしての ID) の Microsoft ID プラットフォームのエンドポイントは、業界標準のプロトコルである OpenID Connect (OIDC) と OAuth 2.0 をそれぞれ使用した認証と承認を実装します。The Microsoft identity platform endpoint for identity-as-a-service implements authentication and authorization with the industry standard protocols OpenID Connect (OIDC) and OAuth 2.0, respectively. このサービスは標準に準拠していますが、これらのプロトコルには、実装によって微妙な違いが存在する場合があります。While the service is standards-compliant, there can be subtle differences between any two implementations of these protocols. ここでは、Microsoft のオープンソース ライブラリを使うのではなく、直接 HTTP 要求を送信して処理することでコードを作成するか、サード パーティのオープンソース ライブラリを使用する場合に役立つ情報を紹介します。The information here will be useful if you choose to write your code by directly sending and handling HTTP requests or use a third-party open-source library, rather than using one of our open-source libraries.

基本The basics

OAuth 2.0 と OpenID Connect におけるフローはほぼすべて、情報のやり取りに 4 つの当事者が関係します。In nearly all OAuth 2.0 and OpenID Connect flows, there are four parties involved in the exchange:

OAuth 2.0 ロールを示す図

  • 承認サーバーは、Microsoft ID プラットフォーム エンドポイントとして、ユーザーの本人性確認、リソースへのアクセス権の付与と取り消し、トークンの発行という役割を担います。The Authorization Server is the Microsoft identity platform endpoint and responsible for ensuring the user's identity, granting and revoking access to resources, and issuing tokens. 承認サーバーは、ID プロバイダーと呼ばれることもあります。ユーザーの情報とそのアクセス、そしてフロー内の当事者間の信頼関係に関するすべてのことは、承認サーバーによって安全に処理されます。The authorization server is also known as the identity provider - it securely handles anything to do with the user's information, their access, and the trust relationships between parties in a flow.
  • リソース所有者 とは通常、エンド ユーザーを指します。The Resource Owner is typically the end user. データを所有し、そのデータまたはリソースへのアクセスをクライアントに許可する権限を持つ当事者です。It's the party that owns the data and has the power to allow clients to access that data or resource.
  • OAuth クライアントは、皆さんが開発するアプリです。対応するアプリケーション ID で識別されます。The OAuth Client is your app, identified by its application ID. 通常は、OAuth クライアントがエンド ユーザーと情報をやり取りし、承認サーバーにトークンを要求します。The OAuth client is usually the party that the end user interacts with, and it requests tokens from the authorization server. クライアントには、リソース所有者がリソースへのアクセス権を付与する必要があります。The client must be granted permission to access the resource by the resource owner.
  • リソース サーバーは、リソースまたはデータが存在する場所です。The Resource Server is where the resource or data resides. 承認サーバーを信頼し、OAuth クライアントを安全に認証、承認します。リソースへのアクセスを許可するためにベアラー アクセス トークンが使用されます。It trusts the Authorization Server to securely authenticate and authorize the OAuth Client, and uses Bearer access tokens to ensure that access to a resource can be granted.

アプリの登録App registration

個人用アカウントと職場や学校のアカウントの両方を受け付けるアプリはすべて、Azure portalアプリの登録 エクスペリエンスを通じて登録する必要があります。登録後、OAuth 2.0 または OpenID Connect を使用して、それらのユーザーをサインインさせることができます。Every app that wants to accept both personal and work or school accounts must be registered through the App registrations experience in the Azure portal before it can sign these users in using OAuth 2.0 or OpenID Connect. アプリの登録プロセスでは、いくつかの値が収集され、対象のアプリに割り当てられます。The app registration process will collect and assign a few values to your app:

  • アプリを一意に識別するアプリケーション IDAn Application ID that uniquely identifies your app
  • 応答をアプリにリダイレクトして戻すために使用できるリダイレクト URI (オプション)A Redirect URI (optional) that can be used to direct responses back to your app
  • その他シナリオに応じた値。A few other scenario-specific values.

詳細については、 アプリの登録方法を参照してください。For more details, learn how to register an app.


アプリは、登録されると、エンドポイントに要求を送ることによって、Microsoft ID プラットフォームと通信します。Once registered, the app communicates with Microsoft identity platform by sending requests to the endpoint:{tenant}/oauth2/v2.0/authorize{tenant}/oauth2/v2.0/token

ここで、 {tenant} は次の 4 つの値のいずれかになります。Where the {tenant} can take one of four different values:

Value 説明Description
common 個人の Microsoft アカウントと Azure AD の職場/学校アカウントのどちらでもアプリケーションにサインインできます。Allows users with both personal Microsoft accounts and work/school accounts from Azure AD to sign into the application.
organizations Azure AD の職場/学校アカウントを持つユーザーのみがアプリケーションにサインインできます。Allows only users with work/school accounts from Azure AD to sign into the application.
consumers 個人の Microsoft アカウント (MSA) を持つユーザーのみがアプリケーションにサインインできます。Allows only users with personal Microsoft accounts (MSA) to sign into the application.
8eaef023-2b34-4da1-9baa-8bc8c9d6a490 または contoso.onmicrosoft.com8eaef023-2b34-4da1-9baa-8bc8c9d6a490 or 特定の Azure AD テナントの職場/学校アカウントを持つユーザーのみがアプリケーションにサインインできます。Allows only users with work/school accounts from a particular Azure AD tenant to sign into the application. Azure AD テナントのフレンドリ ドメイン名か、テナントの GUID 識別子のいずれかを使用できます。Either the friendly domain name of the Azure AD tenant or the tenant's GUID identifier can be used.

これらのエンドポイントと対話する方法について学習するには、「プロトコル」セクションで特定のアプリの種類を選択し、リンクから詳細情報にアクセスしてください。To learn how to interact with these endpoints, choose a particular app type in the Protocols section and follow the links for more info.


Azure AD に登録されたアプリはいずれも、個人用アカウントにサインインしなくても、Microsoft ID プラットフォーム エンドポイントを使用できます。Any app registered in Azure AD can use the Microsoft identity platform endpoint, even if they don't sign in personal accounts. アプリケーションを作成し直さなくても、このようにして既存のアプリケーションを Microsoft ID プラットフォームと MSAL に移行することができます。This way, you can migrate existing applications to Microsoft identity platform and MSAL without re-creating your application.


OAuth 2.0 と OpenID Connect では、ベアラー トークンが頻繁に使用され、一般に JWT (JSON Web トークン) で表されます。OAuth 2.0 and OpenID Connect make extensive use of bearer tokens, generally represented as JWTs (JSON Web Tokens). ベアラー トークンは、保護されたリソースへの "ベアラー" アクセスを許可する簡易セキュリティ トークンです。A bearer token is a lightweight security token that grants the “bearer” access to a protected resource. この意味で、"ベアラー" はトークンのコピーを取得するすべてのユーザーです。In this sense, the “bearer” is anyone that gets a copy of the token. 利用者がベアラー トークンを受信するには、まず Microsoft ID プラットフォームによる認証が必要となりますが、転送中や保存時にトークンを保護するために必要な対策を講じていない場合、意図しない利用者によって傍受され、使用されるおそれがあります。Though a party must first authenticate with Microsoft identity platform to receive the bearer token, if the required steps are not taken to secure the token in transmission and storage, it can be intercepted and used by an unintended party. 一部のセキュリティ トークンには、許可されていない利用者がトークンを使用できないようにするための組み込みメカニズムがありますが、ベアラー トークンにはこのメカニズムがないため、トランスポート層セキュリティ (HTTPS) などのセキュリティで保護されたチャネルで転送する必要があります。While some security tokens have a built-in mechanism for preventing unauthorized parties from using them, bearer tokens do not have this mechanism and must be transported in a secure channel such as transport layer security (HTTPS). ベアラー トークンが暗号化されずに転送された場合、悪意のある利用者が中間者攻撃によってトークンを取得し、保護されたリソースへの未承認のアクセスに使用する可能性があります。If a bearer token is transmitted in the clear, a malicious party can use a man-in-the-middle attack to acquire the token and use it for unauthorized access to a protected resource. 後で使用するためにベアラー トークンを保存またはキャッシュするときにも、同じセキュリティ原則が適用されます。The same security principles apply when storing or caching bearer tokens for later use. アプリケーションでは、常に安全な方法でベアラー トークンを転送および保存してください。Always ensure that your app transmits and stores bearer tokens in a secure manner. ベアラー トークンのセキュリティに関する考慮事項の詳細については、 RFC 6750 セクション 5をご覧ください。For more security considerations on bearer tokens, see RFC 6750 Section 5.

OAuth 2.0/OIDC で使用されるトークンは主に 3 種類あります。There are primarily 3 types of tokens used in OAuth 2.0 / OIDC:

  • アクセス トークン - リソース サーバーがクライアントから受け取るトークンで、クライアントに付与されているアクセス許可が含まれます。Access tokens - tokens that a resource server receives from a client, containing permissions the client has been granted.
  • ID トークン - クライアントが承認サーバーから受け取るトークンで、ユーザーをサインインさせ、ユーザーに関する基本情報を取得するために使用されます。ID tokens - tokens that a client receives from the authorization server, used to sign in a user and get basic information about them.
  • 更新トークン - 時間の経過と共にクライアントが新しいアクセス トークンと ID トークンを取得するために使用されます。Refresh tokens - used by a client to get new access and ID tokens over time. これらは不透明な文字列であり、承認サーバーによってのみ理解可能です。These are opaque strings, and are only understandable by the authorization server.


要求の例を確認する準備ができたら、以下のいずれかのプロトコル ドキュメントから始めてください。If you're ready to see some example requests, get started with one of the below protocol documents. いずれも、特定の認証シナリオに対応しています。Each one corresponds to a particular authentication scenario. どのフローを見ればよいかわからない場合は、Microsoft ID プラットフォームを使用して構築できるアプリの種類に関するページを参照してください。If you need help with determining which is the right flow for you, check out the types of apps you can build with Microsoft identity platform.