Microsoft ID プラットフォームと OAuth 2.0 認証コード フローMicrosoft identity platform and OAuth 2.0 authorization code flow

デバイスにインストールされているアプリに、Web API など、保護されているリソースにアクセスする権利を与えるために OAuth 2.0 認証コード付与を利用できます。The OAuth 2.0 authorization code grant can be used in apps that are installed on a device to gain access to protected resources, such as web APIs. Microsoft ID プラットフォームによる OAuth 2.0 の実装を使用すると、サインインおよび API アクセスをモバイル アプリやデスクトップ アプリに追加できます。Using the Microsoft identity platform implementation of OAuth 2.0, you can add sign in and API access to your mobile and desktop apps.

この記事では、任意の言語を使用して、アプリケーションでプロトコルに対して直接プログラミングする方法について説明します。This article describes how to program directly against the protocol in your application using any language. 可能な場合は、トークンを取得してセキュリティで保護された Web API を呼び出す代わりに、サポートされている Microsoft 認証ライブラリ (MSAL) を使用することをお勧めします。When possible, we recommend you use the supported Microsoft Authentication Libraries (MSAL) instead to acquire tokens and call secured web APIs. また、MSAL を使用するサンプル アプリも参照してください。Also take a look at the sample apps that use MSAL.

OAuth 2.0 承認コード フローは、 OAuth 2.0 仕様のセクション 4.1で規定されています。The OAuth 2.0 authorization code flow is described in section 4.1 of the OAuth 2.0 specification. これは、シングル ページ アプリWeb アプリネイティブにインストールされるアプリなど、大半のアプリ タイプで認証と承認を行う際に使用されます。It's used to perform authentication and authorization in the majority of app types, including single page apps, web apps, and natively installed apps. このフローにより、アプリは、Microsoft ID プラットフォームによって保護されたリソースにアクセスするために使用できる access_token を安全に取得でき、また、追加の access_token を取得するための更新トークンや、サインインしたユーザーの ID トークンも安全に取得できます。The flow enables apps to securely acquire access_tokens that can be used to access resources secured by the Microsoft identity platform, as well as refresh tokens to get additional access_tokens, and ID tokens for the signed in user.

プロトコルのダイアグラムProtocol diagram

まとめると、アプリケーションの全体的な認証フローは次のようになります。At a high level, the entire authentication flow for an application looks a bit like this:

OAuth Auth Code Flow

シングル ページ アプリに必要なリダイレクト URI セットアップRedirect URI setup required for single-page apps

シングル ページ アプリケーションの承認コード フローでは、追加のセットアップが必要です。The authorization code flow for single page applications requires some additional setup. シングルページ アプリケーションの作成手順に従って、CORS に対して有効としてリダイレクト URI を正しくマークします。Follow the instructions for creating your single-page application to correctly mark your redirect URI as enabled for CORS. CORS を有効にするために既存のリダイレクト URI を更新するには、マニフェスト エディターを開き、replyUrlsWithType セクションでリダイレクト URI の type フィールドを spa に設定します。To update an existing redirect URI to enable CORS, open the manifest editor and set the type field for your redirect URI to spa in the replyUrlsWithType section. [認証] タブの [Web] セクションでリダイレクト URI をクリックし、承認コード フローを使用して、移行先の URI を選択することもできます。You can also click on the redirect URI in the "Web" section of the Authentication tab, and select the URIs you want to migrate to using the authorization code flow.

spa のリダイレクトの種類は、暗黙的なフローと下位互換性があります。The spa redirect type is backwards compatible with the implicit flow. トークンを取得するために暗黙的なフローを現在使用しているアプリは、問題なく spa のリダイレクト URI の種類に移行し、暗黙的なフローを引き続き使用することができます。Apps currently using the implicit flow to get tokens can move to the spa redirect URI type without issues and continue using the implicit flow.

承認コード フローを使用しようとして、次のエラーが表示された場合:If you attempt to use the authorization code flow and see this error:

access to XMLHttpRequest at 'https://login.microsoftonline.com/common/v2.0/oauth2/token' from origin 'yourApp.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

この場合、アプリの登録にアクセスし、アプリのリダイレクト URI を spa 型に更新します。Then, visit your app registration and update the redirect URI for your app to type spa.

承認コードを要求するRequest an authorization code

承認コード フローは、クライアントがユーザーを /authorize エンドポイントにリダイレクトさせることから始まります。The authorization code flow begins with the client directing the user to the /authorize endpoint. この要求では、クライアントは、ユーザーからの openidoffline_access、および https://graph.microsoft.com/mail.read のアクセス許可を要求します。In this request, the client requests the openid, offline_access, and https://graph.microsoft.com/mail.read permissions from the user. Directory.ReadWrite.All を使用した組織のディレクトリへのデータの書き込みなど、一部のアクセス許可は管理者によって制限されます。Some permissions are admin-restricted, for example writing data to an organization's directory by using Directory.ReadWrite.All. アプリケーションが組織のユーザーにこれらのアクセス許可のいずれかへのアクセスを要求すると、ユーザーは、アプリのアクセス許可に同意する権限がないという内容のエラー メッセージを受け取ります。If your application requests access to one of these permissions from an organizational user, the user receives an error message that says they're not authorized to consent to your app's permissions. 管理者によって制限されるスコープへのアクセスを要求するには、全体管理者から直接要求する必要があります。To request access to admin-restricted scopes, you should request them directly from a Global Administrator. 詳細については、「管理者によって制限されるアクセス許可」を参照してください。For more information, read Admin-restricted permissions.

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read%20api%3A%2F%2F
&state=12345
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256

ヒント

この要求を実行するには、以下のリンクをクリックしてください。Click the link below to execute this request! サインイン後、ブラウザーは https://localhost/myapp/ にリダイレクトされ、アドレス バーに code が含まれた状態になります。After signing in, your browser should be redirected to https://localhost/myapp/ with a code in the address bar. https://login.microsoftonline.com/common/oauth2/v2.0/authorize...https://login.microsoftonline.com/common/oauth2/v2.0/authorize...

