Azure Active Directory B2C の OAuth 2.0 暗黙的フローを使用したシングルページ アプリケーション サインイン

多くの最新のアプリケーションには、主に JavaScript で記述されたシングルページ アプリ (SPA) フロントエンドがあります。 多くの場合、アプリは React、Angular、Vue.jsなどのフレームワークを使用して記述されます。 主にブラウザーで実行される SPA やその他の JavaScript アプリには、認証に関する追加の課題がいくつかあります。

• これらのアプリのセキュリティ特性は、従来のサーバーベースの Web アプリケーションとは異なります。

• 多くの認証サーバーと ID プロバイダーは、クロスオリジン リソース共有 (CORS) 要求をサポートしていません。

• アプリから離れるフルページブラウザリダイレクトは、ユーザーエクスペリエンスを侵害する可能性があります。

MSAL.js 1.x などの一部のフレームワークでは、暗黙的な許可フローのみがサポートされています。 このような場合、Azure Active Directory B2C (Azure AD B2C) では、OAuth 2.0 承認の暗黙的な許可フローがサポートされます。 このフローについては 、OAuth 2.0 仕様のセクション 4.2 で説明されています。 暗黙的なフローでは、アプリは Azure AD B2C 承認エンドポイントから直接トークンを受け取り、サーバー間の交換は行われません。 すべての認証ロジックとセッション処理は、ページリダイレクトまたはポップアップボックスを使用して、JavaScriptクライアントで完全に行われます。

Azure AD B2C は、標準の OAuth 2.0 の暗黙的なフローを単純な認証と承認以上のものに拡張します。 Azure AD B2C では 、ポリシー パラメーターが導入されています。 policy パラメーターを使用すると、OAuth 2.0 を使用して、サインアップ、サインイン、プロファイル管理のユーザー フローなどのポリシーをアプリに追加できます。 この記事の HTTP 要求の例では、説明のために {tenant}.onmicrosoft.com を使用しています。 {tenant} をテナントの名前に置き換えます (ある場合)。 また、 ユーザー フローを作成しておく必要があります。

次の図は、暗黙的なサインイン フローを示すために使用します。 各手順については、この記事の後半で詳しく説明します。

認証要求を送信する

Web アプリケーションでユーザーを認証し、ユーザー フローを実行する必要がある場合、ユーザーは Azure AD B2C の /authorize エンドポイントに転送されます。 ユーザーはユーザー フローに応じてアクションを実行します。

この要求では、クライアントは、 scope パラメーターと実行するためにユーザー フローでユーザーから取得する必要があるアクセス許可を示します。 リクエストがどのように機能するかを理解するには、リクエストをブラウザに貼り付けて実行してみてください。 次のように置換します。

• {tenant} を Azure AD B2C テナントの名前に置き換えます。

• 00001111-aaaa-2222-bbbb-3333cccc4444 を、テナントに登録したアプリケーションのアプリ ID に置き換えます。

• {policy} を、テナントで作成したポリシーの名前 (例: b2c_1_sign_in) に置き換えます。

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

HTTP GET リクエストのパラメータについては、次の表で説明します。

これは、フローの対話型部分です。 ユーザーは、ポリシーのワークフローを完了するように求められます。 ユーザーは、ユーザー名とパスワードの入力、ソーシャル ID でのサインイン、ローカル アカウントへのサインアップ、またはその他のいくつかの手順が必要になる場合があります。 ユーザー アクションは、ユーザー フローの定義方法によって異なります。

ユーザーがユーザー フローを完了すると、Azure AD B2C は redirect_uriを介してアプリに応答を返します。 response_mode パラメーターで指定されたメソッドを使用します。 応答は、実行されたユーザー フローとは無関係に、各ユーザー アクション シナリオでまったく同じです。

成功応答

response_mode=fragment と response_type=id_token+token を使用した正常な応答は、読みやすくするために改行して、次のようになります。

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier

エラー応答

エラー応答をリダイレクト URI に送信して、アプリが適切に処理できるようにすることもできます。

GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response

ID トークンの検証

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

JWTの検証には、使用する言語に応じて、多くのオープンソースライブラリを利用できます。 独自の検証ロジックを実装するのではなく、利用可能なオープンソースライブラリを探索することを検討してください。 この記事の情報は、これらのライブラリを適切に使用する方法を学習するのに役立ちます。

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

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 トークンの署名に使用されたユーザー フロー (およびメタデータのフェッチ元) を特定するには、次のいずれかのオプションを使用できます。

• ユーザー フロー名は、acr の id_token 要求に含まれています。 ID トークンから要求を解析する方法については、 Azure AD B2C トークン リファレンスを参照してください。

