web-dev-qa-db-ja.com

REST APIの本当に良い認証メカニズムを実装したい

私はWebアプリケーション（Angularのシングルページアプリケーション）を所有しています。これは、（Play Framework 2.2.1を使用した）サーバー側アプリケーションに基づくREST APIのセットを通じていくつかのデータを要求します。

基本的に、私はセキュリティの専門家ではないので、最初は簡単に認証を実装するための「ツール」を使用したいと思いました。したがって、私は SecureSocial を使用することを選択しました。

私は自分のニーズに合わせてそれをカスタマイズしますが、REST認証方式に関するいくつかのドキュメントを読んだ後、私は間違った方法にある可能性が高いことに気付きました。

どうして？完全なステートレスソリューションではなく、セッショントークンメカニズムに基づいているからです。

つまり、認証ワークフローは次のとおりです。

  • ユーザーは従来の形式（電子メール/パスワード）を使用してWebアプリケーションにログインします。
  • サーバーは、資格情報の有効性をチェックし（パスワードのBCryptハッシュを比較）、有効であれば、一種の認証トークンを含むCookieを返します。この認証トークンはサーバーキャッシュ（Memcachedストアにアクセスするように構成されたPlay）にも保存され、ユーザーが（可視性に関して）制限された機能を要求するたびにいくつかの比較を行うことができます。

このソリューションの長所：
..これは[〜＃〜] restricted [〜＃〜]APIへのアクセスを制御するのに適しています。

欠点：

  • このソリューションでは、リクエストの試行ごとにクライアントが提供する認証トークンを比較するために、サーバーに認証トークンを格納するデータストアが必要です。現在、Memcachedを使用しています。
  • 一部の小さなクライアントリストへのアクセスを制限できません。実際、すべてのRESTアプリケーションへのAPIアクセスのみを制限したい場合はどうしますか？ある種のAPIキー/ API秘密キーが、認証ではなく認証を実装するために必要です。
    たとえば、外部のコマンドラインや外部のWebサイトが、適切な資格情報を提供することによって認証ステップに成功した場合でも、APIにアクセスすることを厳密に許可したくありません。
    最悪の場合、最初に公開された一部のデータにアクセスするのに問題はありません。たとえば、正確なデータのセットのリストを取得するなど、認証が必要ありません。
  • HTTPS転送が保証されていない場合、いくつかの既知の攻撃に対して非常に脆弱であるようです。

HTTP BASICについて多くのことを聞いて読みましたが、それは避けるべきだと思われます： http://adrianotto.com/2013/ 02/why-http-basic-auth-is-bad /

次に、Amazonが実装するHMACソリューションについて読みましたが、それはかなり良いソリューションのようです。 OAuth1は複雑なように聞こえますが、簡単な場合には必要です。

HMACソリューションを実装する必要がありますか？
HMACソリューションはブラウザと本当に互換性がありますか？つまり、ユーザーが毎回認証する必要なく、いくつかの異なる操作を呼び出すことができますか？
このトリックを行うには、この場合のトークン交換が必要ですか？

Webアプリケーション/ブラウザーを扱っているときに、誰かがHMACの概念を紹介してくれたら本当に嬉しいです。
確かに、ブラウザと組み合わせたHMACスキームに関するドキュメントを見つけるのに苦労しています。

または、Oauthソリューションを本当に信頼していますか？...

私は主題について瞑想しています...

authenticationcookiesresthmac
5
Mik378

独自の認証をロールバックしないでください、Json Web Token（JWT）はあなたが望むことを実行できます、それはoAuthよりも簡単で、HMACを使用します

2
user618509

OAuthは、3者シナリオの場合に役立ちます。これは、クライアントがリソースサービスでアクセスできるものを決定する認証サービスがある場合です。このシナリオでは、クライアントは、認証サービスがユーザーに操作の実行を許可したことを証明するトークンを提供することにより、リソースに接続します。その音から、あなたは本当にOAuthを必要としません。

サーバー間APIを実行している場合（つまり、ユーザーのブラウザーではなく、別のサーバーからサービスにアクセスしている場合）、サービスがHTTPSで実行されている限り（つまり、暗号化されていないHTTPがない限り）、HTTP Basicは完全に問題ありません。 HMACは、この状況を実際にはより安全にしません。少なくともMITM攻撃者による改ざんを防ぐため、暗号化されていないHTTPでサービスを実行する必要がある場合はHMACが役立つことがありますが、最近のHTTPSのセットアップは非常に簡単であるため、HMACは誰よりもはるかに複雑です。

Basicよりも優れたセキュリティが必要な場合は、相互TLS認証（別名TLSクライアント認証）を使用できます。相互TLSは、非対称暗号化を使用するため、Basicよりも優れています。つまり、クライアントまたはサーバーのいずれかが侵害されても、他のキーのセキュリティは侵害されません。多くの状況では、この利点はそれほど重要ではありませんが、状況によっては適用される場合があります。

1
Lie Ryan

少し遅いのはわかっていますが、それを見て、とにかく答えようと思いました。 HMACは（Keyed） -Hash Message Authentication Codeです。 APIを保護するための仕組みは次のとおりです。メッセージと組み合わせてハッシュされるAPIトークンを作成します。このHMACは、ユーザー名とAPI呼び出しと共に送信され、APIサーバーに呼び出されます。

https://apiserver.com/api/?mac=098f6bcd4621d373cade4e832627b4f6&user=leaustinwile&command=url_encode({json:"test"})。

次に、APIバックエンドはメッセージを受け取り、ユーザーのAPIトークンを見つけることにより、HMACサーバー側を計算します。

https://localhost/get_api_token/<user>

サーバー側で計算されたHMACがメッセージと共に送信されたHMACと一致する場合、メッセージが（インスタンスの正しいOriginから）正当であることが確認されているため、API呼び出しが呼び出されます。

0
leaustinwile