パラメーターParameter 必須/省略可能Required/optional 説明Description
tenant requiredrequired 要求パスの {tenant} の値を使用して、アプリケーションにサインインできるユーザーを制御します。The {tenant} value in the path of the request can be used to control who can sign into the application. 使用できる値は、commonorganizationsconsumers およびテナント識別子です。The allowed values are common, organizations, consumers, and tenant identifiers. 詳細については、 プロトコルの基礎に関するページを参照してください。For more detail, see protocol basics.
client_id requiredrequired Azure portal の [アプリの登録] エクスペリエンスでアプリに割り当てられた アプリケーション (クライアント) IDThe Application (client) ID that the Azure portal – App registrations experience assigned to your app.
response_type requiredrequired 承認コード フローでは code を指定する必要があります。Must include code for the authorization code flow. ハイブリッド フローを使用する場合は、id_token または token を含めることもできます。Can also include id_token or token if using the hybrid flow.
redirect_uri 必須required アプリ の redirect_uri。アプリは、この URI で認証応答を送受信することができます。The redirect_uri of your app, where authentication responses can be sent and received by your app. ポータルで登録したいずれかの redirect_uri と完全に一致させる必要があります (ただし、URL エンコードが必要)。It must exactly match one of the redirect_uris you registered in the portal, except it must be url encoded. ネイティブ アプリやモバイル アプリの場合は、推奨される値 (埋め込みのブラウザーを使用するアプリの場合は https://login.microsoftonline.com/common/oauth2/nativeclient、システム ブラウザーを使用するアプリの場合は http://localhost) のいずれかを使用してください。For native & mobile apps, you should use one of the recommended values - https://login.microsoftonline.com/common/oauth2/nativeclient (for apps using embedded browsers) or http://localhost (for apps that use system browsers).
scope requiredrequired ユーザーに同意を求める スコープ の、スペースで区切られたリスト。A space-separated list of scopes that you want the user to consent to. 要求の /authorize の段階では、これに複数のリソースを含めることができ、ご利用のアプリが呼び出す必要がある複数の Web API に対して同意を取得することを許可します。For the /authorize leg of the request, this can cover multiple resources, allowing your app to get consent for multiple web APIs you want to call.
response_mode 推奨recommended 結果として得られたトークンをアプリに返す際に使用するメソッドを指定します。Specifies the method that should be used to send the resulting token back to your app. 以下のいずれかを指定できます。Can be one of the following:

- query
- fragment
- form_post

query はリダイレクト URI でクエリ文字列パラメーターとしてコードを提供します。query provides the code as a query string parameter on your redirect URI. 暗黙的フローを使って ID トークンを要求する場合、OpenID 仕様で規定された query を使用することはできません。コードのみを要求する場合は、queryfragmentform_post のいずれかを使用できます。If you're requesting an ID token using the implicit flow, you can't use query as specified in the OpenID spec. If you're requesting just the code, you can use query, fragment, or form_post. form_post は、リダイレクト URI に対するコードを含んだ POST を実行します。form_post executes a POST containing the code to your redirect URI.
state 推奨recommended 要求に含まれ、かつトークンの応答として返される値。A value included in the request that will also be returned in the token response. 任意の文字列を指定することができます。It can be a string of any content that you wish. クロスサイト リクエスト フォージェリ攻撃を防ぐために通常、ランダムに生成された一意の値が使用されます。A randomly generated unique value is typically used for preventing cross-site request forgery attacks. この値を使用すると、認証要求の前にアプリ内でユーザーの状態 (表示中のページやビューなど) に関する情報をエンコードすることもできます。The value can also encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on.
prompt 省略可能optional ユーザーとの必要な対話の種類を指定します。Indicates the type of user interaction that is required. 現時点で有効な値は loginnoneconsent だけです。The only valid values at this time are login, none, and consent.

- prompt=login は、その要求でユーザーに資格情報の入力を強制し、シングル サインオンを無効にします。- prompt=login will force the user to enter their credentials on that request, negating single-sign on.
- prompt=none はその反対であり、ユーザーにどのような対話型プロンプトも表示されないようにします。- prompt=none is the opposite - it will ensure that the user isn't presented with any interactive prompt whatsoever. シングル サインオンで確認なしで要求を完了できない場合は、Microsoft ID プラットフォームから interaction_required エラーが返されます。If the request can't be completed silently via single-sign on, the Microsoft identity platform will return an interaction_required error.
- prompt=consent では、ユーザーがサインインした後で OAuth 同意ダイアログが表示され、アプリへのアクセス許可の付与をユーザーに求めます。- prompt=consent will trigger the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.
- prompt=select_account では、シングル サインオンに割り込み、まったく別のアカウントの使用を選択するためのオプションとして、セッション内または記憶されているアカウント内のいずれかにある全アカウントを一覧表示するアカウント選択エクスペリエンスを提供します。- prompt=select_account will interrupt single sign-on providing account selection experience listing all the accounts either in session or any remembered account or an option to choose to use a different account altogether.
login_hint 省略可能optional ユーザー名が事前にわかっている場合、ユーザーに代わって事前に、サインイン ページのユーザー名/電子メール アドレス フィールドに入力ができます。Can be used to pre-fill the username/email address field of the sign-in page for the user, if you know their username ahead of time. アプリはしばしば前回のサインインから preferred_username 要求を抽出して再認証時にこのパラメーターを使用します。Often apps will use this parameter during re-authentication, having already extracted the username from a previous sign-in using the preferred_username claim.
domain_hint 省略可能optional これが含まれていると、ユーザーがサインイン ページで実行する電子メール ベースの検出プロセスがスキップされ、多少効率化されたユーザー エクスペリエンスが提供されます (たとえば、フェデレーション ID プロバイダーへの送信など)。If included, it will skip the email-based discovery process that user goes through on the sign-in page, leading to a slightly more streamlined user experience - for example, sending them to their federated identity provider. 多くの場合、アプリでは、前回のサインインから tid を抽出することで再認証時にこのパラメーターを使用します。Often apps will use this parameter during re-authentication, by extracting the tid from a previous sign-in. tid 要求の値が 9188040d-6c67-4c5b-b112-36a304b66dad の場合、domain_hint=consumers を使用する必要があります。If the tid claim value is 9188040d-6c67-4c5b-b112-36a304b66dad, you should use domain_hint=consumers. それ以外の場合は、 domain_hint=organizationsを指定します。Otherwise, use domain_hint=organizations.
code_challenge 推奨/必須recommended / required PKCE (Proof Key for Code Exchange) を使用して承認コード付与をセキュリティ保護するために使用されます。Used to secure authorization code grants via Proof Key for Code Exchange (PKCE). code_challenge_method が含まれている場合は必須です。Required if code_challenge_method is included. 詳細については、「PKCE RFC」を参照してください。For more information, see the PKCE RFC. これは、すべての種類のアプリケーション (パブリック クライアントと機密クライアントの両方) で推奨されるようになり、Microsoft ID プラットフォームでは認可コード フローを使用するシングル ページ アプリで必須となりました。This is now recommended for all application types - both public and confidential clients - and required by the Microsoft identity platform for single page apps using the authorization code flow.
code_challenge_method 推奨/必須recommended / required code_challenge パラメーターの code_verifier をエンコードするために使用されるメソッド。The method used to encode the code_verifier for the code_challenge parameter. これは S256 である べき ですが、何らかの理由によってクライアントで SHA256 がサポートされない場合、仕様では plain の使用が許可されています。This SHOULD be S256, but the spec allows the use of plain if for some reason the client cannot support SHA256.

除外されていると、code_challenge が含まれている場合、code_challenge はプレーンテキストであると見なされます。If excluded, code_challenge is assumed to be plaintext if code_challenge is included. Microsoft ID プラットフォームは plainS256 の両方をサポートします。The Microsoft identity platform supports both plain and S256. 詳細については、「PKCE RFC」を参照してください。For more information, see the PKCE RFC. これは、承認コード フローを使用するシングル ページ アプリには必須です。This is required for single page apps using the authorization code flow.

現時点では、ユーザーに資格情報の入力と認証が求められます。At this point, the user will be asked to enter their credentials and complete the authentication. また、Microsoft ID プラットフォームでは、ユーザーが scope クエリ パラメーターに示されたアクセス許可に同意していることも確認されます。The Microsoft identity platform will also ensure that the user has consented to the permissions indicated in the scope query parameter. いずれのアクセス許可にもユーザーが同意しなかった場合、必要なアクセス許可に同意するようユーザーに求めます。If the user has not consented to any of those permissions, it will ask the user to consent to the required permissions. アクセス許可、同意、マルチテナント アプリの詳細については、 こちらを参照してください。Details of permissions, consent, and multi-tenant apps are provided here.

ユーザーが認証され、同意すると、Microsoft ID プラットフォームは response_mode パラメーターで指定された方法を使用して、指定された redirect_uri でアプリに応答を返します。Once the user authenticates and grants consent, the Microsoft identity platform will return a response to your app at the indicated redirect_uri, using the method specified in the response_mode parameter.

成功応答Successful response

response_mode=query を使用した場合の正常な応答は次のようになります。A successful response using response_mode=query looks like:

GET http://localhost?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345
パラメーターParameter 説明Description
code アプリが要求した authorization_code。The authorization_code that the app requested. アプリは承認コードを使用して、対象リソースのアクセス トークンを要求します。The app can use the authorization code to request an access token for the target resource. 承認コードは有効期間が短く、通常 10 分後には期限切れとなります。Authorization_codes are short lived, typically they expire after about 10 minutes.
state 要求に state パラメーターが含まれている場合、同じ値が応答にも含まれることになります。If a state parameter is included in the request, the same value should appear in the response. 要求と応答に含まれる状態値が同一であることをアプリ側で確認する必要があります。The app should verify that the state values in the request and response are identical.

また、ID トークンを要求し、アプリケーションの登録で暗黙的な許可が有効になっている場合には、その ID トークンを受け取ることができます。You can also receive an ID token if you request one and have the implicit grant enabled in your application registration. これは "ハイブリッド フロー" と呼ばれることもあり、ASP.NET のようなフレームワークで使用されます。This is sometimes referred to as the "hybrid flow", and is used by frameworks like ASP.NET.

エラー応答Error response

アプリ側でエラーを適切に処理できるよう、 redirect_uri にはエラー応答も送信されます。Error responses may also be sent to the redirect_uri so the app can handle them appropriately:

GET http://localhost?
error=access_denied
&error_description=the+user+canceled+the+authentication
パラメーターParameter 説明Description
error 発生したエラーの種類を分類したりエラーに対処したりする際に使用するエラー コード文字列。An error code string that can be used to classify types of errors that occur, and can be used to react to errors.
error_description 認証エラーの根本的な原因を開発者が特定しやすいように記述した具体的なエラー メッセージ。A specific error message that can help a developer identify the root cause of an authentication error.

承認エンドポイント エラーのエラー コードError codes for authorization endpoint errors

次の表で、エラー応答の error パラメーターで返される可能性のあるさまざまなエラー コードを説明します。The following table describes the various error codes that can be returned in the error parameter of the error response.

エラー コードError Code 説明Description クライアント側の処理Client Action
invalid_request 必要なパラメーターが不足しているなどのプロトコル エラーです。Protocol error, such as a missing required parameter. 要求を修正し再送信します。Fix and resubmit the request. これは、開発エラーであり、通常は初期テスト中に発生します。This is a development error typically caught during initial testing.
unauthorized_client クライアント アプリケーションは、承認コードの要求を許可されていません。The client application isn't permitted to request an authorization code. 通常、このエラーは、クライアント アプリケーションが Azure AD に登録されていない、またはユーザーの Azure AD テナントに追加されていないときに発生します。This error usually occurs when the client application isn't registered in Azure AD or isn't added to the user's Azure AD tenant. アプリケーションでは、アプリケーションのインストールと Azure AD への追加を求める指示をユーザーに表示できます。The application can prompt the user with instruction for installing the application and adding it to Azure AD.
access_denied リソースの所有者が同意を拒否しました。Resource owner denied consent クライアント アプリケーションは、ユーザーが同意しないと続行できないことを、ユーザーに通知できます。The client application can notify the user that it can't proceed unless the user consents.
unsupported_response_type 承認サーバーは要求に含まれる応答の種類をサポートしていません。The authorization server does not support the response type in the request. 要求を修正し再送信します。Fix and resubmit the request. これは、開発エラーであり、通常は初期テスト中に発生します。This is a development error typically caught during initial testing. ハイブリッド フローで表示された場合、クライアント アプリの登録で ID トークンの暗黙的な許可設定を有効にする必要があることを示します。When seen in the hybrid flow, signals that you must enable the ID token implicit grant setting on the client app registration.
server_error サーバーで予期しないエラーが発生しました。The server encountered an unexpected error. 要求をやり直してください。Retry the request. これらのエラーは一時的な状況によって発生します。These errors can result from temporary conditions. クライアント アプリケーションは、一時的なエラーのため応答が遅れることをユーザーに説明する場合があります。The client application might explain to the user that its response is delayed to a temporary error.
temporarily_unavailable サーバーが一時的にビジー状態であるため、要求を処理できません。The server is temporarily too busy to handle the request. 要求をやり直してください。Retry the request. クライアント アプリケーションは、一時的な状況が原因で応答が遅れることをユーザーに説明する場合があります。The client application might explain to the user that its response is delayed because of a temporary condition.
invalid_resource 対象のリソースは、存在しない、Azure AD が見つけられない、または正しく構成されていないために無効です。The target resource is invalid because it does not exist, Azure AD can't find it, or it's not correctly configured. このエラーは、リソース (存在する場合) がテナントで構成されていないことを示します。This error indicates the resource, if it exists, has not been configured in the tenant. アプリケーションでは、アプリケーションのインストールと Azure AD への追加を求める指示をユーザーに表示できます。The application can prompt the user with instruction for installing the application and adding it to Azure AD.
login_required ユーザーが多すぎるか、見つかりませんToo many or no users found クライアントからサイレント認証が要求されましたが (prompt=none)、ユーザーは 1 つも見つかりませんでした。The client requested silent authentication (prompt=none), but a single user could not found. これは、セッションで複数のユーザーがアクティブになっているか、ユーザーがないことを意味する可能性があります。This may mean there are multiple users active in the session, or no users. このとき、選択されたテナントが考慮されます (たとえば、Azure AD アカウントが 2 つアクティブになっているか、Microsoft アカウントが 1 つあるかが考慮されます。consumers が選択されている場合はサイレント認証は機能します)。This takes into account the tenant chosen (for example, if there are two Azure AD accounts active and one Microsoft account, and consumers is chosen, silent authentication will work).
interaction_required 要求にユーザーの介入が必要です。The request requires user interaction. 追加の認証手順か同意が必要になります。An additional authentication step or consent is required. prompt=none なしで要求を再試行してください。Retry the request without prompt=none.

ID トークンも要求する (ハイブリッド フロー)Request an ID token as well (hybrid flow)

認可コードの引き換え前にユーザーが誰であるかを確認するには、一般的に、アプリケーションで認可コードを要求するときに ID トークンも要求します。To learn who the user is before redeeming an authorization code, it's common for applications to also request an ID token when they request the authorization code. これは、暗黙的な許可と認可コード フローが混在するため、"ハイブリッド フロー" と呼ばれます。This is called the hybrid flow because it mixes the implicit grant with the authorization code flow. ハイブリッド フローは、コードの引き換え時にブロックなしでユーザーにページをレンダリングする Web アプリで一般的に使用されます (特に ASP.NET)。The hybrid flow is commonly used in web apps that want to render a page for a user without blocking on code redemption, notably ASP.NET. シングルページ アプリも従来の Web アプリも、このモデルの待機時間短縮のメリットを得ることができます。Both single-page apps and traditional web apps benefit from reduced latency in this model.

ハイブリッド フローは、前述の認可コード フローと同じですが、3 つの追加要素として新しいスコープ、新しい response_type、新しい nonce クエリ パラメーターがあり、これらはすべて ID トークンを要求するために必要です。The hybrid flow is the same as the authorization code flow described earlier but with three additions, all of which are required to request an ID token: new scopes, a new response_type, and a new nonce query parameter.

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code%20id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=fragment
&scope=openid%20offline_access%20https%3A%2F%2Fgraph.microsoft.com%2Fuser.read
&state=12345
&nonce=abcde
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
更新対象パラメーターUpdated Parameter 必須/省略可能Required/optional 説明Description
response_type 必須Required id_token の追加により、アプリケーションが /authorize エンドポイントからの応答で ID トークンを要求していることがサーバーに示されます。The addition of id_token indicates to the server that the application would like an ID token in the response from the /authorize endpoint.
scope 必須Required ID トークン用であり、更新して ID トークン スコープ (openid とオプションの profile および email) を含める必要があります。For ID tokens, must be updated to include the ID token scopes - openid, and optionally profile and email.
nonce 必須Required 要求に含まれる、アプリによって生成される値。この値は、結果の id_token に要求として含まれます。A value included in the request, generated by the app, that will be included in the resulting id_token as a claim. アプリはこの値を確認することにより、トークン リプレイ攻撃を緩和できます。The app can then verify this value to mitigate token replay attacks. 通常、この値はランダム化された一意の文字列であり、要求の送信元を特定する際に使用できます。The value is typically a randomized, unique string that can be used to identify the origin of the request.
response_mode 推奨Recommended 結果として得られたトークンをアプリに返す際に使用するメソッドを指定します。Specifies the method that should be used to send the resulting token back to your app. 既定では、認可コードのみの場合は query に設定されますが、要求に id_token response_type を含める場合は fragment に設定します。Defaults to query for just an authorization code, but fragment if the request includes an id_token response_type. ただし、特に http:/localhost をリダイレクト URI として使用している場合は、アプリで form_post を使用することをお勧めします。However, apps are recommended to use form_post, especially when using http:/localhost as a redirect URI.

応答モードとして fragment を使用すると、ブラウザーでフラグメントが Web サーバーに渡されないため、リダイレクトからコードを読み取る Web アプリでは問題が発生する可能性があります。The use of fragment as a response mode causes issues for web apps that read the code from the redirect, as browsers do not pass the fragment to the web server. このような状況では、すべてのデータがサーバーに送信されるようにするために、アプリで form_post 応答モードを使用してください。In these situations, apps should use the form_post response mode to ensure that all data is sent to the server.

成功応答Successful response

response_mode=fragment を使用した場合の正常な応答は次のようになります。A successful response using response_mode=fragment looks like:

GET https://login.microsoftonline.com/common/oauth2/nativeclient#
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&id_token=eYj...
&state=12345
パラメーターParameter 説明Description
code アプリが要求した承認コード。The authorization code that the app requested. アプリは承認コードを使用して、対象リソースのアクセス トークンを要求します。The app can use the authorization code to request an access token for the target resource. 認可コードは有効期間が短く、通常 10 分後には期限切れとなります。Authorization codes are short lived, typically expiring after about 10 minutes.
id_token "暗黙的な許可" によって発行されたユーザーの ID トークン。An ID token for the user, issued via implicit grant. 同じ要求に code のハッシュである特別な c_hash 要求が含まれます。Contains a special c_hash claim that is the hash of the code in the same request.
state 要求に state パラメーターが含まれている場合、同じ値が応答にも含まれることになります。If a state parameter is included in the request, the same value should appear in the response. アプリは、要求と応答の state 値が同じであることを検証します。The app should verify that the state values in the request and response are identical.

アクセス トークンを要求するRequest an access token

authorization_code を取得し、ユーザーからアクセス許可を得たら、access_tokencode を目的のリソースに対して使うことができます。Now that you've acquired an authorization_code and have been granted permission by the user, you can redeem the code for an access_token to the desired resource. これを行うには、POST 要求を /token エンドポイントに送信します。Do this by sending a POST request to the /token endpoint:

// Line breaks for legibility only

POST /{tenant}/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong 
&client_secret=JqQX2PNo9bpM0uEihUPzyrh    // NOTE: Only required for web apps. This secret needs to be URL-Encoded.

ヒント

を必ず置き換えてください)。Try executing this request in Postman! (code を置き換えるのを忘れないでください) Postman でこの要求を実行してみる(Don't forget to replace the code) Try running this request in Postman

パラメーターParameter 必須/省略可能Required/optional 説明Description
tenant requiredrequired 要求パスの {tenant} の値を使用して、アプリケーションにサインインできるユーザーを制御します。The {tenant} value in the path of the request can be used to control who can sign into the application. 使用できる値は、commonorganizationsconsumers およびテナント識別子です。The allowed values are common, organizations, consumers, and tenant identifiers. 詳細については、 プロトコルの基礎に関するページを参照してください。For more detail, see protocol basics.
client_id requiredrequired Azure portal の [アプリの登録] ページでアプリに割り当てられたアプリケーション (クライアント) ID。The Application (client) ID that the Azure portal – App registrations page assigned to your app.
grant_type requiredrequired 承認コード フローでは authorization_code を指定する必要があります。Must be authorization_code for the authorization code flow.
scope オプションoptional スペースで区切られたスコープのリスト。A space-separated list of scopes. このスコープはすべて、OIDC スコープ (profileopenidemail) に沿って、1 つのリソースからである必要があります。The scopes must all be from a single resource, along with OIDC scopes (profile, openid, email). スコープの詳細については、 アクセス許可、同意、スコープに関するページを参照してください。For a more detailed explanation of scopes, refer to permissions, consent, and scopes. これは、承認コード フローの Microsoft 拡張機能であり、トークンの引き換え時にトークンが必要なリソースをアプリによって宣言できるようにするためのものです。This is a Microsoft extension to the authorization code flow, intended to allow apps to declare the resource they want the token for during token redemption.
code requiredrequired フローの最初の段階で取得した authorization_code。The authorization_code that you acquired in the first leg of the flow.
redirect_uri requiredrequired authorization_code の取得に使用された同じ redirect_uri 値。The same redirect_uri value that was used to acquire the authorization_code.
client_secret 機密 Web アプリには必須required for confidential web apps アプリ登録ポータルで作成した、アプリケーションのシークレット。The application secret that you created in the app registration portal for your app. client_secret をデバイスや Web ページに確実に保存することはできないため、ネイティブ アプリやシングル ページ アプリではアプリケーションのシークレットを使用しないでください。You shouldn't use the application secret in a native app or single page app because client_secrets can't be reliably stored on devices or web pages. Web アプリや Web API では client_secret をサーバー側で安全に保存する機能が備わっており、必ず指定する必要があります。It's required for web apps and web APIs, which have the ability to store the client_secret securely on the server side. ここで説明されているすべてのパラメーターと同様に、クライアント シークレットは、送信前に URL エンコードする必要があります。これは、通常、SDK によって実行される手順です。Like all parameters discussed here, the client secret must be URL-encoded before being sent, a step usually performed by the SDK. URI エンコードの詳細については、URI の一般構文の仕様に関する記事を参照してください。For more information on uri encoding, see the URI Generic Syntax specification.
code_verifier 推奨recommended authorization_code を取得するために使用されたのと同じ code_verifier。The same code_verifier that was used to obtain the authorization_code. 承認コード付与要求で PKCE が使用された場合は必須です。Required if PKCE was used in the authorization code grant request. 詳細については、「PKCE RFC」を参照してください。For more information, see the PKCE RFC.

成功応答Successful response

正常なトークン応答は次のようになります。A successful token response will look like:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "scope": "https%3A%2F%2Fgraph.microsoft.com%2Fmail.read",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}
パラメーターParameter 説明Description
access_token 要求されたアクセス トークン。The requested access token. アプリはこのトークンを使用して、保護されたリソース (Web API など) に対し、本人性を証明することができます。The app can use this token to authenticate to the secured resource, such as a web API.
token_type トークン タイプ値を指定します。Indicates the token type value. Azure AD でサポートされるのは Bearer タイプのみです。The only type that Azure AD supports is Bearer
expires_in アクセス トークンの有効期間 (秒)。How long the access token is valid (in seconds).
scope access_token が有効である範囲。The scopes that the access_token is valid for. 省略可能 - これは非標準です。省略した場合、トークンはフローの最初の区間で要求されたスコープ用になります。Optional - this is non-standard, and if omitted the token will be for the scopes requested on the initial leg of the flow.
refresh_token OAuth 2.0 更新トークン。An OAuth 2.0 refresh token. 現在のアクセス トークンの有効期限が切れた後、アプリはこのトークンを使用して、追加のアクセス トークンを取得します。The app can use this token acquire additional access tokens after the current access token expires. Refresh_token は有効期間が長く、リソースへのアクセスを長時間保持するときに利用できます。Refresh_tokens are long-lived, and can be used to retain access to resources for extended periods of time. アクセス トークンの更新の詳細については、後述のセクションを参照してください。For more detail on refreshing an access token, refer to the section below.
注: offline_access スコープが要求された場合のみ提供されます。Note: Only provided if offline_access scope was requested.
id_token JSON Web トークン (JWT)。A JSON Web Token (JWT). アプリは、このトークンのセグメントをデコードすることによって、サインインしたユーザーに関する情報を要求することができます。The app can decode the segments of this token to request information about the user who signed in. アプリでは値をキャッシュして表示できます。また、機密クライアントではこの値を使用して承認を行うことができます。The app can cache the values and display them, and confidential clients can use this for authorization. id_token の詳細については、id_token referenceを参照してください。For more information about id_tokens, see the id_token reference.
注: openid スコープが要求された場合のみ提供されます。Note: Only provided if openid scope was requested.

