Microsoft ID プラットフォームと暗黙的な許可のフローMicrosoft identity platform and Implicit grant flow

Microsoft ID プラットフォーム エンドポイントを使ったシングル ページ アプリでは、ユーザーは、Microsoft の個人アカウントと職場/学校アカウントのどちらでもサインインできます。With the Microsoft identity platform endpoint, you can sign users into your single-page apps with both personal and work or school accounts from Microsoft. シングル ページ アプリなどの主にブラウザーで実行される JavaScript アプリには、認証に関して重要な課題があります。Single-page and other JavaScript apps that run primarily in a browser face a few interesting challenges when it comes to authentication:

  • これらのアプリのセキュリティ特性は、従来のサーバーベースの Web アプリケーションとは大きく異なります。The security characteristics of these apps are significantly different from traditional server-based web applications.
  • 多くの承認サーバーや ID プロバイダーでは、CORS 要求をサポートしていません。Many authorization servers and identity providers do not support CORS requests.
  • アプリからブラウザーにフル ページがリダイレクトされると、ユーザー エクスペリエンスに大きな悪影響が及びます。Full page browser redirects away from the app become particularly invasive to the user experience.

これらのアプリケーション (Angular、Ember.js、React.js など) の場合、Microsoft ID プラットフォームでは OAuth 2.0 の暗黙的な許可のフローをサポートしています。For these applications (Angular, Ember.js, React.js, and so on), Microsoft identity platform supports the OAuth 2.0 Implicit Grant flow. この暗黙的フローは、OAuth 2.0 仕様で規定されています。The implicit flow is described in the OAuth 2.0 Specification. 主な利点は、バックエンド サーバーとの資格情報交換を実行しなくても、アプリが Microsoft ID プラットフォームからトークンを取得できることです。Its primary benefit is that it allows the app to get tokens from Microsoft identity platform without performing a backend server credential exchange. これにより、アプリは、ユーザーのサインイン、セッションの維持、他の Web API へのトークンの取得をすべてクライアント JavaScript コード内で実行できます。This allows the app to sign in the user, maintain session, and get tokens to other web APIs all within the client JavaScript code. 暗黙的フローを使用する際に考慮が必要なセキュリティに関する重要事項がいくつかあります。具体的には、クライアントユーザーの偽装に関する事項です。There are a few important security considerations to take into account when using the implicit flow specifically around client and user impersonation.

この記事では、アプリケーションでプロトコルに対して直接プログラミングする方法について説明します。This article describes how to program directly against the protocol in your application. 可能な場合は、トークンを取得してセキュリティで保護された 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.

シングル ページ アプリケーションでライブラリを使用せずに、自分でプロトコル メッセージを送信する場合は、次の一般的な手順を実行してください。However, if you prefer not to use a library in your single-page app and send protocol messages yourself, follow the general steps below.

OAuth2 の暗黙的な許可の適切なシナリオSuitable scenarios for the OAuth2 implicit grant

OAuth2 の仕様で明らかにされているとおり、暗黙的な許可はユーザー エージェント アプリケーション (つまり、ブラウザー内で実行される JavaScript アプリケーション) を実現にするために考案されました。The OAuth2 specification declares that the implicit grant has been devised to enable user-agent applications – that is to say, JavaScript applications executing within a browser. このようなアプリケーションに特徴的なのは、サーバー リソース (通常は Web API) にアクセスするため、そしてアプリケーション ユーザー エクスペリエンスを適宜更新するために、JavaScript コードが使用されるという点です。The defining characteristic of such applications is that JavaScript code is used for accessing server resources (typically a web API) and for updating the application user experience accordingly. Gmail や Outlook Web Access のようなアプリケーションを考えてみてください。受信トレイからメッセージを選択したときに、メッセージ視覚化パネルのみが変更されて新しい選択内容が表示され、ページの残りの部分は変更されません。Think of applications like Gmail or Outlook Web Access: when you select a message from your inbox, only the message visualization panel changes to display the new selection, while the rest of the page remains unmodified. この特性は、ユーザー操作ごとにページ全体がポストバックされ、新しいサーバー応答によりページ全体がレンダリングされる、従来のリダイレクト ベースの Web アプリとは対照的です。This characteristic is in contrast with traditional redirect-based Web apps, where every user interaction results in a full page postback and a full page rendering of the new server response.

