OpenID Connect と Azure Active Directory を使用する Web アプリケーションへのアクセスの承認Authorize access to web applications using OpenID Connect and Azure Active Directory

OpenID Connect は、OAuth 2.0 プロトコル上に構築された単純な ID 層です。OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol. OAuth 2.0 では保護されたリソースにアクセスするためのアクセス トークンを取得して使用するためのメカニズムを定義しますが、ID 情報を提供するための標準的な方法は定義しません。OAuth 2.0 defines mechanisms to obtain and use access tokens to access protected resources, but they do not define standard methods to provide identity information. OpenID Connect は、OAuth 2.0 承認プロセスの拡張機能として認証を実装します。OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. エンド ユーザーに関する情報を id_token の形式で提供し、これを使ってユーザーの ID を検証し、ユーザーに関する基本的なプロファイル情報を提供します。It provides information about the end user in the form of an id_token that verifies the identity of the user and provides basic profile information about the user.

OpenID Connect は、サーバーでホストされ、ブラウザーでアクセスされる Web アプリケーションを構築している場合に推奨されます。OpenID Connect is our recommendation if you are building a web application that is hosted on a server and accessed via a browser.

AD テナントへのアプリケーションの登録Register your application with your AD tenant

まず、Azure Active Directory (Azure AD) テナントにアプリケーションを登録する必要があります。First, register your application with your Azure Active Directory (Azure AD) tenant. これにより、アプリケーションのアプリケーション ID を取得でき、トークンを受信できるようになります。This will give you an Application ID for your application, as well as enable it to receive tokens.

  1. Azure Portal にサインインします。Sign in to the Azure portal.

  2. ページ右上隅にあるアカウントを選択し、 [ディレクトリの切り替え] ナビゲーションを選択してから、適切なテナントを選択して、Azure AD テナントを選択します。Choose your Azure AD tenant by selecting your account in the top right corner of the page, followed by selecting the Switch Directory navigation and then selecting the appropriate tenant.

    • アカウントの下の Azure AD テナントが 1 つのみの場合、または適切な Azure AD テナントを既に選択している場合は、この手順をスキップします。Skip this step if you only have one Azure AD tenant under your account, or if you've already selected the appropriate Azure AD tenant.
  3. Azure portal で、Azure Active Directory を検索して選択します。In the Azure portal, search for and select Azure Active Directory.

  4. [Azure Active Directory] の左側のメニューで、 [アプリの登録] を選択し、 [新しい登録] を選択します。In the Azure Active Directory left menu, select App Registrations, and then select New registration.

  5. 画面の指示に従い、新しいアプリケーションを作成します。Follow the prompts and create a new application. このチュートリアルでは、Web アプリケーションであるかパブリック クライアント (モバイルとデスクトップ) アプリケーションであるかは重要ではありませんが、Web アプリケーションまたはパブリック クライアント アプリケーションの具体的な例を確認するには、クイック スタートをご覧ください。It doesn't matter if it is a web application or a public client (mobile & desktop) application for this tutorial, but if you'd like specific examples for web applications or public client applications, check out our quickstarts.

    • [名前] はアプリケーションの名前で、エンド ユーザーがアプリケーションの機能を把握できるような名前を設定します。Name is the application name and describes your application to end users.
    • [サポートされているアカウントの種類] で、 [Accounts in any organizational directory and personal Microsoft accounts](任意の組織のディレクトリ内のアカウントと個人用の Microsoft アカウント) を選択します。Under Supported account types, select Accounts in any organizational directory and personal Microsoft accounts.
    • [リダイレクト URI] を指定します。Provide the Redirect URI. Web アプリケーションの場合、これはユーザーのサインイン場所となるアプリのベース URL です。For web applications, this is the base URL of your app where users can sign in. たとえば、「 http://localhost:12345 」のように入力します。For example, http://localhost:12345. パブリック クライアント (モバイルとデスクトップ) の場合、Azure AD はこれを使用してトークン応答を返します。For public client (mobile & desktop), Azure AD uses it to return token responses. アプリケーション固有の値を入力します。Enter a value specific to your application. たとえば、「 http://MyFirstAADApp 」のように入力します。For example, http://MyFirstAADApp.
  6. 登録が完了すると、Azure AD により、アプリケーションに一意のクライアント ID (アプリケーション ID) が割り当てられます。Once you've completed registration, Azure AD will assign your application a unique client identifier (the Application ID). この値は次のセクションで必要になるので、アプリケーション ページからコピーします。You need this value in the next sections, so copy it from the application page.

  7. Azure portal でアプリケーションを見つけるには、 [アプリの登録] を選択し、 [アプリケーションをすべて表示] を選択します。To find your application in the Azure portal, select App registrations, and then select View all applications.

