3

複数のトークン リクエストが必要な理由:

SPA の暗黙的なフローを使用して、Azure AD B2C からアクセス トークンを取得し、B2C によって保護されている API にアクセスしています。複数の API にアクセスする必要があり、それらはすべて B2C で異なるアプリケーションとして登録されているため、それぞれの対象者が異なります。それらはすべて異なる対象者であるため、B2C は複数の対象者に対する 1 つのトークン リクエストをサポートしていないため、複数のトークン リクエストを作成する必要があります。

B2C セットアップの背景

ローカル アカウント ログインと、他の Azure AD ID プロバイダーを使用するソーシャル ログインをサポートしています。また、B2C (アイデンティティ エクスペリエンス フレームワーク) のカスタム ポリシーも使用しています。

問題

この問題は、Azure AD ログインソーシャル ログインを使用しているユーザーに発生します。ユーザーは以前にログインしたことがあります。

複数のリクエストが行われると、Google Chrome で次のネットワーク トレースが確認されました。

Chrome ネットワーク トレース 上記のトレースは次を示しています。

  1. 1 行目と 2 行目は、 2 つの異なる api/scope/audience のB2C承認エンドポイントへのトークン リクエストです。
  2. 3 行目と 4 行目と 5 行目と 6 行目は、 login.windows.netとlogin.microsoftonline.comへのリダイレクトで、どちらも特定の api/scope/audience 用に 1 セットとして設定されています。
  3. 7 行目と 8 行目は両方とも、B2C への応答 (id トークン) フォームのポストです。行 7 は、フォーム ポストから不正なリクエスト応答を返します。

質問

  1. login.windows.netまたはlogin.microsoftonline.comにリダイレクトする必要があるのはなぜですか? ユーザーは以前にログインしたことがあるため、有効なセッションを持っているべきではないので、B2C は要求されたトークンを返すことができますか?
  2. B2C は、ソーシャル ログインID のために同じブラウザーからの同時トークン要求 (またはログイン) をサポートできますか? これは、B2C がソーシャル ログインに期待する認証状態が1 つだけであり、一意であることが原因であると考えられます。そのため、同時ログインによってこれが互いにオーバーライドされ、他の要求が無効になります。不正なリクエスト応答に関する詳細はまったくありません。「Bad request」テキストを含む空白のページが表示されるだけです。

-- 2019 年 3 月 5 日更新 --

B2C カスタム ポリシーを少しいじった後、次のように変更することで、一度ログインした後、リダイレクトを抑制することができました。

        <TechnicalProfile Id="SM-SocialLogin">
          <DisplayName>Session Mananagement Provider</DisplayName>
          <!--Changed to this provider instead of ExternalLoginSSOSessionProvider-->
          <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <PersistedClaims>
            <PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />
            <PersistedClaim ClaimTypeReferenceId="objectId" />
            ... removed for brevity ...
            <PersistedClaim ClaimTypeReferenceId="groups" />
          </PersistedClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
          </OutputClaims>
        </TechnicalProfile>

行われた変更は、デフォルトのセッション プロバイダーを使用することです。

外部セッション プロバイダーが再認証を抑制しないのはなぜですか? false に設定されたメタデータAlwaysFetchClaimsFromProviderは、再認証も抑制しません。

しかし、この回避策を使用すると、別の問題で別の問題が発生します。

4

0 に答える 0