JavaScript ベースのアプローチを最大限に活用するアプリケーションは、シングルページ アプリケーション (SPA) と呼ばれます。Applications that take the JavaScript based approach to its extreme are called single-page applications, or SPAs. これらのアプリケーションは最初の HTML ページと関連する JavaScript のみを提供し、後続のすべてのやりとりは JavaScript を介して実行される Web API 呼び出しによって行われるという考えです。The idea is that these applications only serve an initial HTML page and associated JavaScript, with all subsequent interactions being driven by web API calls performed via JavaScript. ただし、ハイブリッド アプローチも珍しくはありません。このアプローチでは、アプリケーションはほとんどの場合ポストバックに基づきますが、JS 呼び出しを実行することもあります。暗黙的フローの使用方法に関する議論は、ハイブリッド アプローチにも当てはまります。However, hybrid approaches, where the application is mostly postback-driven but performs occasional JS calls, are not uncommon – the discussion about implicit flow usage is relevant for those as well.

リダイレクト ベースのアプリケーションでは通常、Cookie を使用して要求をセキュリティ保護します。ただし、このアプローチは JavaScript アプリケーションではうまくいきません。Redirect-based applications typically secure their requests via cookies, however, that approach does not work as well for JavaScript applications. Cookie はその生成元のドメインに対してのみ機能しますが、JavaScript 呼び出しは他のドメインにリダイレクトされる可能性があるためです。Cookies only work against the domain they have been generated for, while JavaScript calls might be directed toward other domains. これは実際、多くの場合に発生します。Microsoft Graph API、Office API、Azure API を呼び出すアプリケーションを考えてみてください。これらの API はいずれもアプリケーションが動作するドメインの外部にあります。In fact, that will frequently be the case: think of applications invoking Microsoft Graph API, Office API, Azure API – all residing outside the domain from where the application is served. JavaScript アプリケーションでは、バックエンドを一切持たず、サード パーティの Web API に 100% 依存してビジネス機能を実装する傾向が強まっています。A growing trend for JavaScript applications is to have no backend at all, relying 100% on third party web APIs to implement their business function.

現時点で推奨される Web API 呼び出しの保護方法は、OAuth2 べアラー トークンのアプローチを使用する方法です。このアプローチでは、すべての呼び出しに OAuth2 のアクセス トークンが付随します。Currently, the preferred method of protecting calls to a web API is to use the OAuth2 bearer token approach, where every call is accompanied by an OAuth2 access token. Web API は受信したアクセス トークンを調べ、アクセス トークン内に必要なスコープが見つかった場合に、要求された操作へのアクセス許可を与えます。The web API examines the incoming access token and, if it finds in it the necessary scopes, it grants access to the requested operation. 暗黙的フローは、JavaScript アプリケーションが Web API 用のアクセス トークンを取得するための便利なメカニズムを提供するものであり、Cookie に関してさまざまなメリットがあります。The implicit flow provides a convenient mechanism for JavaScript applications to obtain access tokens for a web API, offering numerous advantages in respect to cookies:

  • クロス オリジン呼び出しをしなくても、トークンを確実に取得できます。トークンが返されるリダイレクト URI の登録が必須であるため、トークンが置換されないことが保証されます。Tokens can be reliably obtained without any need for cross origin calls – mandatory registration of the redirect URI to which tokens are return guarantees that tokens are not displaced
  • JavaScript アプリケーションは、ドメインの制限なしに、対象とする Web API の数だけ、必要な数のアクセス トークンを取得できます。JavaScript applications can obtain as many access tokens as they need, for as many web APIs they target – with no restriction on domains
  • セッションやローカル ストレージなどの HTML5 機能ではトークンのキャッシュと有効期間管理にフル コントロールを許可しますが、Cookie の管理はアプリにとって非透過的です。HTML5 features like session or local storage grant full control over token caching and lifetime management, whereas cookies management is opaque to the app
  • アクセス トークンはクロスサイト リクエスト フォージェリ (CSRF) 攻撃をあまり受けませんAccess tokens aren't susceptible to Cross-site request forgery (CSRF) attacks