OpenID Connect を使用する認証フローAuthentication flow using OpenID Connect

最も基本的なサインイン フローには次の手順が含まれています。各手順についてはこの後詳しく説明します。The most basic sign-in flow contains the following steps - each of them is described in detail below.

OpenID Connect 認証フロー

OpenID Connect のメタデータ ドキュメントOpenID Connect metadata document

OpenID Connect はメタデータ ドキュメントについて説明するものです。メタデータ ドキュメントは、アプリがサインインを実行するために必要な情報の大半を含んでいます。OpenID Connect describes a metadata document that contains most of the information required for an app to perform sign-in. これには、使用する URL、サービスの公開署名キーの場所などの情報が含まれます。This includes information such as the URLs to use and the location of the service's public signing keys. OpenID Connect のメタデータ ドキュメントは、次の場所にあります。The OpenID Connect metadata document can be found at:

https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration

メタデータは、単純な JavaScript Object Notation (JSON) ドキュメントです。The metadata is a simple JavaScript Object Notation (JSON) document. 例については、次のスニペットを参照してください。See the following snippet for an example. スニペットの内容については、OpenID Connect の仕様に詳しく記載されています。The snippet's contents are fully described in the OpenID Connect specification. 上記の {tenant} に common ではなくテナント ID を指定すると、JSON オブジェクトのテナント固有の URI が返されます。Note that providing a tenant ID rather than common in place of {tenant} above will result in tenant-specific URIs in the JSON object returned.

{
    "authorization_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/authorize",
    "token_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/token",
    "token_endpoint_auth_methods_supported":
    [
        "client_secret_post",
        "private_key_jwt",
        "client_secret_basic"
    ],
    "jwks_uri": "https://login.microsoftonline.com/common/discovery/keys"
    "userinfo_endpoint":"https://login.microsoftonline.com/{tenant}/openid/userinfo",
    ...
}

claims-mapping 機能を使用した結果として、アプリにカスタム署名キーがある場合は、アプリの署名キー情報をポイントする jwks_uri を取得するために、アプリ ID を含む appid クエリ パラメーターを追加する必要があります。If your app has custom signing keys as a result of using the claims-mapping feature, you must append an appid query parameter containing the app ID in order to get a jwks_uri pointing to your app's signing key information. 例: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e には、https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391ejwks_uri が含まれます。For example: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e contains a jwks_uri of https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e.

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

Web アプリケーションでユーザーを認証する必要がある場合、ユーザーを /authorize エンドポイントにリダイレクトさせる必要があります。When your web application needs to authenticate the user, it must direct the user to the /authorize endpoint. この要求は、 OAuth 2.0 承認コード フローの最初の部分に似ていますが、いくつかの重要な違いがあります。This request is similar to the first leg of the OAuth 2.0 Authorization Code Flow, with a few important distinctions:

  • 要求の scope パラメーターにはスコープ openid が含まれる必要があります。The request must include the scope openid in the scope parameter.
  • response_type パラメーターには、id_token が設定されている必要があります。The response_type parameter must include id_token.
  • 要求には nonce パラメーターが含まれる必要があります。The request must include the nonce parameter.

したがって、要求の例は次のようになります。So a sample request would look like this:

// Line breaks for legibility only

GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%3a12345
&response_mode=form_post
&scope=openid
&state=12345
&nonce=7362CAEA-9CA5-4B43-9BA3-34D7C303EBA7
パラメーターParameter 説明Description
tenanttenant 必須required 要求パスの {tenant} の値を使用して、アプリケーションにサインインできるユーザーを制御します。The {tenant} value in the path of the request can be used to control who can sign into the application. 使用できる値はテナント ID です。たとえば、8eaef023-2b34-4da1-9baa-8bc8c9d6a490contoso.onmicrosoft.com または common (テナント独立のトークンの場合) ですThe allowed values are tenant identifiers, for example, 8eaef023-2b34-4da1-9baa-8bc8c9d6a490 or contoso.onmicrosoft.com or common for tenant-independent tokens
client_idclient_id 必須required Azure AD への登録時にアプリに割り当てられたアプリケーション ID。The Application ID assigned to your app when you registered it with Azure AD. これは、Azure Portal で確認できます。You can find this in the Azure portal. [Azure Active Directory][アプリの登録] の順にクリックし、アプリケーションを選択して、アプリケーション ページでアプリケーション ID を特定します。Click Azure Active Directory, click App Registrations, choose the application and locate the Application ID on the application page.
response_typeresponse_type 必須required OpenID Connect サインインでは、 id_token を指定する必要があります。Must include id_token for OpenID Connect sign-in. codetoken などの他の response_types が含まれていてもかまいません。It may also include other response_types, such as code or token.
scopescope 推奨recommended OpenID Connect の仕様では、スコープとして openid を指定する必要があります。このスコープは、承認 UI で "サインイン" アクセス許可に変換されます。The OpenID Connect specification requires the scope openid, which translates to the "Sign you in" permission in the consent UI. これとその他の OIDC スコープは v1.0 エンドポイントでは無視されますが、標準に準拠したクライアントにとっては依然としてベスト プラクティスです。This and other OIDC scopes are ignored on the v1.0 endpoint, but is still a best practice for standards-compliant clients.
noncenonce 必須required アプリによって生成された、要求に含まれる値。この値が、最終的な id_token に要求として含まれます。A value included in the request, generated by the app, that is included in the resulting id_token as a claim. アプリでこの値を確認することにより、トークン再生攻撃を緩和することができます。The app can then verify this value to mitigate token replay attacks. 通常、この値はランダム化された一意の文字列または GUID になっており、要求の送信元を特定する際に使用できます。The value is typically a randomized, unique string or GUID that can be used to identify the origin of the request.
redirect_uriredirect_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. ない場合は、ユーザー エージェントが、アプリ用に登録されたリダイレクト URI のいずれかにランダムに送り返されます。If missing, the user agent will be sent back to one of the redirect URIs registered for the app, at random. 最大長は 255 バイトです。The maximum length is 255 bytes
response_moderesponse_mode 省略可能optional 結果として得られた authorization_code をアプリに返す際に使用するメソッドを指定します。Specifies the method that should be used to send the resulting authorization_code back to your app. サポートされる値は、form_post (HTTP フォーム ポスト の場合) および fragment (URL フラグメント の場合) です。Supported values are form_post for HTTP form post and fragment for URL fragment. Web アプリケーションでは、トークンをアプリケーションに最も安全に転送できるように、response_mode=form_post を使用することをお勧めします。For web applications, we recommend using response_mode=form_post to ensure the most secure transfer of tokens to your application. id_token を含むすべてのフローの既定値は fragment です。The default for any flow including an id_token is fragment.
statestate 推奨recommended 要求に含まれ、トークンの応答として返される値。A value included in the request that is 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.
promptprompt 省略可能optional ユーザーとの必要な対話の種類を指定します。Indicates the type of user interaction that is required. 現時点で有効な値は 'login'、'none'、'consent' だけです。Currently, the only valid values are 'login', 'none', and 'consent'. prompt=login は、その要求でユーザーに資格情報の入力を強制させ、シングル サインオンを無効にします。prompt=login forces the user to enter their credentials on that request, negating single-sign on. prompt=none は反対に、ユーザーに対して対話形式のプロンプトを表示しません。prompt=none is the opposite - it ensures that the user is not presented with any interactive prompt whatsoever. シングル サインオンによって自動的に要求を完了できない場合、エンドポイントはエラーを返します。If the request cannot be completed silently via single-sign on, the endpoint returns an error. prompt=consent では、ユーザーがサインインした後で OAuth 同意ダイアログが表示され、アプリへのアクセス許可の付与をユーザーに求めます。prompt=consent triggers the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.
login_hintlogin_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 use this parameter during reauthentication, having already extracted the username from a previous sign-in using the preferred_username claim.

