ネイティブ アプリから埋め込み Web ビューへのシングル サインオンを実装する

適用対象: 次の内容が外部テナントに適用されることを示す白いチェック マーク記号が付いた緑の円。 外部テナント (詳細)

モバイル アプリにプロファイルの更新ページやリワード ダッシュボードなどの Web ベースの機能が含まれている場合、ユーザーはシームレスなシングル サインオン エクスペリエンスを期待します。 ネイティブ アプリを使用して既にサインインした後に、2 番目のログイン プロンプトが表示されないようにする必要があります。

この記事では、ネイティブ モバイル アプリケーションと、埋め込み Web ビューでホストされている Web リソース (たとえば、iOS での WKWebView や Android 上の WebView ) の間にシングル サインオン (SSO) を実装する方法について説明します。 システム ブラウザーとは異なり、埋め込み Web ビューを使用すると、送信前にネットワーク要求を操作できます。 この機能により、アプリはユーザーの認証状態を要求ヘッダーに直接挿入できます。

推奨されるフローは次のようになります。

  1. ユーザーは、ネイティブ認証 SDK またはネイティブ 認証 API を使用して、モバイル アプリのネイティブ UI を使用してサインインします。
  2. Web ビューを読み込む前に、アプリは SDK または API から有効なアクセス トークンを取得します。
  3. アプリは、 Authorization: Bearer <access_token> ヘッダーにアクセス トークンを含むカスタム要求を含む Web ビューを読み込みます。
  4. Web リソースはトークンを検証し、すぐにアクセス権を付与します。

次の図は、Web リソース、モバイル アプリ、SDK、ID サービス (ESTS) の間の相互作用を示しています。

モバイル アプリが SDK 経由でサインインし、トークンを受け取り、アクセス トークンを含む Web ビューを Authorization ヘッダーに読み込む SSO フローを示すシーケンス図。

前提条件

ネイティブ認証でサインインする

Native Auth SDK または ネイティブ認証 API を使用して、標準のサインイン フローを完了します。 SDK を使用してサインインに成功すると、アクセス トークン、ID トークン、および更新トークンが安全にキャッシュされます。 API を直接使用する場合、アプリは、受け取ったトークンを安全に格納する役割を担います。

サインインの実装手順の詳細については、次を参照してください。

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

ユーザーが Web ビューを開くアクションをトリガーしたら、Web リソースを読み込む前に、アプリに有効な期限切れのないアクセス トークンがあることを確認します。

Native Auth SDK を使用する場合は、トークンをサイレント モードで要求します。 SDK には、キャッシュから有効なトークンを取得するか、自動的に更新する getAccessToken() メソッドが用意されています。 特定のスコープでアクセス トークンを取得する方法の詳細については、次を参照してください。

ネイティブ認証 API を直接使用する場合、アプリは API の /oauth/v2.0/token エンドポイントを介してトークンを取得します。 詳細については、 ネイティブ認証 API リファレンスを参照してください。

Web リソースに必要な正確なスコープでトークンを要求します。 スコープの要件については、「 制限事項と構成要件」を参照してください。

認証を使用して Web ビューを読み込む

認証状態を Web ビューに渡すには、2 つの方法があります。 推奨される方法では、承認ヘッダーが使用されます。 従来のシナリオでは Cookie ベースのフォールバックを使用できますが、推奨されません。

Web ビューの読み込みに使用する初期 HTTP 要求の Authorization ヘッダーにアクセス トークンを直接挿入します。 これは、最も安全で堅牢な方法です。

この方法は、次の理由で推奨されます。

  • ステートレス: クライアント側の永続的な Cookie には依存しません。
  • トークンを分離します。トークンをこの特定の要求フローに厳密に制限します。
  • Web ベースの攻撃ベクトルを回避します。ブラウザーで管理されるセッションに関連する一般的なセキュリティの問題を回避します。

