RESTful APIの二重認証

Question

私は現在、サードパーティのWebアプリケーションやモバイルアプリケーションからアクセスされるWebサービスのRESTful APIを構築しています。特定のレベルのAPIコンシューマ（ウェブアプリやモバイルアプリ）を管理したいので、特定の悪意のあるクライアントを制限または阻止するAPIリクエストを行うことができます。そのためには、私たちのAPIにアクセスするすべての開発者が私たちからAPIキーを入手し、それを使用してAPIエンドポイントにアクセスしたいと考えています。特定のユーザー情報を扱っていないAPI呼び出しの場合は、唯一必要な認証レベルである&認可です。これは「app」-level A & Aと呼ばれますが、特定のユーザーに属する情報を処理するAPI呼び出しもあります。そのユーザーにログインさせ、アプリケーションにデータへのアクセスを許可する方法が必要です。これにより、第2レベル（または「ユーザー」レベルA & A）が作成されます。

「ユーザー」レベルのA & AにはOAuth2を使用することが非常に意味があり、私はここで何をする必要があるかを十分に理解していると思います。

私はまた、アプリケーション開発者が秘密のAPIキー&の秘密を受け取り、すべての呼び出しでAPIキーを提供し、リクエストに署名するためにシークレットを使用するOAuth1のようなスキームを実装しました（再び、OAuth1のようです。 OAuth1を使用してください）。

今私が持っている問題は、これらの2つの異なるメカニズムと結婚する方法です。私の現在の仮説は、すべてのAPIエンドポイントにアクセスできるようにすべてのリクエストに署名するためにAPIキー/シークレットペアを引き続き使用し、ユーザー固有の情報アプリケーションへのアクセスを必要とするコールではOAuth2フローを通過してアクセストークンそれらを供給する。

私のコミュニティへの質問は、良い解決策のように聞こえるか、これをもっとうまく構築する方法があるということです。

ホイールを再発明するのではなく、私が使用できる既存のソリューションへのリンクもありがとう（私たちのサービスはRuby/Railsベース）。

Answer 1

あなたのキーと秘密のペアは、実際にあなたにモバイルアプリの作者に対する信頼を与えていません。秘密は実行可能ファイルに埋め込まれ、ユーザーに与えられます。実際にユーザーがキーを抽出できないようにすることはできません。

Stack Exchange APIでは、OAuth 2.0を使用しています。私たちができるのは、悪意のあるユーザー（OAuthのない以前のリビジョンのIP）を排除することだけです。私たちは追跡のための鍵を提供していますが、秘密ではありません（価値のないものを許可するので、盗むインセンティブはありません）。

乱用防止の観点からは、認証トークンがない場合はIPに基づいてスロットルを行いますが、ユーザーがある場合はスロットルごとに切り替えます。

純粋に悪意のあるクライアントを扱う場合、私たちは弁護士を解放します（悪意のあるのは、ほとんどの場合cc-wikiガイドラインに違反しています）。技術的な解決策は我々の見積もりでは十分に洗練されていない。悪意のあるクライアントの発生率は実際には非常に低い（1年間の操作では1桁で、毎日のAPIリクエストは数百万件あります）。

要するに、私はOAuth 1.0を取り除き、スロットルをIPベースとユーザーベースのハイブリッドに切り替えます。