モバイルアプリの正しいOAuth 2.0フロー
OAuth 2.0を使用して、モバイルアプリのWeb APIに委任された承認を実装しようとしています。仕様によると、暗黙的な許可フローは更新トークンをサポートしません。特定の期間、ユーザーはトークンの有効期限が切れるか、取り消されると、アプリに再度許可を与える必要があります。これは、仕様で述べられているように、ブラウザで実行するJavaScriptコードにとっては良いシナリオだと思います。ユーザーがトークンを取得するためにアプリにアクセス許可を付与する必要がある時間を最小限に抑えるため、認証コードフローは更新トークンをサポートするため、適切なオプションのように見えますが、このフローは、埋め込みWebブラウザーが使用されている場合、このフローがモバイルアプリに適したオプションであるかどうか疑問に思っています。
明確化：モバイルアプリ=ネイティブアプリ
他のコメントやオンラインのいくつかのソースで述べられているように、暗黙的はモバイルアプリに自然にフィットするように見えますが、最良の解決策は必ずしも明確ではありません（実際、以下で説明する理由から暗黙的は推奨されません）。
ネイティブアプリOAuth2ベストプラクティス
どのアプローチを選択するか（考慮すべきいくつかのトレードオフがあります）、OAuth2を使用したネイティブアプリのここで概説するベストプラクティスに注意を払う必要があります。 https://tools.ietf.org/html/rfc8252
次のオプションを検討してください
暗黙的
暗黙的に使用する必要がありますか？
セクション8.2から引用するには https://tools.ietf.org/html/rfc8252#section-8.2
OAuth 2.0暗黙的許可認証フロー（OAuth 2.0 [RFC6749]のセクション4.2で定義））は、通常、ブラウザで認証要求を実行する方法で機能します。 URIベースのアプリ間通信を介して承認応答を受信します。
ただし、暗黙フローはPKCE [RFC7636]（セクション8.1で必要）で保護できないため、ネイティブアプリでの暗黙フローの使用は推奨されません。暗黙的なフローを介して付与されたアクセストークンは、ユーザーの操作なしで更新することもできません。これにより、更新トークンを発行できる承認コード付与フローが、アクセストークンの更新を必要とするネイティブアプリ承認のより実用的なオプションになります。
認証コード
承認コードを使用する場合、1つのアプローチは、デバイス上の分散アプリにトークン要求を保存しないように、クライアントシークレットでトークン要求を強化する独自のWebサーバーコンポーネントを介してプロキシすることです。
以下からの抜粋： https://dev.fitbit.com/docs/oauth2/
承認コード付与フローは、Webサービスを持つアプリケーションに推奨されます。このフローには、アプリケーションのクライアントシークレットを使用したサーバー間通信が必要です。
注：アプリストアやクライアント側のJavaScriptからダウンロードしたアプリなど、分散コードにクライアントシークレットを配置しないでください。
Webサービスを持たないアプリケーションは、暗黙的な許可フローを使用する必要があります。
結論
最終決定は、希望するユーザーエクスペリエンスだけでなく、最終候補のアプローチの適切なリスク評価を行い、その意味をよりよく理解した後のリスクに対する欲求も考慮に入れる必要があります。
素晴らしい読み物はこちら https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
もう1つは https://www.oauth.com/oauth2-servers/oauth-native-apps/ です
現在の業界のベストプラクティスは、クライアントシークレットを省略しながら認証フローを使用し、外部ユーザーエージェントを使用してフローを完了することです。通常、外部ユーザーエージェントはデバイスのネイティブブラウザーであり（ネイティブアプリとは別のセキュリティドメインを使用）、アプリがCookieストレージにアクセスしたり、ブラウザー内のページコンテンツを検査または変更することはできません。
PKCEの考慮事項
ここで説明されているPKCEも考慮する必要があります https://www.oauth.com/oauth2-servers/pkce/
具体的には、承認サーバーも実装している場合、- https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ はあなたがすべき
- クライアントがリダイレクトURLのカスタムURLスキームを登録できるようにします。
- デスクトップアプリをサポートするために、任意のポート番号でループバックIPリダイレクトURLをサポートします。
- ネイティブアプリが秘密を保持できると想定しないでください。すべてのアプリに公開か機密かを宣言するよう要求し、機密アプリにのみクライアントシークレットを発行します。
- PKCE拡張機能をサポートし、パブリッククライアントがそれを使用することを要求します。
- 認証ブラウザがシステムブラウザで起動されるのではなく、ネイティブアプリのウェブビューに埋め込まれていることを検出し、それらの要求を拒否します。
Webビューの考慮事項
Webビューを使用した野生の例、つまり組み込みのユーザーエージェントが多数ありますが、このアプローチは回避する必要があり（特にアプリがファーストパーティでない場合）、場合によっては抜粋としてAPIの使用が禁止されることがあります以下から here を示します
OAuth 2.0認証ページの埋め込みを試みると、Fitbit APIからアプリケーションが禁止されます。
セキュリティを考慮して、OAuth 2.0承認ページは専用のブラウザビューで表示する必要があります。Fitbitユーザーは、提供されるツールを使用している場合、Fitbit.comサイトで認証されていることを確認できますブラウザ（URLバーやTransport Layer Security（TLS）証明書情報など）。
ネイティブアプリケーションの場合、これは、認証ページをデフォルトのブラウザーで開く必要があることを意味します。ネイティブアプリケーションは、カスタムURLスキームをリダイレクトURIとして使用して、ユーザーをブラウザーからアクセス許可を要求するアプリケーションにリダイレクトできます。
iOSアプリケーションは、アプリをSafariに切り替える代わりにSFSafariViewControllerクラスを使用する場合があります。 WKWebViewまたはUIWebViewクラスの使用は禁止されています。
Androidアプリケーションは、アプリをデフォルトのブラウザーに切り替える代わりに、Chromeカスタムタブを使用できます。WebViewの使用は禁止されています。
さらに明確にするために、上記のベストプラクティスリンクの前草案の このセクション からの引用を以下に示します。
一般にWebビューで実装される組み込みユーザーエージェントは、ネイティブアプリを認証するための代替方法です。ただし、定義上、サードパーティによる使用は安全ではありません。完全なログイン認証情報を使用してサインインするユーザーが関与しますが、それらは、より強力ではないOAuth認証情報に限定されます。
信頼できるファーストパーティアプリケーションで使用されている場合でも、組み込みのユーザーエージェントは、必要以上に強力な資格情報を取得することにより、最小特権の原則に違反し、潜在的に攻撃対象を拡大します。
組み込みユーザーエージェントの典型的なWebビューベースの実装では、ホストアプリケーションは次のことができます。フォームに入力されたすべてのキーストロークを記録して、ユーザー名とパスワードをキャプチャします。フォームを自動的に送信し、ユーザーの同意をバイパスします。セッションCookieをコピーし、それらを使用してユーザーとして認証されたアクションを実行します。
ブラウザーが持っている通常のアドレスバーや他の識別機能なしで、ユーザーが埋め込みWebビューに資格情報を入力することを奨励し、ユーザーが正当なサイトにサインインしているかどうかを知ることを不可能にします最初にサイトを検証せずに資格情報を入力してもかまいません。
セキュリティ上の懸念は別として、Webビューは他のアプリやシステムブラウザーと認証状態を共有しないため、ユーザーはすべての承認要求に対してログインする必要があり、ユーザーエクスペリエンスが低下します。
上記の理由により、信頼できるファーストパーティアプリが他のアプリの外部ユーザーエージェントとして機能する場合、または複数のファーストパーティアプリにシングルサインオンを提供する場合を除き、埋め込みユーザーエージェントの使用は推奨されません。
許可サーバーは、可能な場合、自身ではない組み込みのユーザーエージェントを介してログインを検出およびブロックするための手順を検討する必要があります。
いくつかの興味深い点もここに挙げられます： https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what- are-the-a
残念ながら、この質問に対する明確な答えはないと思います。ただし、私が特定したオプションは次のとおりです。
ユーザーに資格情報を要求してもよい場合は、 Resource Owner Password Credentials を使用します。ただし、これはいくつかの理由で不可能な場合があります。
- ユーザビリティまたはセキュリティポリシーにより、アプリに直接パスワードを挿入することは禁止されています
- 認証プロセスは外部のIDプロバイダーに委任され、HTTPリダイレクトベースのフロー（OpenID、SAMLP、WS-Federationなど）を介して実行する必要があります
ブラウザベースのフローを使用する必要がある場合は、 Authorization Code Flow を使用します。ここで、
redirect_uriの定義は大きな課題であり、次のオプションがあります。- https://developers.google.com/accounts/docs/OAuth2InstalledApp で説明されている手法を使用します。ここで、特別な
redirect_uri（たとえばurn:ietf:wg:oauth:2.0:oob）が表示する承認エンドポイントを通知しますクライアントアプリにリダイレクトする代わりに認証コード。ユーザーはこのコードを手動でコピーするか、アプリがHTMLドキュメントのタイトルから取得しようとすることができます。 - デバイスで
localhostサーバーを使用します（ポート管理は簡単ではない場合があります）。 - カスタムURIスキーム（例：
myapp://...）を使用します。これは、逆参照されると登録済みの「ハンドラー」をトリガーします（詳細はモバイルプラットフォームによって異なります）。 - 可能であれば、Windows 8で WebAuthenticationBroker などの特別な「Webビュー」を使用して、HTTPリダイレクト応答を制御およびアクセスします。
- https://developers.google.com/accounts/docs/OAuth2InstalledApp で説明されている手法を使用します。ここで、特別な
お役に立てれば
ペドロ
TL; DR：[〜＃〜] pkce [〜＃〜] で認可コード付与を使用
1。暗黙的な付与タイプ
暗黙的な付与タイプは、モバイルアプリで非常に人気があります。しかし、このように使用することを意図したものではありませんでした。リダイレクトにはセキュリティ上の懸念があります。 Justin Richer州 ：
問題は、リモートサーバーのURLとは異なり、特定のリダイレクトURIと特定のモバイルアプリケーション間のバインディングを確実に保証する信頼できる方法がないことを認識したときに発生します。デバイス上のアプリは、リダイレクトプロセスに自分自身を挿入し、リダイレクトURIを提供させることができます。推測します。ネイティブアプリケーションで暗黙的なフローを使用している場合は、攻撃者にアクセストークンを渡しただけです。その時点から回復することはできません-トークンを手に入れ、彼らはそれを使用できます。
また、アクセストークンを更新できないため、回避する方が良いという事実もあります。
2。認証コード付与タイプ
認証コードの付与には、クライアントシークレットが必要です。ただし、モバイルアプリのソースコードに機密情報を保存しないでください。人々はそれらを抽出できます。クライアントシークレットを公開しないようにするには、サーバーを仲介者として実行する必要があります Facebookの書き込み ：
最高のセキュリティを提供するために、アプリのアクセストークンはアプリのサーバーからのみ直接使用することをお勧めします。ネイティブアプリの場合、アプリが自分のサーバーと通信し、サーバーがアプリアクセストークンを使用してFacebookにAPIリクエストを行うことをお勧めします。
理想的なソリューションではありませんが、新しい、より良い方法がありますOAuthモバイルデバイスで：コード交換用の証明キー
3。 PKCE（コード交換の証明キー）を使用した認証コード付与タイプ
制限を超えて、クライアントシークレットなしで認証コードを使用できる新しい手法が作成されました。完全な RFC 7636 または この短い紹介 を読むことができます。
PKCE（RFC 7636）は、クライアントシークレットを使用しないパブリッククライアントを保護する手法です。
これは主にネイティブアプリとモバイルアプリで使用されますが、この手法はどの公開クライアントにも適用できます。認証サーバーによる追加サポートが必要なため、特定のプロバイダーでのみサポートされます。