この時点で、ユーザーに資格情報の入力と認証が求められます。At this point, the user is asked to enter their credentials and complete the authentication.

応答のサンプルSample response

ユーザーが認証された後でサインイン要求内に指定された redirect_uri に送信される応答の例は、次のようになります。A sample response, sent to the redirect_uri specified in the sign-in request after the user has authenticated, could look like this:

POST / HTTP/1.1
Host: localhost:12345
Content-Type: application/x-www-form-urlencoded

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&state=12345
パラメーターParameter 説明Description
id_tokenid_token アプリが要求した id_tokenThe id_token that the app requested. この id_token を使用してユーザーの身元を確認し、そのユーザーとのセッションを開始することができます。You can use the id_token to verify the user's identity and begin a session with the user.
statestate 要求に含まれ、トークンの応答としても返される値。A value included in the request that is also returned in the token response. クロスサイト リクエスト フォージェリ攻撃を防ぐために通常、ランダムに生成された一意の値が使用されます。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.

エラー応答Error response

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

POST / HTTP/1.1
Host: localhost:12345
Content-Type: application/x-www-form-urlencoded

error=access_denied&error_description=the+user+canceled+the+authentication
パラメーターParameter 説明Description
errorerror 発生したエラーの種類を分類したりエラーに対処したりする際に使用するエラー コード文字列。An error code string that can be used to classify types of errors that occur, and can be used to react to errors.
error_descriptionerror_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_requestinvalid_request 必要なパラメーターが不足しているなどのプロトコル エラーです。Protocol error, such as a missing required parameter. 要求を修正し再送信します。Fix and resubmit the request. これは、開発エラーであり、通常は初期テスト中に発生します。This is a development error, and is typically caught during initial testing.
unauthorized_clientunauthorized_client クライアント アプリケーションは、認証コードの要求を許可されていません。The client application is not permitted to request an authorization code. これは通常、クライアント アプリケーションが Azure AD に登録されていない、またはユーザーの Azure AD テナントに追加されていないときに発生します。This usually occurs when the client application is not registered in Azure AD or is not 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_deniedaccess_denied リソースの所有者が同意を拒否しました。Resource owner denied consent クライアント アプリケーションは、ユーザーが同意しないと続行できないことを、ユーザーに通知できます。The client application can notify the user that it cannot proceed unless the user consents.
unsupported_response_typeunsupported_response_type 承認サーバーは要求に含まれる応答の種類をサポートしていません。The authorization server does not support the response type in the request. 要求を修正し再送信します。Fix and resubmit the request. これは、開発エラーであり、通常は初期テスト中に発生します。This is a development error, and is typically caught during initial testing.
server_errorserver_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 due to a temporary error.
temporarily_unavailabletemporarily_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 due to a temporary condition.
invalid_resourceinvalid_resource 対象のリソースは、存在しない、Azure AD が見つけられない、または正しく構成されていないために無効です。The target resource is invalid because it does not exist, Azure AD cannot find it, or it is 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.

id_token を検証するValidate the id_token

単に id_token を受け取るだけでは、ユーザーを認証するには不十分です。id_token の署名を検証し、要求をアプリの要件に従って確認する必要があります。Just receiving an id_token is not sufficient to authenticate the user; you must validate the signature and verify the claims in the id_token per your app's requirements. Azure AD エンドポイントは、JSON Web トークン (JWT) と公開キー暗号を使用してトークンに署名し、それらが有効であることを確認します。The Azure AD endpoint uses JSON Web Tokens (JWTs) and public key cryptography to sign tokens and verify that they are valid.