エラー応答Error response

エラー応答は次のようになります。Error responses will look like:

{
  "error": "invalid_scope",
  "error_description": "AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope https://foo.microsoft.com/mail.read is not valid.\r\nTrace ID: 255d1aef-8c98-452f-ac51-23d051240864\r\nCorrelation ID: fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7\r\nTimestamp: 2016-01-09 02:02:12Z",
  "error_codes": [
    70011
  ],
  "timestamp": "2016-01-09 02:02:12Z",
  "trace_id": "255d1aef-8c98-452f-ac51-23d051240864",
  "correlation_id": "fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7"
}
パラメーターParameter 説明Description
error 発生したエラーの種類を分類したりエラーに対処したりする際に使用するエラー コード文字列。An error code string that can be used to classify types of errors that occur, and can be used to react to errors.
error_description 認証エラーの根本的な原因を開発者が特定しやすいように記述した具体的なエラー メッセージ。A specific error message that can help a developer identify the root cause of an authentication error.
error_codes 診断に役立つ STS 固有のエラー コードの一覧。A list of STS-specific error codes that can help in diagnostics.
timestamp エラーが発生した時刻。The time at which the error occurred.
trace_id 診断に役立つ、要求の一意の識別子。A unique identifier for the request that can help in diagnostics.
correlation_id コンポーネント間での診断に役立つ、要求の一意の識別子。A unique identifier for the request that can help in diagnostics across components.