暗黙的な許可フローでは、主にセキュリティ上の理由から、更新トークンを発行しません。The implicit grant flow does not issue refresh tokens, mostly for security reasons. 更新トークンはアクセス トークンほどスコープが狭義ではないため、多くの権限を付与すると、リークされた場合のダメージが大きくなります。暗黙的フローでは、トークンは URL の形式で配信されるため、傍受されるリスクが認証コード付与よりも高くなります。A refresh token isn't as narrowly scoped as access tokens, granting far more power hence inflicting far more damage in case it is leaked out. In the implicit flow, tokens are delivered in the URL, hence the risk of interception is higher than in the authorization code grant.

ただし、JavaScript アプリケーションには、アクセス トークンを更新するために廃棄する際、ユーザーに資格情報を繰り返し求めない別のメカニズムがあります。However, a JavaScript application has another mechanism at its disposal for renewing access tokens without repeatedly prompting the user for credentials. アプリケーションは非表示の iframe を使用して、Azure AD の承認エンドポイントに対して新しいトークン要求を実行します。ブラウザーが Azure AD ドメインに対してアクティブなセッション (読み取り: セッション Cookie あり) を持っている限り、この認証要求は正常に行われ、ユーザーの操作は必要ありません。The application can use a hidden iframe to perform new token requests against the authorization endpoint of Azure AD: as long as the browser still has an active session (read: has a session cookie) against the Azure AD domain, the authentication request can successfully occur without any need for user interaction.

このモデルにより、JavaScript アプリケーションは独立してアクセス トークンを更新できるようになるほか、(ユーザーが事前に同意している場合は) 新しい API の新しいアクセス トークンを取得することさえ可能になります。This model grants the JavaScript application the ability to independently renew access tokens and even acquire new ones for a new API (provided that the user previously consented for them). これにより、更新トークンなどの高価値のアーティファクトを取得、管理、保護する負担を増やさずに済みます。This avoids the added burden of acquiring, maintaining, and protecting a high value artifact such as a refresh token. サイレント更新を可能にするアーティファクト、Azure AD のセッション Cookie は、アプリケーションの外部で管理されます。The artifact that makes the silent renewal possible, the Azure AD session cookie, is managed outside of the application. このアプローチのもう 1 つの利点は、いずれかのブラウザー タブで実行されている、Azure AD にサインインしているいずれかのアプリケーションを使用して、ユーザーが Azure AD からサインアウトできることです。Another advantage of this approach is a user can sign out from Azure AD, using any of the applications signed into Azure AD, running in any of the browser tabs. サインアウトすると、Azure AD のセッション Cookie が削除され、JavaScript アプリケーションは自動的に、サインアウトしたユーザーのトークンを更新できなくなります。This results in the deletion of the Azure AD session cookie, and the JavaScript application will automatically lose the ability to renew tokens for the signed out user.

暗黙的な許可に適切なアプリIs the implicit grant suitable for my app?

暗黙的な付与は他の付与よりリスクが大きくなります。また、注意を払うべき領域が詳しく記録されます (たとえば、「Misuse of Access Token to Impersonate Resource Owner in Implicit Flow (暗黙的フローでの偽装リソース所有者に対するアクセス トークンの誤用)」や「OAuth 2.0 Threat Model and Security Considerations (OAuth 2.0 の脅威モデルとセキュリティの考慮事項)」)。The implicit grant presents more risks than other grants, and the areas you need to pay attention to are well documented (for example, Misuse of Access Token to Impersonate Resource Owner in Implicit Flow and OAuth 2.0 Threat Model and Security Considerations). ただし、よりリスクが高いプロファイルは、多くの場合、リモート リソースによってブラウザーに対して処理されるアクティブ コードを実行するアプリケーションを有効にしなければならないという事実に起因します。However, the higher risk profile is largely due to the fact that it is meant to enable applications that execute active code, served by a remote resource to a browser. SPA アーキテクチャを計画していて、バックエンド コンポーネントがない場合、または JavaScript を使用して Web API を呼び出そうとしている場合は、トークンの取得に暗黙的フローを使用することをお勧めします。If you are planning an SPA architecture, have no backend components or intend to invoke a web API via JavaScript, use of the implicit flow for token acquisition is recommended.