クライアント コードで id_token を検証することもできますが、id_token をバックエンド サーバーに送信して検証を実行するのが一般的な方法です。You can choose to validate the id_token in client code, but a common practice is to send the id_token to a backend server and perform the validation there.

シナリオに応じてその他の要求も検証することができます。You may also wish to validate additional claims depending on your scenario. 以下に一般的な検証の例をいくつか挙げます。Some common validations include:

  • ユーザー/組織がアプリにサインアップ済みであることを確認する。Ensuring the user/organization has signed up for the app.
  • wids または roles 要求を使用して、適切な承認/特権がユーザーにあることを確認する。Ensuring the user has proper authorization/privileges using the wids or roles claims.
  • 多要素認証など特定の強度の認証が行われたことを確認する。Ensuring a certain strength of authentication has occurred, such as multi-factor authentication.

id_token を検証したら、ユーザーとのセッションを開始し、id_token の要求を使用してそのユーザーに関する情報をアプリで取得することができます。Once you have validated the id_token, you can begin a session with the user and use the claims in the id_token to obtain information about the user in your app. この情報は、表示、記録、パーソナル化などに利用することができます。id_tokens と要求の詳細については、AAD id_tokens に関するページを参照してください。This information can be used for display, records, personalization, etc. For more information about id_tokens and claims, read AAD id_tokens.

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

ユーザーをアプリからサインアウトさせるとき、アプリの Cookie を消去する、あるいはユーザーとのセッションを終了するだけでは十分ではありません。When you wish to sign the user out of the app, it is not sufficient to clear your app's cookies or otherwise end the session with the user. サインアウトするには、ユーザーを end_session_endpoint にリダイレクトする必要もあります。そうしないと、ユーザーが資格情報を再入力しなくてもアプリで再認証できます。Azure AD エンドポイントのシングル サインオン セッションが有効であるためです。You must also redirect the user to the end_session_endpoint for sign-out. If you fail to do so, the user will be able to reauthenticate to your app without entering their credentials again, because they will have a valid single sign-on session with the Azure AD endpoint.

OpenID Connect メタデータ ドキュメントの一覧にある end_session_endpoint にはユーザーを簡単にリダイレクトできます。You can simply redirect the user to the end_session_endpoint listed in the OpenID Connect metadata document:

GET https://login.microsoftonline.com/common/oauth2/logout?
post_logout_redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F

パラメーターParameter 説明Description
post_logout_redirect_uripost_logout_redirect_uri 推奨recommended サインアウトの正常終了後にユーザーをリダイレクトする URL。この URL は、アプリ登録ポータルのアプリケーションに対する登録済みリダイレクト URI のいずれかと一致させる必要があります。The URL that the user should be redirected to after successful sign out. This URL must match one of the redirect URIs registered for your application in the app registration portal. post_logout_redirect_uri が含まれていない場合、ユーザーに汎用メッセージが表示されます。If post_logout_redirect_uri is not included, the user is shown a generic message.

シングル サインアウトSingle sign-out

