OpenID Connect と Azure Active Directory を使用して Web アプリケーションへのアクセスを承認する

OpenID Connect は、OAuth 2.0 プロトコルの上に構築されたシンプルな ID レイヤーです。 OAuth 2.0 では、 アクセス トークン を取得して使用して保護されたリソースにアクセスするメカニズムが定義されていますが、ID 情報を提供する標準的な方法は定義されていません。 OpenID Connect は、OAuth 2.0 承認プロセスの拡張機能として認証を実装します。 エンド ユーザーに関する情報を、ユーザーの ID を検証し、ユーザーに関する基本的なプロファイル情報を提供する id_token の形式で提供します。

OpenID Connect は、サーバーでホストされ、ブラウザー経由でアクセスされる Web アプリケーションを構築する場合に推奨されます。

アプリケーションを AD テナントに登録する

まず、アプリケーションを Azure Active Directory (Azure AD) テナントに登録します。 これにより、アプリケーションのアプリケーション ID が提供され、トークンを受信できるようになります。

1. Azure portal にサインインします。

2. ページの右上隅にあるアカウントを選択し、[ ディレクトリの切り替え ] ナビゲーションを選択し、適切なテナントを選択して、Azure AD テナントを選択します。

   • アカウントに Azure AD テナントが 1 つだけある場合、または適切な Azure AD テナントを既に選択している場合は、この手順をスキップします。

3. Azure portal で、 Azure Active Directory を検索して選択します。

4. Azure Active Directory の左側のメニューで、[アプリの登録] を選択し、[新しい登録] を選択します。

5. プロンプトに従って、新しいアプリケーションを作成します。 このチュートリアルの Web アプリケーションまたはパブリック クライアント (モバイルおよびデスクトップ) アプリケーションのどちらであるかは関係ありませんが、Web アプリケーションやパブリック クライアント アプリケーションの具体的な例が必要な場合は、 クイック スタートを確認してください。

   • 名前 はアプリケーション名であり、エンド ユーザーにアプリケーションを記述します。
   • [サポートされているアカウントの種類] で、 [Accounts in any organizational directory and personal Microsoft accounts](任意の組織のディレクトリ内のアカウントと個人用の Microsoft アカウント) を選択します。
   • リダイレクト URI を指定します。 Web アプリケーションの場合、これはユーザーがサインインできるアプリのベース URL です。 たとえば、http://localhost:12345 のようにします。 パブリック クライアント (モバイルおよびデスクトップ) の場合、Azure AD はそれを使用してトークン応答を返します。 アプリケーションに固有の値を入力します。 たとえば、http://MyFirstAADApp のようにします。

6. 登録が完了すると、Azure AD によってアプリケーションに一意のクライアント識別子 ( アプリケーション ID) が割り当てられます。 この値は次のセクションで必要になるため、アプリケーション ページからコピーします。

7. Azure portal でアプリケーションを検索するには、[アプリの 登録] を選択し、[ すべてのアプリケーションの表示] を選択します。

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

最も基本的なサインイン フローには、次の手順が含まれています。それぞれの手順について、以下で詳しく説明します。

OpenID Connect メタデータ ドキュメント

OpenID Connect は、アプリがサインインを実行するために必要なほとんどの情報を含むメタデータ ドキュメントを記述します。 これには、使用する URL やサービスの公開署名キーの場所などの情報が含まれます。 OpenID Connect メタデータ ドキュメントは、次の場所にあります。

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

メタデータは、単純な JavaScript Object Notation (JSON) ドキュメントです。 例については、次のスニペットを参照してください。 スニペットの内容は、 OpenID Connect 仕様で完全に説明されています。 上記の {tenant} の代わりに common ではなくテナント ID を指定すると、返される JSON オブジェクト内のテナント固有の URI が生成されることに注意してください。

{
    "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",
    ...
}

要求マッピング機能を使用した結果としてアプリにカスタム署名キーがある場合は、アプリの署名キー情報を指すjwks_uriを取得するために、アプリ ID を含む appid クエリ パラメーターを追加する必要があります。 例: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e には、jwks_uri の https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e が含まれます。

サインイン要求を送信する

Web アプリケーションがユーザーを認証する必要がある場合は、ユーザーを /authorize エンドポイントに誘導する必要があります。 この要求は 、OAuth 2.0 承認コード フローの最初の区間に似ていますが、いくつかの重要な違いがあります。

• 要求には、scope パラメーターにスコープ openidを含める必要があります。
• response_type パラメーターには、id_tokenを含める必要があります。
• 要求には、 nonce パラメーターを含める必要があります。

そのため、サンプル要求は次のようになります。

// 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

この時点で、ユーザーに認証情報の入力と認証が求められます。

サンプル応答

ユーザーが認証された後にサインイン要求で指定された redirect_uri に送信される応答の例は、次のようになります。

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

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&state=12345

