Azure Active Directory B2C での OpenID Connect による Web サインイン

OpenID Connect は、ユーザーを Web アプリケーションに安全にサインインさせるために使用できる、OAuth 2.0 に基づいて構築された認証プロトコルです。 Azure Active Directory B2C (Azure AD B2C) で導入された OpenID Connect を利用することで、Web アプリケーションのサインアップ、サインイン、その他の ID 管理を Microsoft Entra ID に外注できます。 このガイドでは、これを言語に依存しない方法で実行する方法について説明します。 オープンソース ライブラリを利用しないで、HTTP メッセージを送受信する方法について説明します。

OpenID Connect は、OAuth 2.0 の "認可" プロトコルを "認証" プロトコルとして使用できるように拡張したものです。 この認証プロトコルでは、シングル サインオンを実行できます。 ここでは、クライアントがユーザーの ID を検証したり、ユーザーに関する基本的なプロファイル情報を取得したりできるようにする "ID トークン" の概念が導入されています。

OpenID Connect により、アプリケーションがアクセス トークンを安全に取得することも可能になります。 アクセス トークンを使用すると、承認サーバーによってセキュリティ保護されたリソースにアクセスできます。 サーバーでホストされ、ブラウザーでアクセスされる Web アプリケーションを構築する場合は、OpenID Connect をお勧めします。 トークンの詳細については、「Overview of tokens in Azure Active Directory B2C (Azure Active Directory B2C でのトークンの概要)」を参照してください。

Azure AD B2C は、単純な認証と権限付与以上のことができるように標準の OpenID Connect プロトコルを拡張したものです。 これによって導入されるユーザー フロー パラメーターにより、OpenID Connect を使用してサインアップ、サインイン、プロファイル管理などのユーザー エクスペリエンスをアプリに追加できるようになります。

認証要求を送信する

ご利用の Web アプリケーションでユーザーを認証し、ユーザー フローを実行する必要があるときは、ユーザーを /authorize エンドポイントにリダイレクトさせることができます。 ユーザーはユーザー フローに応じてアクションを実行します。

この要求では、クライアントによって、ユーザーから取得する必要があるアクセス許可が scope パラメーターで示され、実行するユーザー フローが指定されます。 要求がどのように動作するかを理解するには、要求をブラウザーに貼り付けて実行してください。 置換前のコード:

• {tenant} を自分のテナントに置き換えます。
• 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 を、テナントに登録済みのアプリケーションのアプリ ID に置き換えます。
• {application-id-uri}/{scope-name} を、テナントに登録済みのアプリケーションのアプリケーション ID URI とスコープに置き換えます。
• {policy} を、テナント内のポリシー名に置き換えます (例: b2c_1_sign_in)。

GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

この時点で、ユーザーはワークフローを完了するよう求められます。 ユーザー名とパスワードを入力したり、ソーシャル ID でサインインしたり、ディレクトリにサインアップしたりすることが必要な場合があります。 ユーザー フローの定義方法によっては、これ以外にもいくつかの手順が必要になる場合があります。

ユーザーがユーザー フローを完了すると、response_mode パラメーターで指定された方法を使用して、redirect_uri パラメーターで示された場所にあるアプリケーションに応答が返されます。 ユーザー フローには関係なく、応答は前の各ケースにおいて同じです。

response_mode=fragment を使用した場合の正常な応答は次のようになります。

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response

アプリケーションでエラーを適切に処理できるように、redirect_uri パラメーターにはエラー応答も送信されます。

GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response

ID トークンの検証

ユーザーを認証するには、ID トークンを受信するだけでは不十分です。 ID トークンの署名を検証し、アプリケーションの要件ごとにトークン内の要求を確認します。 Azure AD B2C は、JSON Web トークン (JWT) と公開キー暗号を使用してトークンに署名し、それらが有効であることを証明します。

Azure AD B2C には、OpenID Connect メタデータ エンドポイントがあって、アプリケーションは、このエンドポイントを使用することで、Azure AD B2C に関する情報を実行時に取得することができます。 この情報には、エンドポイント、トークンの内容、トークンの署名キーが含まれます。 B2C テナントにはユーザー フローごとに JSON メタデータ ドキュメントがあります。 たとえば、fabrikamb2c.onmicrosoft.com 内の b2c_1_sign_in ユーザー フローのメタデータ ドキュメントは次の場所にあります。

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration

この構成ドキュメントのプロパティの 1 つに jwks_uri があります。同じユーザー フローに対するこの値は次のようになります。

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys

どのユーザー フローが ID トークンの署名に使用されたかは、2 つの方法で判断できます。 1 つ目として、ID トークンの acr 要求にユーザー フロー名が含まれています。ユーザー フローを表す要求に関する説明をご覧ください。 もう 1 つの選択肢では、要求を発行するときに state パラメーターの値に含まれているユーザー フローをエンコードして、それをデコードして使用されたユーザー フローを判断します。 どちらの方法も有効です。

OpenID Connect メタデータ エンドポイントからメタデータ ドキュメントを取得したら、RSA 256 公開キーを利用し、ID トークンの署名を検証できます。 このエンドポイントには、それぞれが kid 要求によって識別されるキーが複数存在すると表示される場合があります。 また、ID トークンのヘッダーには、これらのキーのうちのどれが ID トークンの署名に使用されたかを示す kid 要求も含まれています。