トークン エンドポイント エラーのエラー コードError codes for token endpoint errors

エラー コードError Code 説明Description クライアント側の処理Client Action
invalid_request 必要なパラメーターが不足しているなどのプロトコル エラーです。Protocol error, such as a missing required parameter. 要求またはアプリの登録を修正し、要求を再送信します。Fix the request or app registration and resubmit the request
invalid_grant 承認コードまたは PKCE コード検証機能が無効か、有効期限切れです。The authorization code or PKCE code verifier is invalid or has expired. /authorize エンドポイントに対する新しい要求を試し、code_verifier パラメーターが正しいことを確認します。Try a new request to the /authorize endpoint and verify that the code_verifier parameter was correct.
unauthorized_client 認証されたクライアントは、この承認付与の種類を使用する権限がありません。The authenticated client isn't authorized to use this authorization grant type. これは、通常、クライアント アプリケーションが Azure AD に登録されていない、またはユーザーの Azure AD テナントに追加されていないときに発生します。This usually occurs when the client application isn't registered in Azure AD or isn't added to the user's Azure AD tenant. アプリケーションでは、アプリケーションのインストールと Azure AD への追加を求める指示をユーザーに表示できます。The application can prompt the user with instruction for installing the application and adding it to Azure AD.
invalid_client クライアント認証に失敗しました。Client authentication failed. クライアント資格情報が有効ではありません。The client credentials aren't valid. 修正するには、アプリケーション管理者が資格情報を更新します。To fix, the application administrator updates the credentials.
unsupported_grant_type 承認サーバーが承認付与の種類をサポートしていません。The authorization server does not support the authorization grant type. 要求の付与の種類を変更します。Change the grant type in the request. この種のエラーは、開発時にのみ発生し、初期テスト中に検出する必要があります。This type of error should occur only during development and be detected during initial testing.
invalid_resource 対象のリソースは、存在しない、Azure AD が見つけられない、または正しく構成されていないために無効です。The target resource is invalid because it does not exist, Azure AD can't find it, or it's not correctly configured. これは、リソース (存在する場合) がテナントで構成されていないことを示します。This indicates the resource, if it exists, has not been configured in the tenant. アプリケーションでは、アプリケーションのインストールと Azure AD への追加を求める指示をユーザーに表示できます。The application can prompt the user with instruction for installing the application and adding it to Azure AD.
interaction_required これは、OIDC 仕様では /authorize エンドポイントでのみ呼び出されるため、非標準です。要求にはユーザーの操作が必要です。Non-standard, as the OIDC specification calls for this only on the /authorize endpoint.The request requires user interaction. たとえば、追加の認証手順が必要です。For example, an additional authentication step is required. 同じスコープで /authorize 要求を再試行します。Retry the /authorize request with the same scopes.
temporarily_unavailable サーバーが一時的にビジー状態であるため、要求を処理できません。The server is temporarily too busy to handle the request. 短い遅延後に要求を再試行します。Retry the request after a small delay. クライアント アプリケーションは、一時的な状況が原因で応答が遅れることをユーザーに説明する場合があります。The client application might explain to the user that its response is delayed because of a temporary condition.
consent_required 要求にはユーザーの同意が必要です。The request requires user consent. このエラーは、通常、OIDC 仕様に従って /authorize エンドポイントでのみ返されるため、非標準です。This error is non-standard, as it's usually only returned on the /authorize endpoint per OIDC specifications. 要求するアクセス許可がクライアント アプリにないことを示すコード引き換えフローで scope パラメーターが使用された場合に返されます。Returned when a scope parameter was used on the code redemption flow that the client app does not have permission to request. クライアントでは、同意をトリガーするために、正しいスコープの /authorize エンドポイントにユーザーを返信する必要があります。The client should send the user back to the /authorize endpoint with the correct scope in order to trigger consent.
invalid_scope アプリによって要求されたスコープが無効です。The scope requested by the app is invalid. 認証要求のスコープ パラメーターの値を有効な値に更新します。Update the value of the scope parameter in the authentication request to a valid value.