アプリケーションがネイティブ クライアントの場合は、暗黙的フローはあまり向いていません。If your application is a native client, the implicit flow isn't a great fit. ネイティブ クライアントのコンテキストには Azure AD のセッション Cookie がないので、アプリケーションには存続期間の長いセッションを維持する手段がありません。The absence of the Azure AD session cookie in the context of a native client deprives your application from the means of maintaining a long lived session. つまり、アプリケーションは新しいリソースのアクセス トークンを取得する場合、繰り返しユーザーに求めることになります。Which means your application will repeatedly prompt the user when obtaining access tokens for new resources.

バックエンドを含む Web アプリケーションを開発しており、そのバックエンド コードから API を使用する場合も、暗黙的フローはあまり向いていません。If you are developing a Web application that includes a backend, and consuming an API from its backend code, the implicit flow is also not a good fit. 他の方法の方がはるかに便利です。Other grants give you far more power. たとえば、OAuth2 クライアント資格情報付与では、ユーザー委任とは対照的に、アプリケーション自体に割り当てられているアクセス許可を反映したトークンを取得できます。For example, the OAuth2 client credentials grant provides the ability to obtain tokens that reflect the permissions assigned to the application itself, as opposed to user delegations. これは、ユーザーがセッションにアクティブに関与していない場合などでも、クライアントがプログラムによるリソース アクセスを維持できることを意味します。This means the client has the ability to maintain programmatic access to resources even when a user is not actively engaged in a session, and so on. メリットはそれだけにとどまりません。このような付与では、セキュリティ保証が強化されます。Not only that, but such grants give higher security guarantees. たとえば、アクセス トークンがユーザーのブラウザーを通過せず、ブラウザーの履歴に保存されるなどのリスクがありません。For instance, access tokens never transit through the user browser, they don't risk being saved in the browser history, and so on. また、クライアント アプリケーションは、トークンの要求時に強力な認証を実行できます。The client application can also perform strong authentication when requesting a token.

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

次の図は、暗黙的なサインイン フローの全体像を示しています。各手順については、この後のセクションで詳しく説明します。The following diagram shows what the entire implicit sign-in flow looks like and the sections that follow describe each step in more detail.

暗黙的なサインイン フローを示す図

サインイン要求を送信するSend the sign-in request

最初にユーザーをアプリにサインインするために、OpenID Connect 認証要求を送信し、Microsoft ID プラットフォーム エンドポイントから id_token を取得します。To initially sign the user into your app, you can send an OpenID Connect authentication request and get an id_token from the Microsoft identity platform endpoint.

重要

ID トークンおよびアクセス トークンを正しく要求するには、Azure portal の [アプリの登録] ページのアプリ登録で、 [暗黙の付与] セクションの [ID トークン] および [アクセス トークン] を選択して、対応する暗黙的な許可フローを有効にする必要があります。To successfully request an ID token and/or an access token, the app registration in the Azure portal - App registrations page must have the corresponding implicit grant flow enabled, by selecting ID tokens and.or access tokens under the Implicit grant section. それが有効でない場合は、unsupported_response エラー The provided value for the input parameter 'response_type' is not allowed for this client.Expected value is 'code' (入力パラメーター 'response_type' に入力された値はこのクライアントで許可されません。入力できる値は 'code' です。) が返されますIf it's not enabled, an unsupported_response error will be returned: The provided value for the input parameter 'response_type' is not allowed for this client. Expected value is 'code'

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid
&response_mode=fragment
&state=12345
&nonce=678910

ヒント

暗黙的フローを使用したサインインをテストするには、https://login.microsoftonline.com/common/oauth2/v2.0/authorize.. をクリックします。サインイン後、ブラウザーは https://localhost/myapp/ にリダイレクトされ、アドレス バーに id_token が含まれた状態になります。To test signing in using the implicit flow, click https://login.microsoftonline.com/common/oauth2/v2.0/authorize... After signing in, your browser should be redirected to https://localhost/myapp/ with an id_token in the address bar.