Azure AD B2C からのトークンを確認するには、指数 (e) と剰余 (n) を使用して公開キーを生成する必要があります。 そのためには、任意のプログラミング言語で公開キーを生成する方法を学習する必要があります。 RSA プロトコルを使用した公開キーの生成に関する公式ドキュメントについては、https://tools.ietf.org/html/rfc3447#section-3.1 を参照してください。

ID トークンの署名を検証した後、確認する必要のあるさまざまな要求が存在します。 次に例を示します。

• トークン再生攻撃を防止するために、nonce 要求を検証します。 その値が、サインイン要求で指定した値と一致していることが必要です。
• ID トークンが自分のアプリケーションのために発行されたことを確認するために、aud 要求を検証します。 その値がアプリケーションのアプリケーション ID と一致している必要があります。
• ID トークンの有効期限が切れていないことを確認するために、iat 要求と exp 要求を検証します。

また、実行する必要のあるその他の検証もいつくか存在します。 検証の詳細については、OpenID Connect コアの仕様に関するページを参照してください。シナリオに応じてその他の要求も検証することができます。 以下に一般的な検証の例をいくつか挙げます。

• ユーザー/組織がアプリにサインアップ済みであることを確認する。
• 適切な認可/権限がユーザーにあることを確認する。
• Microsoft Entra 多要素認証など特定の強度の認証が行われたことを確認する。

ID トークンが検証された後、ユーザーとのセッションを開始できます。 ID トークン内の要求を使用して、アプリケーションでユーザーに関する情報を取得できます。 この情報の使用には、表示、記録、および承認が含まれます。

トークンを取得する

Web アプリケーションがユーザー フローの実行にのみ必要な場合は、次のいくつかのセクションを省略できます。 これらのセクションは、Azure AD B2C 自体によって保護されている Web API に対して認証された呼び出しを行う必要がある Web アプリケーションにのみ適用されます。

トークン用に (response_type=code+id_token を使用して) 取得した承認コードは、POST 要求を /token エンドポイントに送信することによって目的のリソースに利用できます。 Azure AD B2C では、対応するスコープを要求の中で指定することによって、いつものように他の API のアクセス トークンを要求できます。

アプリ独自のバックエンド Web API のアクセス トークンを要求することもできます。 この場合、要求されたスコープとしてアプリのクライアント ID を使用します。その結果、そのクライアント ID を "対象ユーザー" として持つアクセス トークンが生成されます。

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

grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

正常なトークン応答は次のようになります。

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

エラー応答は次のようになります。

{
    "error": "invalid_grant",
    "error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}

トークンを使用する

アクセス トークンを正常に取得できたら、そのトークンを Authorization ヘッダー内に含めることによって、それをバックエンド Web API への要求で使用できます。

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

トークンを更新する

アクセス トークンと ID トークンの有効期限は非常に短いです。 有効期限が切れた後に、リソースに引き続きアクセスできるようにするには、トークンを更新する必要があります。 アクセス トークンを更新すると、Azure AD B2C から新しいトークンが返されます。 更新されたアクセス トークンは、nbf (期間の開始時刻)、iat (発行時刻)、および exp (有効期限) の要求値が更新されます。 他のすべての要求値は、前のアクセス トークンの値と似ています。

トークンを更新するには、もう一度 POST 要求を /token エンドポイントに送信します。 今回は、code パラメーターの代わりに refresh_token パラメーターを指定します。

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

grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

正常なトークン応答は次のようになります。

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}

エラー応答は次のようになります。

{
    "error": "invalid_grant",
    "error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}

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

ユーザーをアプリケーションからサインアウトさせるときは、アプリケーションの Cookie を消去する、あるいはユーザーとのセッションを終了するだけでは十分ではありません。 サインアウトさせるには、ユーザーを Azure AD B2C にリダイレクトします。そうしない場合、ユーザーは資格情報を再入力しなくてもアプリケーションに対して再認証できることがあります。 詳しくは、Azure AD B2C のセッションの動作に関する記事を参照してください。

ユーザーをサインアウトするには、前述した OpenID Connect メタデータ ドキュメントに示されている end_session_endpoint にユーザーをリダイレクトします。

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F

サインアウト要求が発生すると、Azure AD B2C は Azure AD B2C Cookie ベースのセッションを無効にし、フェデレーション ID プロバイダーからのサインアウトを試行します。 詳細については、「シングル サインアウト」をご覧ください。

ログアウトのリダイレクトをセキュリティで保護する

ログアウト後、ユーザーは、アプリケーションに対して指定されている応答 URL に関係なく、post_logout_redirect_uri パラメーターに指定された URI にリダイレクトされます。 ただし、有効な id_token_hint が渡され、 [ログアウト要求に ID トークンが必要] が有効になっている場合、Azure AD B2C では、リダイレクトの実行前に、post_logout_redirect_uri の値がいずれかのアプリケーションの構成済みのリダイレクト URL と一致するかどうかが検証されます。 一致する応答 URL がアプリケーションで構成されていない場合は、エラー メッセージが表示され、ユーザーはリダイレクトされません。

ログアウト要求に必要な ID トークンを設定するには、「Azure Active Directory B2C でセッションの動作を構成する」を参照してください。

次のステップ

• Azure AD B2C セッションの詳細について学習します。