ユーザーが end_session_endpoint にリダイレクトされると、Azure AD は、ユーザーのセッションをブラウザーからクリアします。When you redirect the user to the end_session_endpoint, Azure AD clears the user's session from the browser. ただし、ユーザーは認証に Azure AD を使用する他のアプリケーションにサインインしたままになることがあります。However, the user may still be signed in to other applications that use Azure AD for authentication. ユーザーがアプリケーションから同時にサインアウトできるように、Azure AD は、ユーザーが現在サインインしているすべてのアプリケーションの登録済み LogoutUrl に HTTP GET 要求を送信します。To enable those applications to sign the user out simultaneously, Azure AD sends an HTTP GET request to the registered LogoutUrl of all the applications that the user is currently signed in to. アプリケーションは、ユーザーを識別するすべてのセッションを消去し、200 応答を返すことで、この要求に応答する必要があります。Applications must respond to this request by clearing any session that identifies the user and returning a 200 response. アプリケーションでシングル サインアウトをサポートする場合は、アプリケーションのコードで LogoutUrl などを実装する必要があります。If you wish to support single sign out in your application, you must implement such a LogoutUrl in your application's code. LogoutUrl は Azure Portal から設定できます。You can set the LogoutUrl from the Azure portal:

  1. Azure Portal に移動します。Navigate to the Azure portal.
  2. ページの右上隅のアカウントをクリックして、Active Directory を選択します。Choose your Active Directory by clicking on your account in the top right corner of the page.
  3. 左側のナビゲーション パネルで [Azure Active Directory][アプリの登録] の順に選択し、アプリケーションを選択します。From the left hand navigation panel, choose Azure Active Directory, then choose App registrations and select your application.
  4. [設定][プロパティ] の順にクリックして、 [ログアウト URL] テキスト ボックスを探します。Click on Settings, then Properties and find the Logout URL text box.

トークンの取得Token Acquisition

多くの Web アプリは、ユーザーをサインインさせるだけでなく、OAuth を使用してそのユーザーの代わりに Web サービスにアクセスする必要もあります。Many web apps need to not only sign the user in, but also access a web service on behalf of that user using OAuth. このシナリオでは、OpenID Connect を使ってユーザー認証を行うと同時に、OAuth 承認コード フローを使って、access_tokens を取得するための authorization_code を取得します。This scenario combines OpenID Connect for user authentication while simultaneously acquiring an authorization_code that can be used to get access_tokens using the OAuth Authorization Code Flow.

アクセス トークンの取得Get Access Tokens

アクセス トークンを取得するには、前に示したサインイン要求を変更する必要があります。To acquire access tokens, you need to modify the sign-in request from above:

// Line breaks for legibility only

GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e        // Your registered Application ID
&response_type=id_token+code
&redirect_uri=http%3A%2F%2Flocalhost%3a12345          // Your registered Redirect Uri, url encoded
&response_mode=form_post                              // `form_post' or 'fragment'
&scope=openid
&resource=https%3A%2F%2Fservice.contoso.com%2F        // The identifier of the protected resource (web API) that your application needs access to
&state=12345                                          // Any value, provided by your app
&nonce=678910                                         // Any value, provided by your app

アクセス許可スコープを要求に組み込み、response_type=code+id_token を使うことによって、authorize エンドポイントはユーザーが scope クエリ パラメーターで示されているアクセス許可に同意したことを確認し、アクセス トークンと引き換えに承認コードをアプリに返します。By including permission scopes in the request and using response_type=code+id_token, the authorize endpoint ensures that the user has consented to the permissions indicated in the scope query parameter, and return your app an authorization code to exchange for an access token.

成功応答Successful response

response_mode=form_post を使用して redirect_uri に送信された成功応答は、次のようになります。A successful response, sent to the redirect_uri using response_mode=form_post, looks like:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...&state=12345
パラメーターParameter 説明Description
id_tokenid_token アプリが要求した id_tokenThe id_token that the app requested. この id_token を使用してユーザーの身元を確認し、そのユーザーとのセッションを開始することができます。You can use the id_token to verify the user's identity and begin a session with the user.
codecode アプリが要求した 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, and typically expire after about 10 minutes.
statestate 要求に 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:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

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

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

承認の codeid_token を取得した後は、ユーザーの代理でユーザーのサインインを実行し、アクセス トークンを取得することができます。Once you've gotten an authorization code and an id_token, you can sign the user in and get access tokens on their behalf. ユーザーをサインインさせるには、前に説明したように id_token を厳密に検証する必要があります。To sign the user in, you must validate the id_token exactly as described above. アクセス トークンを取得するには、OAuth コード フローのドキュメントの「承認コードを使用してアクセス トークンを要求する」セクションで説明されているステップに従ってください。To get access tokens, you can follow the steps described in the "Use the authorization code to request an access token" section of our OAuth code flow documentation.

次の手順Next steps