OAuth2とSSLでAPIを保護するには十分ですか

Question

私はAPIを保護する最良の方法を見つけようとしています。私はSSLのみを許可し、認証にはOAuth2を使用していますが、それは十分ではないようです。

私が心配しているのは、正当なクライアントがAPIに対して行ったリクエストを調べて、OAuthのclient_idを盗むことができるということです。その時点で、正当なクライアントに偽装したい任意の要求を作成することができます。

これを防ぐ方法はありますか？私は人々がクライアントとサーバーだけに知られている秘密鍵を使ってパラメータのHMACハッシュを使用するのを見ましたが、私はそれに2つの問題があることを見ています。

1. 悪意のあるユーザーがクライアントを逆コンパイルして秘密鍵を把握するのは非常に困難です（不可能です）。
2. いくつかのパラメータは、のHMACハッシュを作るのが奇妙に思えます。たとえば、パラメータがファイルのバイトであった場合、HMACハッシュにすべてのものを含めますか？

Answer 1

正当なクライアントとあなたのAPIの間に相互認証されたSSLを配備することができます。自己署名SSLクライアント証明書を生成し、それをクライアントに保管します。クライアント側の認証を要求し、クライアントに配布した証明書のみを受け入れるようにサーバーを構成します。接続しようとしている誰かがそのクライアント証明書を持っていない場合、SSLセッションを確立できず、接続も確立されません。正当なクライアントとサーバーを制御していると仮定すると、ここではCA発行の証明書は必要ありません。クライアント側とサーバー側の両方の証明書の信頼を制御するので、自己署名証明書を使用するだけです。

ここで、あなたのクライアントをリバースエンジニアリングしてクレデンシャル（この場合はクライアント証明書に属する秘密鍵）を回復させないようにするのは本当に難しいと言います。そしてあなたは正しい。通常、その鍵（および証明書）をsometypeの鍵ストア（Androidを使用している場合はKeyStore）に格納し、その鍵ストアを暗号化します。その暗号化はパスワードに基づいているため、（1）クライアントのどこかにパスワードを保存するか、（2）クライアントアプリケーションを起動するときにパスワードを尋ねる必要があります。あなたがしなければならないことは、あなたのユースケースに依存します。 （2）が受け入れ可能な場合は、暗号化され、パスワードはどこにも保存されないため、リバースエンジニアリングから資格を保護しています（ただし、ユーザーは毎回入力する必要があります）。 （1）を実行すると、クライアントをリバースエンジニアリングし、パスワードを取得し、キーストアを取得し、秘密鍵と証明書を復号化し、サーバーに接続できる別のクライアントを作成できます。

これを防ぐには何もできません。コードを難しくする（難読化などで）リバースエンジニアリングを行うことはできますが、不可能にすることはできません。これらのアプローチを使用して軽減しようとしているリスクはどれか、それを軽減するためにはどれだけの作業が必要なのかを判断する必要があります。

Answer 2

OAuth認証手順はSSL自体で実行していますか？ OAuthサーバーの証明書を最新の状態に保つように注意する必要がありますが、あらゆる種類の詮索を防ぎます。あなたは、言っ

;（それは努力のも、漠然と、合理的な金額を偽造することはまだ不可能だそれは秘密にする必要がある唯一の秘密鍵だノート、OAuthのサーバ公開SSLアイデンティティを持つことができます。）あなたが守っているものをもっと慎重にする必要があります。なぜ人々はあなたのクライアントコードをまったく使用しなければならないのですか？なぜそれは「秘密」でなければならないのですか？それを捨てて、あなたのサーバーにスマート（ログインIDの検証を含む）を置くのが簡単です。誰かが自分のクライアントを書くことを望むなら、それを聞かせてください。誰かが愚かな方法で公に自分のアカウントを振りたい場合は、愚かさから生じる費用を請求してください。