パラメーター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 の [アプリの登録] ページでアプリに割り当てられたアプリケーション (クライアント) ID。The Application (client) ID that the Azure portal - App registrations page assigned to your app.
response_type requiredrequired OpenID Connect サインインでは、 id_token を指定する必要があります。Must include id_token for OpenID Connect sign-in. response_type token が含まれる場合もあります。It may also include the response_type token. ここで token を使用すると、アプリでは承認エンドポイントへ 2 度目の要求を行うことなく、承認エンドポイントからアクセス トークンをすぐに受け取ることができます。Using token here will allow your app to receive an access token immediately from the authorize endpoint without having to make a second request to the authorize endpoint. token response_type を使用する場合、scope パラメーターには、トークンを発行するリソースを示すスコープを含める必要があります (たとえば、Microsoft Graph では user.read)。If you use the token response_type, the scope parameter must contain a scope indicating which resource to issue the token for (for example, user.read on Microsoft Graph).
redirect_uri 推奨recommended アプリ の 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.
scope requiredrequired スコープのスペース区切りリスト。A space-separated list of scopes. OpenID Connect (id_tokens) では、スコープとして openid を指定する必要があります。このスコープは、承認 UI で "サインイン" アクセス許可に変換されます。For OpenID Connect (id_tokens), it must include the scope openid, which translates to the "Sign you in" permission in the consent UI. 必要に応じて、その他のユーザー データにアクセスするために email および profile スコープを含めることも可能です。Optionally you may also want to include the email and profile scopes for gaining access to additional user data. アクセス トークンを要求する場合、さまざまなリソースに対する同意を求めるこの要求に、他のスコープが含まれていてもかまいません。You may also include other scopes in this request for requesting consent to various resources, if an access token is requested.
response_mode 省略可能optional 結果として得られたトークンをアプリに返す際に使用するメソッドを指定します。Specifies the method that should be used to send the resulting token back to your app. 既定値は、アクセス トークンだけのクエリ (ただし、要求に id_token が含まれている場合はフラグメント) です。Defaults to query for just an access token, but fragment if the request includes an id_token.
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 state is also used to encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on.
nonce requiredrequired 要求に追加する (アプリによって生成された) 値。この値が、最終的な 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. Id_token が要求された場合のみ必須です。Only required when an id_token is requested.
prompt 省略可能optional ユーザーとの必要な対話の種類を指定します。Indicates the type of user interaction that is required. 現時点で有効な値は 'login'、'none'、'select_account'、'consent' だけです。The only valid values at this time are 'login', 'none', 'select_account', 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 プラットフォーム エンドポイントからエラーが返されます。If the request can't be completed silently via single-sign on, the Microsoft identity platform endpoint will return an error. prompt=select_account は、ユーザーを、セッションで記憶されているすべてのアカウントが表示されるアカウント ピッカーに送ります。prompt=select_account sends the user to an account picker where all of the accounts remembered in the session will appear. 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.
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 これが含まれていると、ユーザーがサインイン ページで実行する電子メール ベースの検出プロセスがスキップされ、多少効率化されたユーザー エクスペリエンスが提供されます。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. これは、1 つのテナントで動作する基幹業務アプリで一般的に使用され、アプリでは特定のテナント内のドメイン名が提供されます。This is commonly used for Line of Business apps that operate in a single tenant, where they will provide a domain name within a given tenant. これにより、ユーザーはそのテナントのフェデレーション プロバイダーに転送されます。This will forward the user to the federation provider for that tenant. ゲストはこのアプリケーションにサインインできなくなることに注意してください。Note that this will prevent guests from signing into this application.

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

ユーザー本人であることを証明書し、同意の許可を与えると、Microsoft ID プラットフォーム エンドポイントは response_mode パラメーターで指定された方法を使用して、指定された redirect_uri でアプリに応答を返します。Once the user authenticates and grants consent, the Microsoft identity platform endpoint 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=fragmentresponse_type=id_token+token を使用した成功応答は、次のようになります (読みやすいように改行してあります)。A successful response using response_mode=fragment and response_type=id_token+token looks like the following (with line breaks for legibility):