注意

シングル ページ アプリで invalid_request エラーが発生することがあります。これは、クロスオリジン トークンの使用が、"シングル ページ アプリケーション" クライアント タイプにしか許可されないことを示します。Single page apps may receive an invalid_request error indicating that cross-origin token redemption is permitted only for the 'Single-Page Application' client-type. これは、トークンを要求するために使用されるリダイレクト URI が spa リダイレクト URI としてマークされていないことを示します。This indicates that the redirect URI used to request the token has not been marked as a spa redirect URI. このフローを有効にする方法については、アプリケーションの登録手順に関する記事を参照してください。Review the application registration steps on how to enable this flow.

アクセス トークンを使用するUse the access token

access_token を無事取得したら、そのトークンを Authorization ヘッダーに追加することによって、Web API への要求に使用することができます。Now that you've successfully acquired an access_token, you can use the token in requests to web APIs by including it in the Authorization header:

ヒント

ヘッダーを置き換えてください)。Execute this request in Postman! (まず Authorization ヘッダーを置き換えます) Postman でこの要求を実行してみる(Replace the Authorization header first) Try running this request in Postman

GET /v1.0/me/messages
Host: https://graph.microsoft.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

アクセス トークンを更新するRefresh the access token

アクセス トークンは有効期間が短く、期限が切れた後もリソースにアクセスし続けるためにはトークンを更新する必要があります。Access_tokens are short lived, and you must refresh them after they expire to continue accessing resources. アクセス トークンを更新するには、もう一度 POST 要求を /token エンドポイントに送信します。このとき、code の代わりに refresh_token を指定します。You can do so by submitting another POST request to the /token endpoint, this time providing the refresh_token instead of the code. 更新トークンは、クライアントが既に同意を受け取っているすべてのアクセス許可に対して有効です。そのため、scope=mail.read に対する要求で発行された更新トークンを使用して、scope=api://contoso.com/api/UseResource に対する新しいアクセス トークンを要求できます。Refresh tokens are valid for all permissions that your client has already received consent for - thus, a refresh token issued on a request for scope=mail.read can be used to request a new access token for scope=api://contoso.com/api/UseResource.