• 要求を発行するときに、 state パラメーターの値でユーザー フローをエンコードします。 次に、 state パラメーターをデコードして、使用されたユーザー フローを特定します。

OpenID Connect メタデータエンドポイントからメタデータドキュメントを取得したら、RSA-256 公開鍵 (このエンドポイントにあります) を使用して ID トークンの署名を検証できます。 このエンドポイントには、常に複数のキーがリストされ、それぞれが kidで識別される可能性があります。 id_token のヘッダーには、kid 要求も含まれています。 これは、これらのキーのどれが ID トークンの署名に使用されたかを示します。 トークンの検証の詳細など、詳細については、Azure AD B2C トークン リファレンスを参照してください。

ID トークンの署名を検証した後、いくつかの要求で検証が必要になります。 例えば次が挙げられます。

• トークン再生攻撃を防止するために、nonce 要求を検証します。 その値が、サインイン要求で指定した値と一致していることが必要です。

• aud 要求を検証して、アプリの ID トークンが発行されたことを確認します。 その値は、アプリのアプリケーション ID である必要があります。

• iat 要求と exp 要求を検証して、ID トークンの有効期限が切れていないことを確認します。

実行する必要があるその他のいくつかの検証については、 OpenID Connect Core Spec で詳しく説明しています。また、シナリオによっては、追加の要求を検証することもできます。 以下に一般的な検証の例をいくつか挙げます。

• ユーザーまたは組織がアプリにサインアップしていることを確認します。

• ユーザーが適切な許可と特権を持っていることを確認します。

• Microsoft Entra 多要素認証を使用するなどして、特定の強度の認証が行われていることを確認します。

ID トークンの要求の詳細については、 Azure AD B2C トークン リファレンスを参照してください。

ID トークンを検証したら、ユーザーとのセッションを開始できます。 アプリでは、ID トークンの要求を使用して、ユーザーに関する情報を取得します。 この情報は、照会、レコード、権限などに使用できます。

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

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

ユーザーが SPA にサインインしたので、Microsoft Entra ID によって保護されている Web API を呼び出すためのアクセス トークンを取得できます。 token 応答の種類を使用してトークンを既に受信している場合でも、この方法を使用すると、ユーザーが再度サインインするようにリダイレクトすることなく、追加のリソースのトークンを取得できます。

一般的な Web アプリ フローでは、 /token エンドポイントに要求を行います。 ただし、エンドポイントは CORS 要求をサポートしていないため、更新トークンを取得するために AJAX 呼び出しを行うことはできません。 代わりに、非表示の HTML iframe 要素で暗黙的なフローを使用して、他の Web API の新しいトークンを取得できます。 次に、読みやすくするために改行を使用した例を示します。

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none

prompt=none パラメータを設定すると、このリクエストはすぐに成功または失敗し、アプリケーションに戻ります。 成功した応答は、 response_mode パラメーターで指定された方法を使用して、リダイレクト URI を介してアプリに送信されます。

成功応答

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

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read

エラー応答

エラー応答は、アプリが適切に処理できるように、リダイレクト URI に送信することもできます。 prompt=noneの場合、予期されるエラーは次の例のようになります。

GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently

Iframe 要求でこのエラーを受信した場合、ユーザーは対話形式でもう一度サインインして新しいトークンを取得する必要があります。

更新トークン

IDトークンとアクセストークンはどちらも短期間で期限切れになります。 アプリは、これらのトークンを定期的に更新する準備ができている必要があります。 暗黙的なフローでは、セキュリティ上の理由から更新トークンを取得できません。 いずれかのタイプのトークンを更新するには、非表示の HTML iframe 要素で暗黙的なフローを使用します。 認証要求には、 prompt=none パラメーターを含めます。 新しい id_token 値を受け取るには、必ず response_type=id_token と scope=openid、および nonce パラメーターを使用してください。

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

ユーザーをアプリからサインアウトする場合は、ユーザーを Azure AD B2C のサインアウト エンドポイントにリダイレクトします。 その後、アプリでユーザーのセッションをクリアできます。 ユーザーをリダイレクトしない場合、ユーザーは Azure AD B2C との有効なシングル Sign-On セッションを持っているため、資格情報を再度入力せずにアプリに再認証できる可能性があります。

end_session_endpoint」で説明されているのと同じ OpenID Connect メタデータ ドキュメントにリストされているにユーザーをリダイレクトするだけです。 例えば次が挙げられます。

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

次のステップ

コード サンプル「 JavaScript SPA で Azure AD B2C を使用してサインインする」を参照してください。