2

APIにサーバー側のOAuthを実装しています。私はここで、Googleが完全なJavaScriptで記述されたアプリケーションがそのAPIを使用することを許可していることを見てきました。

この場合、「ビューソース」環境を使用しているため、クライアントシークレットを使用していないため、アプリケーションIDを確認できません。

例：Google用の完全なJavaScriptアプリケーションが表示された場合は、ソースを表示し、クライアントキーを取得して、自分のWebサイトにコードの編集バージョンを配置するだけです。ユーザーが最初のWebサイトでアプリを承認した場合、私は彼のデータを使用できます（アプリが承認されたため、承認部分はユーザーには完全に表示されません）。

ユーザーがアプリを再承認する必要がある場合でも、ユーザーがアプリを承認すると、最初のアプリIDでアクセスできるようになります。

私はこの方法に少し怖いです、そして私はグーグルが文書や承認段階の間に異なるリスクを公開していないことに非常に驚いています。私は何かが欠けているに違いない...あなたは私を助けることができますか？

わかりやすくなったのかよくわかりませんが、ご不明な点がございましたらお問い合わせください。

（そして私の英語でごめんなさい）

4

2 に答える 2

1

あなたが正しいです。アプリケーションに表示されるデータはとclient idですclient secret。ユーザーがアプリケーションを認証するaccess tokenと、次のAPIリクエストに使用する必要のあるが取得されます。アクセストークンは通常、ローカルデータベース内に保存され、すべてのユーザーに固有です（さらには期限切れになる場合もあります）。

結果：にアクセスできる邪悪なユーザーは、アプリケーションにアクセスするためclient idにclient secretアプリケーションを再承認する必要があります。彼はを持っていないので、直接アクセスすることはできませんaccess token。しかし、それを受け入れた後、彼はすべてのデータにアクセスできます。

この問題を解決する1つの方法は、サーバー側で認証を実行することです。サーバーが初期認証を行い、を保存しaccess tokenます。クライアントからAPIにアクセスする場合はaccess token、サーバーから（安全な接続を介してclient id）取得します。APIは通常どおりに使用でき、とは非表示になっているはずですclient secret。これを実装する簡単な方法は、Yahooクエリ言語です。

于 2012-11-02T08:27:40.973 に答える
0

私もそれについてかなり心配していて、私はそれを快適にするためにたくさん読んでいます。実際には、純粋なjavascriptアクセスを許可するWebサーバーがたくさんあります（Facebook、Google、Mercadolibreなど）。

これらの会社は、有効なドメインサーバー名を要求します。つまり、クライアントIDとクライアントシークレットは、Webアプリから要求された場合にのみ使用できます。そうは言っても、私は（あまりにも）もう少し快適です。アプリを偽造するのはそれほど簡単ではなく、11歳の甥はそれを試すのに苦労するでしょう。

とにかく、ブラウザに対して何らかのフィッシング攻撃を使用して、「your-app-domain.com」にいると信じ込ませることができることを私は知っています。これらの前述の企業がこの種の攻撃をどのようにフィルタリングするかはわかりません。

思考：私があなたに持っていた1つのアイデアはあなたの資格情報をクッキーに保存することができました。アプリの起動時にRESTURIを使用し、そこにクレデンシャルを保存します。私が知っている限り、ハッキングをほとんど行わなくてもCookieにアクセスできますが、それは追加の障壁になります。

考え方2：私はモバイル開発者ではないので、モバイルアプリでこの問題を解決する方法を尋ね続けます。アプリを逆コンパイルするのは簡単ではないことを知っていても、それを実行することは可能です。

クライアント側のクレデンシャルストレージを解決する方法や快適にする方法はわかりませんが、この議論に貢献したいと思っています。

于 2013-09-08T15:33:50.453 に答える