Web アプリとネイティブ アプリの更新トークンには、指定の有効期間はありません。Refresh tokens for web apps and native apps do not have specified lifetimes. 通常、更新トークンの有効期間は比較的長いです。Typically, the lifetimes of refresh tokens are relatively long. ただし、場合によっては、更新トークンの有効期限が切れる、失効する、または目的の操作のための十分な特権がないことがあります。However, in some cases, refresh tokens expire, are revoked, or lack sufficient privileges for the desired action. クライアント アプリケーションは、トークン発行エンドポイントから返されるエラーを予期して正しく処理する必要があります。Your application needs to expect and handle errors returned by the token issuance endpoint correctly. ただし、シングル ページ アプリでは、24 時間の有効期限を持つトークンが取得され、毎日新しい認証が必要になります。Single page apps, however, get a token with a 24 hour lifetime, requiring a new authentication every day. これは、サード パーティ Cookie が有効になっている場合は iframe でサイレントに実行できますが、Safari などのサード パーティ Cookie がないブラウザーでは、トップ レベルのフレーム (ページ全体のナビゲーションまたはポップアップ) で実行する必要があります。This can be done silently in an iframe when 3rd party cookies are enabled, but must be done in a top level frame (either full page navigation or a popup) in browsers without 3rd party cookies such as Safari.

