OAuth2.0を使用してモバイルアプリのWebAPIに委任された承認を実装しようとしています。仕様によると、暗黙的な付与フローは更新トークンをサポートしていません。つまり、アクセストークンが特定の期間付与されると、トークンの有効期限が切れるか、トークンが取り消されたときに、ユーザーはアプリに再度アクセス許可を付与する必要があります。
仕様に記載されているように、これはブラウザで実行されているJavaScriptコードにとって良いシナリオだと思います。ユーザーがトークンを取得するためにアプリに権限を付与する必要がある時間を最小限に抑えようとしているので、認証コードフローは更新トークンをサポートしているため、適切なオプションのようです。
ただし、このフローは、リダイレクトを実行するためにWebブラウザに大きく依存しているようです。埋め込み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サービスを持たないアプリケーションは、ImplicitGrantフローを使用する必要があります。
結論
最終的な決定では、最終候補のアプローチの適切なリスク評価を行い、その影響をよりよく理解した後、目的のユーザーエクスペリエンスだけでなく、リスク選好も考慮に入れる必要があります。
すばらしい読み物はここにありますhttps://auth0.com/blog/oauth-2-best-practices-for-native-apps/
もう一つはあるhttps://www.oauth.com/oauth2-servers/oauth-native-apps/いる状態
現在の業界のベストプラクティスは、クライアントシークレットを省略して承認フローを使用し、外部ユーザーエージェントを使用してフローを完了することです。外部ユーザーエージェントは通常、デバイスのネイティブブラウザーであり（ネイティブアプリとは別のセキュリティドメインを使用）、アプリはCookieストレージにアクセスしたり、ブラウザー内のページコンテンツを検査または変更したりできません。
PKCEの考慮事項
https://www.oauth.com/oauth2-servers/pkce/で説明されているPKCEも検討する必要があります
具体的には、承認サーバーも実装している場合は、https： //www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/に、
Webビューに関する考慮事項
Webビュー、つまり埋め込みユーザーエージェントを使用する実際の例はたくさんありますが、このアプローチは避ける必要があり（特にアプリがファーストパーティでない場合）、場合によってはAPIを抜粋として使用することが禁止される可能性があります下記のここ実証
OAuth 2.0認証ページを埋め込もうとすると、アプリケーションがFitbitAPIから禁止されます。
セキュリティ上の理由から、OAuth2.0認証ページは専用のブラウザビューで表示する必要があります。Fitbitユーザーは、URLバーやトランスポート層セキュリティ（TLS）証明書情報など、ブラウザーが提供するツールを使用している場合にのみ、本物のFitbit.comサイトで認証されていることを確認できます。
ネイティブアプリケーションの場合、これは認証ページをデフォルトのブラウザで開く必要があることを意味します。ネイティブアプリケーションは、リダイレクトURIとしてカスタムURLスキームを使用して、ユーザーをブラウザーからアクセス許可を要求するアプリケーションにリダイレクトできます。
iOSアプリケーションは、アプリをSafariに切り替える代わりに、SFSafariViewControllerクラスを使用する場合があります。WKWebViewまたはUIWebViewクラスの使用は禁止されています。
Androidアプリケーションは、アプリをデフォルトのブラウザに切り替える代わりにChromeカスタムタブを使用する場合があります。WebViewの使用は禁止されています。
さらに明確にするために、上記のベストプラクティスリンクの以前のドラフトのこのセクションからの引用を次に示します。
一般にWebビューで実装される埋め込みユーザーエージェントは、ネイティブアプリを承認するための代替方法です。ただし、定義上、サードパーティによる使用は安全ではありません。これには、ユーザーが完全なログイン資格情報を使用してサインインする必要がありますが、それは、それほど強力ではないOAuth資格情報にダウンスコープするためだけです。
信頼できるファーストパーティアプリで使用されている場合でも、埋め込まれたユーザーエージェントは、必要以上に強力な資格情報を取得することで最小特権の原則に違反し、攻撃対象領域を増やす可能性があります。
埋め込みユーザーエージェントの一般的なWebビューベースの実装では、ホストアプリケーションは次のことができます。フォームに入力されたすべてのキーストロークをログに記録して、ユーザー名とパスワードを取得します。フォームを自動的に送信し、ユーザーの同意をバイパスします。セッションCookieをコピーし、それらを使用してユーザーとして認証されたアクションを実行します。
通常のアドレスバーやブラウザが備えているその他のID機能を使用せずに、埋め込みWebビューに資格情報を入力するようユーザーに促すと、ユーザーは正規のサイトにサインインしているかどうかを知ることができなくなり、サインインしている場合でもトレーニングを受けます。最初にサイトを検証せずに資格情報を入力しても問題ないこと。
セキュリティ上の懸念は別として、Webビューは認証状態を他のアプリやシステムブラウザと共有しないため、ユーザーはすべての承認リクエストにログインする必要があり、ユーザーエクスペリエンスが低下します。
上記の理由により、信頼できるファーストパーティアプリが他のアプリの外部ユーザーエージェントとして機能する場合、または複数のファーストパーティアプリにシングルサインオンを提供する場合を除いて、埋め込みユーザーエージェントの使用は推奨されません。
承認サーバーは、可能であれば、独自のものではない組み込みユーザーエージェントを介してログインを検出およびブロックするための措置を講じることを検討する必要があります。
いくつかの興味深い点もここで提起されています：https：//security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- a
残念ながら、この質問に対する明確な答えはないと思います。ただし、私が特定したオプションは次のとおりです。
ユーザーに資格情報を要求しても問題がない場合は、リソース所有者のパスワード資格情報を使用します。ただし、これはいくつかの理由で不可能な場合があります。
ブラウザベースのフローを使用する必要がある場合は、認証コードフローを使用してください。ここで、の定義はredirect_uri主要な課題であり、次のオプションがあります。
redirect_uri（eg urn:ietf:wg:oauth:2.0:oob）は、クライアントアプリにリダイレクトする代わりに、認証エンドポイントに認証コードを表示するように通知します。ユーザーはこのコードを手動でコピーするか、アプリがHTMLドキュメントのタイトルからコードを取得しようとすることができます。localhostデバイスでサーバーを使用します（ポート管理は簡単ではない場合があります）。myapp://...逆参照すると登録済みの「ハンドラー」がトリガーされるカスタムURIスキーム（例）を使用します（詳細はモバイルプラットフォームによって異なります）。お役に立てれば
ペドロ
1.暗黙の付与タイプ
暗黙的な付与タイプは、モバイルアプリで非常に人気があります。しかし、それはこのように使用されることを意図していませんでした。リダイレクトにはセキュリティ上の懸念があります。ジャスティンリッチャーは述べています：
問題は、リモートサーバーのURLとは異なり、特定のリダイレクトURIと特定のモバイルアプリケーション間のバインディングが確実に守られるようにする信頼できる方法がないことに気付いたときに発生します。デバイス上のすべてのアプリは、リダイレクトプロセスに自分自身を挿入して、リダイレクトURIを提供するように試みることができます。そして、何を推測しますか。ネイティブアプリケーションで暗黙的なフローを使用した場合は、攻撃者にアクセストークンを渡しただけです。その時点からの回復はありません—彼らはトークンを持っており、それを使用することができます。
また、アクセストークンを更新できないという事実とともに、回避することをお勧めします。
2.認証コード付与タイプ
認証コードの付与には、クライアントシークレットが必要です。ただし、モバイルアプリのソースコードに機密情報を保存しないでください。人々はそれらを抽出することができます。クライアントシークレットを公開しないようにするには、Facebookが書いているように、仲介者としてサーバーを実行する必要があります。
最高のセキュリティを提供するために、アプリアクセストークンはアプリのサーバーから直接使用することをお勧めします。ネイティブアプリの場合、アプリが独自のサーバーと通信し、サーバーがアプリアクセストークンを使用してFacebookにAPIリクエストを送信することをお勧めします。
理想的なソリューションではありませんが、モバイルデバイスでOAuthを実行するための新しいより良い方法があります：コード交換用のプルーフキー
3. PKCE（コード交換用のプルーフキー）を使用した認証コード付与タイプ
制限から、クライアントシークレットなしで認証コードを使用できる新しい手法が作成されました。完全なRFC7636またはこの短い紹介を読むことができます。
PKCE（RFC 7636）は、クライアントシークレットを使用しないパブリッククライアントを保護するための手法です。
これは主にネイティブアプリとモバイルアプリで使用されますが、この手法はすべてのパブリッククライアントにも適用できます。承認サーバーによる追加のサポートが必要なため、特定のプロバイダーでのみサポートされます。
モバイルアプリケーションでWebビューを使用することは、AndroidプラットフォームにOAuth2.0プロトコルを実装するための手頃な方法であるはずです。
redirect_uriフィールドについては、クラス内http://localhostのonPageStarted関数の実装をオーバーライドし、パラメーターを確認した後WebViewClientからWebページの読み込みを停止できるため、アプリケーション内にHTTPサーバーを移植する必要がないので良い選択だと思います。http://localhosturl
public void onPageStarted(final WebView webView, final String url,
final Bitmap favicon) {}
認証のための最もスムーズなユーザーエクスペリエンス、および実装が最も簡単なのは、アプリにWebビューを埋め込むことです。認証ポイントからWebビューによって受信された応答を処理し、エラー（ユーザーのキャンセル）または承認を検出します（およびURLクエリパラメーターからトークンを抽出します）。そして、私はあなたが実際にすべてのプラットフォームでそれを行うことができると思います。私はこれを次のように正常に動作させました：ios、android、mac、windows store 8.1アプリ、windows phone8.1アプリ。私は次のサービスのためにこれを行いました：dropbox、googleドライブ、onedrive、box、basecamp。Windows以外のプラットフォームの場合、プラットフォーム固有のAPI全体を公開しないと思われるXamarinを使用していましたが、これを可能にするのに十分な公開を行いました。したがって、クロスプラットフォームの観点からも、非常にアクセスしやすいソリューションであり、