GET https://localhost/myapp/#
&token_type=Bearer
&expires_in=3599
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=12345
パラメーターParameter 説明Description
access_token response_typetoken が含まれる場合に含まれます。Included if response_type includes token. アプリが要求したアクセス トークン。The access token that the app requested. アクセス トークンはデコードしないようにする必要があります。そうしないと、検証した場合に不透明な文字列として扱われます。The access token shouldn't be decoded or otherwise inspected, it should be treated as an opaque string.
token_type response_typetoken が含まれる場合に含まれます。Included if response_type includes token. 常に Bearer になります。Will always be Bearer.
expires_in response_typetoken が含まれる場合に含まれます。Included if response_type includes token. キャッシュ用に有効なトークンの秒数を示します。Indicates the number of seconds the token is valid, for caching purposes.
scope response_typetoken が含まれる場合に含まれます。Included if response_type includes token. access_token が有効なスコープを示します。Indicates the scope(s) for which the access_token will be valid. 要求されたスコープをユーザーに適用できなかった場合 (ログインのために個人アカウントが使用されているときに Azure AD のみのスコープが要求された場合)、必ずしもすべてのスコープが含まれないことがあります。May not include all of the scopes requested, if they were not applicable to the user (in the case of Azure AD-only scopes being requested when a personal account is used to log in).
id_token 署名付き JSON Web トークン (JWT)。A signed 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 shouldn't 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.
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.

エラー応答Error response

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

GET https://localhost/myapp/#
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.

バックグラウンドでサイレントにアクセス トークンを取得するGetting access tokens silently in the background

これでユーザーをシングルページ アプリにサインインさせたので、Microsoft Graph などの Microsoft ID プラットフォームによってセキュリティ保護された Web API を呼び出すためのアクセス トークンをサイレントに取得できます。Now that you've signed the user into your single-page app, you can silently get access tokens for calling web APIs secured by Microsoft identity platform, such as the Microsoft Graph. このメソッドを使用すると、token response_type を使用してトークンを既に取得している場合でも、再度サインインするためにユーザーをリダイレクトする必要なく、その他のリソースのトークンを取得できます。Even if you already received a token using the token response_type, you can use this method to acquire tokens to additional resources without having to redirect the user to sign in again.

通常の OpenID Connect/OAuth フローでは、これは Microsoft ID プラットフォームの /token エンドポイントに要求を発行することによって行います。In the normal OpenID Connect/OAuth flow, you would do this by making a request to the Microsoft identity platform /token endpoint. ただし、Microsoft ID プラットフォーム エンドポイントは CORS 要求をサポートしていないため、AJAX 呼び出しによってトークンを取得または更新することは不可能です。However, the Microsoft identity platform endpoint does not support CORS requests, so making AJAX calls to get and refresh tokens is out of the question. 代わりに、非表示の iframe で暗黙的フローを使用して、他の Web API 用の新しいトークンを取得できます。Instead, you can use the implicit flow in a hidden iframe to get new tokens for other web APIs:

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fuser.read
&response_mode=fragment
&state=12345
&nonce=678910
&prompt=none
&login_hint=myuser@mycompany.com

URL のクエリ パラメーターの詳細については、「サインイン要求を送信する」を参照してください。For details on the query parameters in the URL, see send the sign in request.

ヒント