新しいアクセス トークンを取得するために使用されたときに、更新トークンが失効していないにもかかわらず、古い更新トークンを破棄することを求められます。Although refresh tokens aren't revoked when used to acquire new access tokens, you are expected to discard the old refresh token. OAuth 2.0 仕様には次のようにあります。"承認サーバーで新しい更新トークンが発行される場合があります。この場合、クライアントは古い更新トークンを破棄し、新しい更新トークンに置き換える必要があります。The OAuth 2.0 spec says: "The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. 承認サーバーは新しい更新トークンをクライアントに発行した後に、古い更新トークンを取り消す場合があります。"The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client."

重要

spa として登録されたリダイレクト URI に送信される更新トークンの場合、更新トークンは 24 時間後に期限切れになります。For refresh tokens sent to a redirect URI registered as spa, the refresh token will expire after 24 hours. 初期更新トークンを使用して取得された追加の更新トークンは、その有効期限を引き継ぎます。そのため、24 時間ごとに新しい更新トークンを取得するために、対話型認証を使用して承認コード フローを再実行するようにアプリを準備する必要があります。Additional refresh tokens acquired using the initial refresh token will carry over that expiration time, so apps must be prepared to re-run the authorization code flow using an interactive authentication to get a new refresh token every 24 hours. ユーザーは自分の資格情報を入力する必要はなく、通常は UX も表示されず、アプリケーションをリロードするだけです。しかし、ブラウザーでは、ログイン セッションを表示するために、トップ レベル フレームのログイン ページにアクセスする必要があります。Users do not have to enter their credentials, and will usually not even see any UX, just a reload of your application - but the browser must visit the login page in a top level frame in order to see the login session. これは、サード パーティ Cookie をブロックするブラウザーのプライバシー機能のためです。This is due to privacy features in browsers that block 3rd party cookies.


// Line breaks for legibility only

POST /{tenant}/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=JqQX2PNo9bpM0uEihUPzyrh      // NOTE: Only required for web apps. This secret needs to be URL-Encoded