ヘッダーベースの認証を使用して Web ビューを読み込むには:

  1. Web リソースの URL を作成します。 HTTPS を使用していることを確認します。
  2. カスタム ネットワーク要求オブジェクトを作成します。
  3. 要求にヘッダー Authorization: Bearer <access_token> を追加します。
  4. Web ビュー コンポーネントに要求を読み込みます (たとえば、iOS の WKWebView や Android の WebView )。

オプション B: Cookie を使用する (フォールバックのみ)

ターゲット Web リソースがヘッダーベースの認証 (たとえば、特定のレガシ シングルページ アプリケーション) を処理できない場合は、トークンを Cookie として挿入できます。 一般に、この方法はセキュリティ 上のリスクがあるためお勧めしません。

Web ビューに Cookie を挿入すると、認証状態がブラウザーで管理されるメカニズムに委ねられます。 これにより、セッションが "アンビエント" (要求に自動的にアタッチされます) になり、アプリが標準の Web 攻撃クラスに公開されます。

  • XSS (クロスサイト スクリプティング): Web コンテンツが侵害された場合、セッションはハイジャックに対して脆弱です。
  • CSRF (クロスサイト リクエスト フォージェリ): 意図しない認証要求のリスクがあります。
  • セッション固定: 攻撃者がセッションの状態を制御する可能性があります。
  • コンプライアンス: このアプローチは、Web ビューの Cookie jar での機密性の高い状態の保持に関するセキュリティのベスト プラクティス (MASTG-KNOW-0018 など) と競合します。

Warning

Cookie ベースのアプローチは条件付きで承認されており、通常は推奨されません。 ターゲット Web リソースがヘッダーベースの認証をサポートできない場合にのみ使用します。

Cookie ベースのアプローチを使用する場合は、次の要件が適用されます。

  • 可能な場合は、サーバーによって発行されたセッション Cookie を使用します。
  • 生のアクセス トークンを Cookie に直接配置することは避けてください。
  • HttpOnly、Secure、および適切なSameSite属性を使用して Cookie を設定します。
  • サーバー側に厳密な CSRF 保護を適用します。

バックエンドでトークンを検証して永続化する

要求が Web リソースに到達すると、バックエンドはトークンを処理してセッションを確立します。

トークンを検証する

Web サーバーは受信要求をインターセプトし、トークンの署名と要求を検証します。 ASP.NET Core バックエンドの場合は、 Microsoft.Identity.Web (MISE) を使用して検証を自動的に処理します。

トークンの対象ユーザー (aud) 要求が Web API の識別子と一致し、発行者 (iss) 要求が予想される機関と一致していることを確認します。

セッションを保持する

Web ビューは、後続のナビゲーション イベント (ユーザーがリンクを選択した場合など) にカスタム ヘッダーを保持しません。 最初の要求後に認証された状態を維持するために、サーバーは初期ベアラー トークンの検証に成功したときに標準セッション Cookie (Set-Cookie) を発行します。

次の属性を使用してセッション Cookie を構成します。

  • HttpOnly
  • Secure
  • 適切な SameSite ポリシー

制限事項と構成要件

モバイル アプリに発行されたトークンが Web リソースによって受け入れられるようにするには、次の構成に注意してください。

  • 共有クライアント ID: モバイル アプリと Web アプリは、同じクライアント ID (アプリケーション ID) を共有する必要があります。 ID が異なる場合、バックエンドは対象ユーザーの不一致としてモバイル アプリのトークンを拒否します。
  • スコープの配置: モバイル アプリは、Web リソースに必要な正確なスコープ ( Profile.Read、 Orders.Writeなど) を使用してアクセス トークンを要求します。

Note

このソリューションは、Web ビューシナリオ専用に調整されています。 SSO 機能をシステム ブラウザーやその他の複雑なシナリオに拡張するより汎用的なソリューションは、今後のリリースで予定されています。

関連するコンテンツ

  • Last updated on