Open ID Connect ミドルウェアを使用して Azure AD に対して認証が行われるという独自のシナリオがあります。アプリケーションが認証され、セッションが確立されたら、同じサーバー上にある WebAPI サービスに対して AJAX 呼び出しを行う必要があります。
サーバーにキャッシュされたID/アクセストークンをクライアントに戻し、セッションストレージに保存する予定です。
このアプローチにはセキュリティ上の影響はありますか? つまり、ADAL JS または ADAL を介して取得したトークンに違いはありますか?
そうすることはお勧めしません。機密クライアントによって取得されたアクセス トークンと ID トークンは、パブリック クライアントによって取得されたものとは異なります。また、Azure AD トークンでは、暗黙的なフローを介して発行されたトークンは、サイズを含むことを目的としたヒューリスティックにより、さらに違いがあります。シナリオにはよりクリーンなソリューションがあります。OpenID Connect を使用してサインインすると、ブラウザーには Azure AD とのセッション Cookie があります。ページに非表示の iframe を挿入し、その iframe を使用して JavaScript を介してトークンの暗黙的な許可要求を実行すると、JS フロントエンドに独自のトークンを取得させることができ、取得したトークンをトポロジ内の他の場所で循環させる必要がなくなります。これはまさに、ADAL がトークンを更新し、サインイン後に新しいトークンを取得するために行うことです。 残念ながら、このアプローチのサンプルはありませんが、ADAL JS を調べることができます。