ヒント

を必ず置き換えてください)。Try executing this request in Postman! (refresh_token を置き換えるのを忘れないでください) Postman でこの要求を実行してみる(Don't forget to replace the refresh_token) Try running this request in Postman

パラメーターParameter TypeType 説明Description
tenant requiredrequired 要求パスの {tenant} の値を使用して、アプリケーションにサインインできるユーザーを制御します。The {tenant} value in the path of the request can be used to control who can sign into the application. 使用できる値は、commonorganizationsconsumers およびテナント識別子です。The allowed values are common, organizations, consumers, and tenant identifiers. 詳細については、 プロトコルの基礎に関するページを参照してください。For more detail, see protocol basics.
client_id requiredrequired Azure portal の [アプリの登録] エクスペリエンスでアプリに割り当てられた アプリケーション (クライアント) IDThe Application (client) ID that the Azure portal – App registrations experience assigned to your app.
grant_type requiredrequired この段階の承認コード フローでは refresh_token を指定する必要があります。Must be refresh_token for this leg of the authorization code flow.
scope requiredrequired スコープのスペース区切りリスト。A space-separated list of scopes. この段階で要求するスコープは、最初の承認コード要求段階で要求したスコープと同じか、またはそのサブセットである必要があります。The scopes requested in this leg must be equivalent to or a subset of the scopes requested in the original authorization_code request leg. この要求で指定したスコープが複数のリソース サーバーにまたがる場合、Microsoft ID プラットフォームからは、最初のスコープで指定したリソースのトークンが返されます。If the scopes specified in this request span multiple resource server, then the Microsoft identity platform will return a token for the resource specified in the first scope. スコープの詳細については、 アクセス許可、同意、スコープに関するページを参照してください。For a more detailed explanation of scopes, refer to permissions, consent, and scopes.
refresh_token requiredrequired フローの第 2 段階で取得した refresh_token。The refresh_token that you acquired in the second leg of the flow.
client_secret Web アプリの場合は必須required for web apps アプリ登録ポータルで作成した、アプリケーションのシークレット。The application secret that you created in the app registration portal for your app. ネイティブ アプリでは使用しないでください。デバイスに client_secret を確実に保存することができません。It should not be used in a native app, because client_secrets can't be reliably stored on devices. Web アプリや Web API では client_secret をサーバー側で安全に保存する機能が備わっており、必ず指定する必要があります。It's required for web apps and web APIs, which have the ability to store the client_secret securely on the server side. このシークレットは URL エンコードする必要があります。This secret needs to be URL-Encoded. 詳細については、URI の一般構文の仕様に関する記事を参照してください。For more information, see the URI Generic Syntax specification.

成功応答Successful response

正常なトークン応答は次のようになります。A successful token response will look like:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "scope": "https%3A%2F%2Fgraph.microsoft.com%2Fmail.read",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}
パラメーターParameter 説明Description
access_token 要求されたアクセス トークン。The requested access token. アプリはこのトークンを使用して、保護されたリソース (Web API など) に対し、本人性を証明することができます。The app can use this token to authenticate to the secured resource, such as a web API.
token_type トークン タイプ値を指定します。Indicates the token type value. Azure AD でサポートされるのは Bearer タイプのみです。The only type that Azure AD supports is Bearer
expires_in アクセス トークンの有効期間 (秒)。How long the access token is valid (in seconds).
scope access_token が有効である範囲。The scopes that the access_token is valid for.
refresh_token 新しい OAuth 2.0 更新トークン。A new OAuth 2.0 refresh token. できるだけ長い時間、更新トークンを有効な状態に維持するためには、この新しく取得した更新トークンで古い更新トークンを置き換える必要があります。You should replace the old refresh token with this newly acquired refresh token to ensure your refresh tokens remain valid for as long as possible.
注: offline_access スコープが要求された場合のみ提供されます。Note: Only provided if offline_access scope was requested.
id_token 無署名の JSON Web トークン (JWT)。An unsigned JSON Web Token (JWT). アプリは、このトークンのセグメントをデコードすることによって、サインインしたユーザーに関する情報を要求することができます。The app can decode the segments of this token to request information about the user who signed in. この値をキャッシュして表示することはできますが、承認やセキュリティ境界の用途でこの値に依存することは避けてください。The app can cache the values and display them, but it should not rely on them for any authorization or security boundaries. id_token の詳細については、id_token referenceを参照してください。For more information about id_tokens, see the id_token reference.
注: openid スコープが要求された場合のみ提供されます。Note: Only provided if openid scope was requested.

エラー応答Error response

{
  "error": "invalid_scope",
  "error_description": "AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope https://foo.microsoft.com/mail.read is not valid.\r\nTrace ID: 255d1aef-8c98-452f-ac51-23d051240864\r\nCorrelation ID: fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7\r\nTimestamp: 2016-01-09 02:02:12Z",
  "error_codes": [
    70011
  ],
  "timestamp": "2016-01-09 02:02:12Z",
  "trace_id": "255d1aef-8c98-452f-ac51-23d051240864",
  "correlation_id": "fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7"
}
パラメーターParameter 説明Description
error 発生したエラーの種類を分類したりエラーに対処したりする際に使用するエラー コード文字列。An error code string that can be used to classify types of errors that occur, and can be used to react to errors.
error_description 認証エラーの根本的な原因を開発者が特定しやすいように記述した具体的なエラー メッセージ。A specific error message that can help a developer identify the root cause of an authentication error.
error_codes 診断に役立つ STS 固有のエラー コードの一覧。A list of STS-specific error codes that can help in diagnostics.
timestamp エラーが発生した時刻。The time at which the error occurred.
trace_id 診断に役立つ、要求の一意の識別子。A unique identifier for the request that can help in diagnostics.
correlation_id コンポーネント間での診断に役立つ、要求の一意の識別子。A unique identifier for the request that can help in diagnostics across components.

エラー コードとクライアントに推奨される対処法については、「トークン エンドポイント エラーのエラー コード」を参照してください。For a description of the error codes and the recommended client action, see Error codes for token endpoint errors.