マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

Nativeアプリ(スマホ)からのOAuth 2.0 は、

  • 認可リクエストを、外部Webブラウザを経由してのみ行う。
  • 外部Webブラウザとの連携には基本的に
    Private-Use URI Scheme Redirection」を使用する。
    (その他、プラットフォーム毎に利用可能な連携方法がある)
  • 外部Webブラウザ以外は、諸事情により使用しない。
  • 外部Webブラウザ以外には、以下のようなモノが存在しうる。
    • 埋め込まれたUserAgent?
      • WebView?
      • InAppBrowser?
  • ブラウザ以外の外部UserAgent?

※ なお、Hybridアプリは、この仕様の目的ではNativeアプリ(スマホ)と同等に扱う。
※ また、このページでは、OAuth 2.0 の一般的な考慮事項と重複する部分は割愛する。

詳細

外部Webブラウザを使用した方が良い理由

外部Webブラウザを使用すると、

  • ブラウザに備わっている通常のアドレスバーや証明書の検証機能を利用できる。
  • 他のアプリケーションやブラウザと認証状態を共有するため優れたUXを提供できる。
  • パスワード・マネージャーの機能を使用できるため、UXが向上する。

外部Webブラウザ以外を使用してはいけない理由

偽造Clientの可能性があり、偽造Clientによって、

IdPのアカウントを盗むことができる。

IdPのアカウントをClientが盗む事ができる。

IdPのSessionを盗むことができる。

IdPのSession cookieをClientが盗む事ができ、
Sessionが有効な間、SSO可能な状態が持続する。

偽造Clientは拒否されることがある。

Googleなどが提供するOAuth2 / OIDCのAuthorization Server(IdP & STS)
には、コレらの偽造Clientからの認可リクエストを拒否する実装が加えられている。

Nativeアプリ(スマホ)と外部Webブラウザの連携方法

Private-Use URI Scheme Redirection

  • アプリケーションが受け取る独自のURL Schemeを事前にシステムに登録する方式。
  • 複数のアプリが通常同じURL Schemeを登録できるため、
    Private-Use URI Scheme上書き攻撃が可能。

Claimed Https Scheme URI Redirection

  • Private-Use URI Scheme Redirectionを改良した方式。
    • ドメイン名などから、アプリを特定可能
    • 事前登録されていない場合は、自サイトにHTTPSで飛ぶタメ安全。
  • URI権限の存在によりURI傍受の影響を受けにくいが、
    • アプリはまだPublicクライアントであり、
    • 仕様が不明瞭なOSのURIディスパッチハンドラを使用しURIが送信される可能性がある。

Loopback Interface Redirection

  • "http://localhost:{port}/{path}"などと、
    ローカル・ループバックでHTTPリクエスを受け取る方式。
  • デスクトップOSなどでの利用を想定している。
  • 一部のOSで同じローカル・ループバックにアクセスする、
    他のアプリの傍受の影響を受ける可能性がある。
  • 例えばWindowsではhostsファイルを編集される可能性があるので、
    localhostより、127.0.0.1を使用することが推奨される。

結論

使用するフロー

Implicitは使用できない。

Private-Use URI Scheme上書き攻撃などの傍受攻撃からtokenを保護できないためNG。

Authorization Codeは、より実用的。

Nativeにtokenを渡せないが、Implicitより実用的なオプション。

サポートがあれば、OAuth PKCEを使う。

  • Private-Use URI Scheme上書き攻撃からの保護が可能。
  • スマホで認証・認可をする場合は、OAuth PKCEを使う。

Client認証について。

Client認証できない。

client_id、client_secretを持たないため。

自動再認証は抑止する。

Client認証できないので、自動再認証は抑止する。

偽造Clientの可能性を考慮する。

  • Client認証できないので、偽造Clientの可能性を考慮する必要がある。
  • ここでの、偽造Clientとは、外部Webブラウザ以外を指す。
  • 従って、偽造Clientではない、外部Webブラウザを使用する。

動的RP登録(RFC 7591)について。

Nativeアプリ(スマホ)は、Publicクライアントであるため、
Dynamic Client Registrationを行う場合は、

  • Client Typeを登録させ、
  • 合わせて、URIをチェックする
    • OAuth 2.0で推奨されるURIの完全一致
    • 連携方式に合わせた+αのチェックを行う)。

プラットフォーム独自の有用な機能

iOS

認可リクエスト送信

  • Safari
    アプリ内ブラウザのタブ機能なしで、
    古いバージョンのiOSで許可リクエストを開始できる。
  • SFAuthenticationSession?(iOS 11 以降)
    ユーザがアプリを離れることなくブラウザで許可リクエストを開始できる。

認可レスポンス受信

Android

認可リクエスト送信

  • Android Custom Tab
    • CustomTabsService?を使用して各ブラウザで実装する。
    • Android Custom Tab の Chrome 実装が Chrome Custom Tabs になる。

認可レスポンス受信

Windows(UWP)

認可リクエスト送信

認可レスポンス受信

  • Loopback Interface Redirection
    • デフォルトのファイアウォールルールによって許可
    • "SO_EXCLUSIVEADDRUSE"ソケットオプションを設定すべき

macOS

認可リクエスト送信

  • platform API

認可レスポンス受信

Linux

認可リクエスト送信

  • xdg-openなどのコマンド

認可レスポンス受信

参考

  • 知っておきたい7つのID連携実装パターン - Yahoo! JAPAN Tech Blog
    https://techblog.yahoo.co.jp/web/auth/id_federation_impl_patterns/
    1. スタンダードなブラウザーパターン
    2. 推奨したいネイティブアプリとブラウザーパターン
    3. 画面遷移がシンプルなネイティブアプリとWebView?パターン
    4. フィッシング防止なWebView?アプリとブラウザーパターン
    5. WebView?アプリ完結パターン
    6. 実装が大変だけどより汎用的なハイブリッドアプリとブラウザーパターン
    7. 汎用的なハイブリッドアプリとWebView?パターン

WebView?代替

OAuth2/OIDCの認証にWebView?はダメっぽい。

  • 代替の提案としては、以下のモノがある。

Android向け

iOS向け

仕様

関連

OAuth PKCE


Tags: :認証基盤, :クレームベース認証, :OAuth


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-03-26 (月) 13:17:58 (141d)