リダイレクトURIは、ネイティブモバイルアプリケーションのOAuth実装でセキュリティを提供しますか？

Question

oAuth2.0実装のサーバーと対話し、説明したようにGoogle AppAuthライブラリを使用するネイティブモバイルアプリケーションをAndroidで開発しています。here

1）私たちのアプリケーションに認証コード/アクセストークンを戻す以外に、リダイレクトURIの目的は何ですか？認可リクエストで指定するリダイレクトURIはGoogle APIコンソールに登録されているものと同じでなければならないため、Googleに登録されているアプリケーションと他の場所に制御が戻ることを確実にする媒体ですか？

2）モバイルアプリケーションでアクセストークンとリフレッシュトークンを取得してモバイルに保存しているので（コードサンプルの例に示すように）、誰かがリフレッシュトークン、クライアントID、リダイレクトのこれらの詳細を保持している場合はどうなりますか？ URI。 誰かが自分のデバイス上でこれらの詳細を使用して自分のサーバーにアクセスできますか？

Answer 1

1）認可コード/アクセストークンをアプリケーションに戻す以外に、リダイレクトURIの目的は何ですか。

ほとんどのIDPは、コードとトークンの送信先を制限するために、特定のクライアントIDに関連付けられたリダイレクトURIのホワイトリストをトークン盗難の第1行として使用します。これはhttpsのリダイレクトURIが少なくともスプーフィングに対するいくつかの基本的な保護手段を提供するWebの場合はうまく機能します。

最近まで、httpsリダイレクトURIはネイティブアプリケーションに適していませんでした。 Android MはApp Linksを導入しました。これにより、他の悪意のあるアプリによってハイジャックされることのないようにhttps権限をアプリに要求できます。代わりの方法、PKCEは、わずかに弱い保護を提供しますが、どのAndroidバージョンでも動作します。ただし、PKCEは認可エンドポイントのサポートを必要とします。誰かがリフレッシュトークンの私のこれらの詳細のホールドを取得する場合

2）[...]誰かが自分のデバイス上でこれらの詳細を使用して自分のサーバーにアクセスすることはできますか？

一般的に言えば、はい。トークンが別の悪意のあるアプリケーションに漏洩した場合、トークンがアクセスを許可するデータにアクセスするためにこれらのトークンを使用することができます。これらのような「ベアラトークン」は、通常、トークンの発行者とトークンのユーザーとの間の暗号化された接続を介してそれらを送信するだけで秘密のままでなければなりません。

token channel bindingの作業が進行中です。トークンは、デバイス上のハードウェア暗号モジュールで生成されて格納されている非対称キーペアとの組み合わせでのみ使用できます。そのようなモジュールから秘密鍵を盗むことは、トークン自体を盗もうとするよりもはるかに困難です。

現在のベストプラクティスの概要については、OAuth2 for Native Appsをお読みください。アプリでOAuth2を使用するには、OpenID AppAuthライブラリを使用することをおすすめします。免責事項：私はAppAuthの主任メンテナーです。