5

OAuth2 を iOS および Android ネイティブ アプリケーションに統合する必要があります。私は OAuth2 とモバイル アプリケーションについて調査しており、このドキュメントを見つけました - Google APIs - Using OAuth 2.0 for Installed Applications

上記のドキュメントでは基本的に、モバイル アプリケーションで Goolge OAuth 2.0 エンドポイントを使用する方法について詳しく説明しています。

これがドキュメントの内容です-

  1. アプリケーションを登録するときに、アプリケーションがインストール済みアプリケーションであることを指定します。これにより、redirect_uri パラメータの値が異なります。
  2. 登録時に取得した client_id と client_secret は、アプリケーションのソース コードに埋め込まれます。このコンテキストでは、client_secret は明らかにシークレットとして扱われません。
  3. 認証コードは、ブラウザーのタイトル バーでアプリケーションに返されるかhttp://localhost、クエリ文字列のポートに返されます。

ユーザーがスマートフォンに 2 つのアプリケーションをインストールしているとします。

App1 - Google OAuth2.0 エンドポイントを使用する正当なアプリ

App2 - 悪意のあるアプリ

実際のところ、ネイティブ モバイル アプリケーション内で OAuth2.0 エンドポイントを統合/使用する上記の手法が安全でないのか、それとも何か不足しているのかは定かではありません。ここに私の質問があります -

  • redirect_uri はhttp://localhostURL にすることができ、任意のポート番号を含めることができます。ポート番号は初期 API 構成の一部ではないため、任意の有効なポート番号にすることができます。また、client_id (いずれにしてもシークレットではないはずです) と client_secret は、モバイル アプリケーションのソース コードに埋め込まれているため、実際にはシークレットではありません。

上記の条件を使用すると、次の可能性はありません-

  1. ユーザーが App2 を起動します
  2. App2 はユーザーを Google OAuth2.0 エンドポイントにリダイレクトしますが、リクエストには App2 に App1 の client_id と、App2 がリッスンしているローカル ポート番号が含まれています。
  3. ユーザーがリダイレクトされ、Google OAuth2.0 エンドポイントに認証されると、Google はユーザーに「App1 (正当なアプリ) がユーザーに代わって Google API の/データへのアクセスを求めている」ことを示します。ユーザーは、アクセスを求めているのは App1 だと思って [はい] をクリックする可能性があります。
  4. その後、Google OAuth2.0 は App2 に認証コードを発行し、App2 は App1 の client_id と client_secret を含む次のリクエストを行い、access_token と refresh_token を取得して、Google からユーザー データにアクセスし続けることができます。
  • redirect_uri は - urn:ietf:wg:oauth:2.0:oob の場合もあり、これは -

この値は、ブラウザーのタイトル バーに認証コードを返す必要があることを Google 認証サーバーに通知します。これは、重要なクライアント構成がないと、クライアントが HTTP ポートでリッスンできない場合に役立ちます。Windows アプリケーションには、この特性があります。

この値を使用すると、アプリケーションは、ページが読み込まれ、HTML ページのタイトルに認証コードが含まれていることを認識できます。認証コードを含むページがユーザーに表示されないようにする場合は、ブラウザ ウィンドウを閉じるかどうかはアプリケーション次第です。これを行うメカニズムは、プラットフォームによって異なります。

上記は、ブラウザ ウィンドウのタイトルで認証コードが返されることを意味します。

私の質問は、App2 は、ページが読み込まれて認証コードを取得したことを感知し、それを (App1 の前に) client_id と client_secret と共に使用して、access_token と refresh_token を取得できるかということです。ブラウザ インスタンスはグローバルで、任意のアプリがそれを監視できますか。また、上記の攻撃シナリオは有効ですか、それともブラウザ インスタンスはアプリケーション固有であり、App1 のみが変更を感知/監視できるようになっていますか?

私の理解は正しいですか、それとも何か不足していますか? 上記の脅威を緩和する緩和策が欠けていますか? または、モバイル OS プラットフォームを使用している場合、上記のリスクは有効ですが、受け入れられますか?

モバイル アプリケーションで OAuth2.0 を使用する安全な方法は何ですか? - ブラウザー ページに認証コードを表示し、ユーザーにアプリケーション内で手動で入力してもらいますか? その場合、ブラウザー インスタンスはプライベートなので、ユーザーが正当な API に入力する前に、別のアプリケーションがそれを監視して認証コード自体を取得することはできませんか?

どんな助けでも大歓迎です

よろしくお願いいたします。

4

2 に答える 2

0

この質問に対する直接的な回答ではありませんが、私のようにここに来て、時代遅れの回答を得た人向けです。ここから始めるのがおそらく最善です。GoogleはOAuth Java ライブラリを公開しており、 Scribeは Java 対応です。

于 2015-03-25T14:45:45.073 に答える
0

私の経験から、認証コードをクリーンな方法で取得することを実際にサポートしているライブラリはほとんどないことがわかりました。

ほとんどのモバイル プラットフォームでは、リダイレクト URL (http またはカスタム スキーム) を「聞く」ことができます。

たとえば、Android では、アクセス トークンを取得するアクティビティを簡単に作成できます (リダイレクト URL を介して受け取る認証コードに基づいて)。

    <activity android:name=".OAuthAccessTokenActivity" android:launchMode="singleTask">>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="http" android:host="localhost"  />
        </intent-filter>
    </activity>

この場合

http://localhost

Android のようなモバイル プラットフォームでは、これは当然のことのように思えます。

iOS でも同じことができますが、私の記憶が正しければ、iOS 用の Google OAuth ライブラリはページ タイトル アプローチを使用します。

技術的には、2 つのフローに違いはありません。唯一の違いは、リダイレクト URL の構文であるため、認証コードの場所が異なります。

セキュリティの観点からは、OAuth2 クライアント シークレットがなければ、認証コードだけでは意味がありません。

ユーザーに認証コードを入力させることは、Oauth2 フローで見慣れていませんが、可能です。セキュリティ的に何かを追加することに疑いがある場合。私見それはユーザーを苛立たせるだけです。

これは、認証コードを取得して処理するさまざまな方法があることを意味するものではありません (localhost またはカスタム URI スキームによるリダイレクト、または手動配信によるコードの自動キャプチャ)

于 2013-08-07T11:16:24.260 に答える