メインコンテンツまでスキップ

Appendix B. Platform-Specific Implementation Details (付録B. プラットフォーム固有の実装詳細)

本文書は主に、さまざまな環境で一般的に利用可能な技術を参照しながら、一般的な方法で最良慣行を定義しています。この非規範的なセクションでは、さまざまなオペレーティングシステムに対する最良慣行の実装詳細を文書化しています。

ここでの実装詳細は公開時点で正確と見なされていますが、時間の経過とともに変更される可能性があります。このような変更が文書の残りの部分の一般的な原則を無効にすることはなく、矛盾がある場合にはそれらの原則が優先されるべきであることが期待されています。

B.1. iOS Implementation Details (iOS 実装詳細)​

アプリは、ユーザーがアプリを離れることなく、"SFSafariViewController" クラスまたはその後継である "SFAuthenticationSession" を通じて、ブラウザで認可リクエストを開始できます。これらはアプリ内ブラウザタブパターンを実装しています。アプリ内ブラウザタブ機能のない古いバージョンの iOS では、Safari を使用してリクエストを処理できます。

認可レスポンスを受信するには、プライベート使用 URI スキーム（"カスタム URL スキーム" と呼ばれる）リダイレクトと、主張された "https" スキーム URI（"Universal Links" として知られている）の両方が実行可能な選択肢です。アプリは、アプリケーションのプロパティリストファイル "Info.plist" の "CFBundleURLTypes" キーでプライベート使用 URI スキームを主張でき、"https" スキーム URI は、アプリ内のエンタイトルメントファイルとドメイン上でホストされる関連ファイルを使用して Universal Links 機能を使用して主張できます。

主張された "https" スキーム URI は、オペレーティングシステムによって提供される所有権証明のため、iOS 9 以降で推奨されるリダイレクト選択肢です。

完全なオープンソースサンプルは、AppAuth for iOS and macOS [AppAuth.iOSmacOS] ライブラリに含まれています。

B.2. Android Implementation Details (Android 実装詳細)​

アプリは、ユーザーがアプリを離れることなく、Android Custom Tab 機能を通じて、ブラウザで認可リクエストを開始できます。これはアプリ内ブラウザタブパターンを実装しています。Custom Tabs をサポートするブラウザがない場合、ユーザーのデフォルトブラウザを使用してリクエストを処理できます。

Android ブラウザベンダーは、ユーザーにアプリ内ブラウザタブのユーザーエクスペリエンス最適化を提供するために、("CustomTabsService" クラスの実装を提供することにより) Custom Tabs プロトコルをサポートすべきです。Chrome は、Custom Tabs を実装するそのようなブラウザの1つです。

認可レスポンスを受信するために、プライベート使用 URI スキームは Android Implicit Intents を通じて広くサポートされています。Android App Links を通じた主張された "https" スキームリダイレクト URI は、Android 6.0 以降で利用可能です。両方のタイプのリダイレクト URI は、アプリケーションのマニフェストに登録されます。

完全なオープンソースサンプルは、AppAuth for Android [AppAuth.Android] ライブラリに含まれています。

B.3. Windows Implementation Details (Windows 実装詳細)​

従来型アプリと Universal Windows Platform (UWP) アプリの両方が、ユーザーのブラウザで認可リクエストを実行できます。従来型アプリは通常、認可レスポンスを受信するためにループバックリダイレクトを使用し、ループバックインターフェースでのリスニングはデフォルトのファイアウォールルールで許可されています。ループバックネットワークソケットを作成する際、アプリは他のアプリが同じソケットにバインドするのを防ぐために "SO_EXCLUSIVEADDRUSE" ソケットオプションを設定すべきです (SHOULD)。

UWP アプリは、ブラウザから認可レスポンスを受信するためにプライベート使用 URI スキームリダイレクトを使用でき、これによりアプリがフォアグラウンドになります。プラットフォームでは "URI Activation" として知られており、URI スキームは長さが 39 文字に制限されており、"." 文字を含めることができるため、(第7.1節で要求される) 短い逆ドメイン名ベースのスキームが可能です。

UWP アプリは、認可フロー用に設計された外部ユーザーエージェントである Single Sign-on (SSO) モードで Web Authentication Broker API を代替として使用できます。クッキーはブローカーの呼び出し間で共有されますが、ユーザーの優先ブラウザとは共有されません。つまり、ブラウザにアクティブなセッションがある場合でも、ユーザーは再度ログインする必要があります。ただし、ブローカーで作成されたセッションは、ブローカーを使用する後続のアプリで利用可能になります。パスワードマネージャーの構成など、ユーザーがブラウザに対して行ったカスタマイズは、ブローカーでは利用できない場合があります。外部ユーザーエージェントとして認定されるには、ブローカーは SSO モードで使用されなければなりません (MUST)。

SSO モードで Web Authentication Broker を使用するには、リダイレクト URI は msapp://{appSID} の形式である必要があります。ここで、"{appSID}" はアプリのセキュリティ識別子 (SID) であり、アプリの登録情報で確認するか、"GetCurrentApplicationCallbackUri" メソッドを呼び出すことで見つけることができます。Windows はそのようなリダイレクトで URI オーソリティを強制し、一致する SID を持つアプリのみが Windows でレスポンスを受信できるようにしますが、URI スキームは同じオーソリティが存在しない他のプラットフォーム上のアプリによって主張される可能性があります。したがって、このリダイレクトタイプは、セキュリティ目的でプライベート使用 URI スキームリダイレクトと同様に扱われるべきです。

これらのパターンを示すオープンソースサンプルが利用可能です [SamplesForWindows]。

B.4. macOS Implementation Details (macOS 実装詳細)​

アプリは、ブラウザで URI を開くためのプラットフォーム API を使用して、ユーザーのデフォルトブラウザで認可リクエストを開始できます。

認可レスポンスを受信するために、プライベート使用 URI スキームは macOS での優れたリダイレクト URI の選択肢です。ユーザーはリクエストを起動したアプリにすぐに戻されます。これらは、"CFBundleURLSchemes" キーを使用してアプリケーションのバンドル情報プロパティリストに登録されます。ループバック IP リダイレクトも別の実行可能なオプションであり、ループバックインターフェースでのリスニングはデフォルトのファイアウォールルールで許可されています。

完全なオープンソースサンプルは、AppAuth for iOS and macOS [AppAuth.iOSmacOS] ライブラリに含まれています。

B.5. Linux Implementation Details (Linux 実装詳細)​

ユーザーのデフォルトブラウザで認可リクエストを開くには、ディストリビューション固有のコマンドが必要です。"xdg-open" はそのようなツールの1つです。

ループバックリダイレクトは、Linux 上のデスクトップアプリが認可レスポンスを受信するための推奨されるリダイレクト選択肢です。アプリは、他のアプリが同じソケットにバインドするのを防ぐために、"SO_REUSEPORT" または "SO_REUSEADDR" ソケットオプションを設定すべきではありません (SHOULD NOT)。

に最終更新