エラー応答

アプリ側でエラーを適切に処理できるよう、 redirect_uri にはエラー応答も送信されます。

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

error=access_denied&error_description=the+user+canceled+the+authentication

承認エンドポイント エラーのエラー コード

次の表で、エラー応答の error パラメーターで返される可能性のあるさまざまなエラー コードを説明します。

id_tokenを検証する

ユーザーを認証するには、 id_token を受け取るだけでは不十分です。署名を検証し、アプリの要件に従って id_token の要求を確認する必要があります。 Azure AD エンドポイントは、JSON Web トークン (JWT) と公開キー暗号化を使用してトークンに署名し、それらが有効であることを確認します。

クライアント コードで id_token を検証することもできますが、一般的な方法は、バックエンド サーバーに id_token を送信し、そこで検証を実行することです。

シナリオに応じて、追加の要求を検証することもできます。 以下に一般的な検証の例をいくつか挙げます。

• ユーザー/組織がアプリにサインアップ済みであることを確認する。
• widsまたはroles要求を使用して、ユーザーに適切な承認/特権があることを確認します。
• 多要素認証など、一定の強度の認証が行われたことを確認します。

id_tokenを検証したら、ユーザーとのセッションを開始し、id_tokenの要求を使用してアプリ内のユーザーに関する情報を取得できます。 この情報は、表示、レコード、パーソナル化などに使用できます。 id_tokens と要求の詳細については、 AAD id_tokensを参照してください。

サインアウト要求を送信する

ユーザーをアプリからサインアウトさせる場合は、アプリの Cookie をクリアしたり、ユーザーとのセッションを終了したりするだけでは不十分です。 サインアウトのために、ユーザーを end_session_endpoint にリダイレクトする必要もあります。これを行わない場合、ユーザーは Azure AD エンドポイントとの有効なシングル サインオン セッションを持っているため、資格情報を再入力せずにアプリに再認証できます。

OpenID Connect メタデータ ドキュメントに記載されている end_session_endpoint にユーザーをリダイレクトするだけです。

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

シングル サインアウト

ユーザーを end_session_endpointにリダイレクトすると、Azure AD はブラウザーからユーザーのセッションをクリアします。 ただし、認証に Azure AD を使用する他のアプリケーションにユーザーがサインインしている可能性があります。 これらのアプリケーションがユーザーを同時にサインアウトできるようにするために、Azure AD は、ユーザーが現在サインインしているすべてのアプリケーションの登録済み LogoutUrl に HTTP GET 要求を送信します。 アプリケーションは、ユーザーを識別するすべてのセッションを消去し、200 応答を返すことで、この要求に応答する必要があります。 アプリケーションでシングル サインアウトをサポートする場合は、アプリケーションのコードにこのような LogoutUrl を実装する必要があります。 LogoutUrlは、Azure portal から設定できます。

1. Azure portal にサインインします。
2. ページの右上隅にあるアカウントをクリックして、Active Directory を選択します。
3. 左側のナビゲーション パネルで、[ Azure Active Directory] を選択し、[ アプリの登録 ] を選択してアプリケーションを選択します。
4. [ 設定]、[ プロパティ ] の順にクリックし、[ ログアウト URL ] テキスト ボックスを見つけます。

トークンの取得

多くの Web アプリでは、ユーザーをサインインさせるだけでなく、OAuth を使用してそのユーザーに代わって Web サービスにアクセスする必要があります。 このシナリオでは、OpenID Connect を組み合わせてユーザー認証を行う一方で、OAuth 承認コード フローを使用してaccess_tokensを取得するために使用できるauthorization_codeを同時に取得します。

アクセス トークンを取得する

アクセス トークンを取得するには、上記のサインイン要求を変更する必要があります。

// 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 クエリ パラメーターに示されているアクセス許可に同意したことを確認し、アクセス トークンと交換する承認コードをアプリに返します。

成功応答

response_mode=form_postを使用してredirect_uriに送信された正常な応答は次のようになります。

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

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...&state=12345

エラー応答

アプリ側でエラーを適切に処理できるよう、 redirect_uri にはエラー応答も送信されます。

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

error=access_denied&error_description=the+user+canceled+the+authentication

考えられるエラー コードとその推奨されるクライアント アクションの説明については、 承認エンドポイント エラーのエラー コードを参照してください。

承認 code と id_tokenを取得したら、ユーザーにサインインし、ユーザーに代わって アクセス トークンを 取得できます。 ユーザーをサインインさせるには、上記のように id_token を正確に検証する必要があります。 アクセス トークンを取得するには、 OAuth コード フロー ドキュメントの「承認コードを使用してアクセス トークンを要求する」セクションで説明されている手順に従います。

次のステップ

• アクセス トークンの詳細を確認します。
• id_tokenや要求についてさらに詳しく知る