以下の要求をコピーしてブラウザー タブに貼り付けてみてくださいTry copy & pasting the below request into a browser tab! (login_hint の値をユーザーの正しい値に置き換えてください)。(Don't forget to replace the login_hint values with the correct value for your user)

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=token&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&scope=https%3A%2F%2Fgraph.microsoft.com%2Fuser.read&response_mode=fragment&state=12345&nonce=678910&prompt=none&login_hint={your-username}

prompt=none パラメーターに応じて、要求はすぐに成功または失敗し、アプリケーションに戻ります。Thanks to the prompt=none parameter, this request will either succeed or fail immediately and return to your application. 成功すると、response_mode パラメーターで指定された方法を使用して、指定された redirect_uri でアプリに応答が送信されます。A successful response will be sent to your app at the indicated redirect_uri, using the method specified in the response_mode parameter.

成功応答Successful response

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

GET https://localhost/myapp/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=12345
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fdirectory.read
パラメーターParameter 説明Description
access_token response_typetoken が含まれる場合に含まれます。Included if response_type includes token. この場合は、Microsoft Graph 用にアプリケーションが要求したアクセス トークンです。The access token that the app requested, in this case for the Microsoft Graph. アクセス トークンはデコードしないようにする必要があります。そうしないと、検証した場合に不透明な文字列として扱われます。The access token shouldn't be decoded or otherwise inspected, it should be treated as an opaque string.
token_type 常に Bearer になります。Will always be Bearer.
expires_in キャッシュ用に有効なトークンの秒数を示します。Indicates the number of seconds the token is valid, for caching purposes.
scope access_token が有効なスコープを示します。Indicates the scope(s) for which the access_token will be valid. 要求されたスコープをユーザーに適用できなかった場合 (ログインのために個人アカウントが使用されているときに Azure AD のみのスコープが要求された場合)、必ずしもすべてのスコープが含まれないことがあります。May not include all of the scopes requested, if they were not applicable to the user (in the case of Azure AD-only scopes being requested when a personal account is used to log in).
id_token 署名付き JSON Web トークン (JWT)。A signed JSON Web Token (JWT). response_typeid_token が含まれる場合に含まれます。Included if response_type includes id_token. アプリは、このトークンのセグメントをデコードすることによって、サインインしたユーザーに関する情報を要求することができます。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 shouldn't rely on them for any authorization or security boundaries. id_token の詳細については、id_token のリファレンスを参照してください。For more information about id_tokens, see the id_token reference.
注: openid スコープが要求された場合のみ提供されます。Note: Only provided if openid scope was requested.
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.

エラー応答Error response

アプリ側で適切に処理できるように、 redirect_uri にエラーの応答が送信される場合もあります。Error responses may also be sent to the redirect_uri so the app can handle them appropriately. prompt=noneの場合、予期されるエラーは次のようになります。In the case of prompt=none, an expected error will be:

GET https://localhost/myapp/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
パラメーター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.

Iframe 要求でこのエラーを受信した場合、ユーザーは対話形式でもう一度サインインして新しいトークンを取得する必要があります。If you receive this error in the iframe request, the user must interactively sign in again to retrieve a new token. この場合は、アプリケーションに適した任意の方法で処理できます。You can choose to handle this case in whatever way makes sense for your application.

トークンを更新するRefreshing tokens

暗黙的な付与では、更新トークンが与えられません。The implicit grant does not provide refresh tokens. id_tokenaccess_token はどちらも短時間で期限切れになるため、トークンを定期的に更新するようにアプリを準備しておく必要があります。Both id_tokens and access_tokens will expire after a short period of time, so your app must be prepared to refresh these tokens periodically. どちらの種類のトークンを更新する場合も、ID プラットフォームの動作を制御するための prompt=none パラメーターを使用して、上と同じ非表示の iframe 要求を実行できます。To refresh either type of token, you can perform the same hidden iframe request from above using the prompt=none parameter to control the identity platform's behavior. 新しい id_token を受け取りたい場合は、response_typeid_tokenscope=openid に加えて、nonce パラメーターも使用してください。If you want to receive a new id_token, be sure to use id_token in the response_type and scope=openid, as well as a nonce parameter.

サインアウト要求を送信するSend a sign out request

OpenID Connect end_session_endpoint を使用すると、アプリから Microsoft ID プラットフォーム エンドポイントへの要求をエンド ユーザーのセッションに送信し、Microsoft ID プラットフォーム エンドポイントによって設定された Cookie をクリアできます。The OpenID Connect end_session_endpoint allows your app to send a request to the Microsoft identity platform endpoint to end a user's session and clear cookies set by the Microsoft identity platform endpoint. ユーザーが Web アプリケーションから完全にサインアウトするには、アプリがユーザーとのセッションを終了し (通常、トークン キャッシュをクリアするか Cookie を切断する)、ブラウザーを以下にリダイレクトする必要があります。To fully sign a user out of a web application, your app should end its own session with the user (usually by clearing a token cache or dropping cookies), and then redirect the browser to:

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/logout?post_logout_redirect_uri=https://localhost/myapp/
パラメーター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.
post_logout_redirect_uri 推奨recommended ログアウト完了後にユーザーが戻る URL。The URL that the user should be returned to after logout completes. この値は、アプリケーションに登録されているリダイレクト URI のいずれかと一致する必要があります。This value must match one of the redirect URIs registered for the application. 一致しない場合、Microsoft ID プラットフォーム エンドポイントにより汎用メッセージが表示されます。If not included, the user will be shown a generic message by the Microsoft identity platform endpoint.

次のステップNext steps