用語・概念
-
ネイティブアプリ
- ユーザーがデバイスにインストールするアプリまたはアプリケーション。
-
埋め込みブラウザ(embedded user-agent)
- ネイティブアプリの一部を形成する、または同じセキュリティドメインを共有してアプリがCookieストレージにアクセスしたり、ページコンテンツを検査または変更したりできるよう、ネイティブアプリによってホストされるユーザーエージェント。
-
外部ブラウザ(external user-agent)
- ネイティブアプリがCookieストレージにアクセスしたり、ページコンテンツを検査または変更したりできないように、リクエストを行うネイティブアプリとは別のエンティティまたはセキュリティドメインである承認リクエストを処理可能なユーザーエージェント。
-
in-app browser tab
- ブラウザのタブをアプリから使う機能。
- ホストアプリ内に表示されるが、ブラウザーの完全なセキュリティプロパティと認証状態を保持する、ブラウザーインスタンス。
-
private-use URI scheme
- アプリによって定義され、オペレーティングシステムに登録されたURIスキーム。
- スキームへのURIリクエストにより、リクエストを処理するためにそれを登録したアプリを起動する。
-
claimed "https" scheme URI
- アプリがドメイン名の所有権を証明した後に「https」スキームURIを要求することで、アプリを起動する。
-
ループバックアドレス
- そのIPアドレスを指定することで自分の使用しているコンピュータのIPアドレスを指定した場合と同じ意味になるIPアドレス。
連携観点
認可リクエストの開始
外部ブラウザの利用
外部ブラウザの利用を推奨する。
推奨理由
- ブラウザに備わっている通常のアドレスバーや証明書の検証機能を利用可能。
- 他のアプリやブラウザと認証状態を共有するためUXが低下しない。
- パスワード・マネージャーの機能を使用できるため、UXが向上する。
外部ブラウザ以外(埋め込みブラウザ)を推奨しない理由
- 偽造Clientの可能性があり、偽造Clientによって以下の問題が発生する。
- IdPのアカウントをClientが盗む事ができる。
- IdPのSession cookieをClientが盗む事ができ、Sessionが有効な間、SSO可能な状態が持続する。
PKCEの実装
- 認可リクエスト毎に Code Verifier と呼ばれる値を生成し、そのハッシュ値を付与する。
- IdP からのレスポンスから、認可コード を受け取り、それを利用してアクセストークン の発行を行う。
- アクセストークン発行時に元の Code Verifier を 認可コード と同時に送らせることで、最初に Authorization Request をスタートしたアプリ (その時点まで Code Verifier を知っている唯一のアプリ) だけがアクセストークン の発行を行えることを保証する。
認可レスポンスの受信
- 認可サーバーは以下の3つのリダイレクトオプションをサポートする必要がある。
Private-Use URI Scheme Redirection
- アプリケーションが受け取る独自のURL スキームを事前にシステムに登録する方式。
- 複数のアプリが通常同じURL Schemeを登録できるため、Private-Use URI Scheme上書き攻撃が可能。
- 同じ URL スキームを複数のアプリが登録可能であることから、該当 スキーム 経由で起動されたアプリが本来期待されたアプリと異なる可能性がある。
- これを利用し、他の ネイティブアプリが利用している URLスキームを乗っ取る攻撃アプリが成立する。
- 攻撃者は、このような攻撃アプリをターゲットにインストール & ログインさせることで、IdPおよびバックエンドアプリが発行したターゲットアカウント向けのアクセストークンや、バックエンドアプリに保存されているターゲットのデータへのアクセス権を得ることができる。
Claimed Https Scheme URI Redirection
- Private-Use URI Scheme Redirectionを改良した方式。
- httpsスキームのURIをアプリで受信し、起動する方法。
Loopback Interface Redirection
- ループバックアドレスでHTTPリクエスを受け取る方式。
- デスクトップOSなどでの利用を想定している。
- 一部のOSで同じループバックアドレスにアクセスすると、他のアプリの傍受の影響を受ける可能性がある。