8

既知の一連のサーバーからのみアクセスできる REST API を構築しています。私の質問は、ブラウザ ベースのクライアントから直接アクセスできない場合、どのようなセキュリティ メカニズムが必要かということです。

現在持っているもの:

  • 明らかに HTTPS 経由
  • HTTP 認証を有効にすると、API コンシューマはキーとパスワードを持っています

次のことが必要ですか。

  • md5(timestamp + token)たとえば、リクエスト用に形成され、エンドポイントで検証される変更キーを作成しますか?
  • OAuth (2-legged 認証) を使用しますか?
4

4 に答える 4

2

関係ありません-ブラウザからかどうか。

次のことが必要ですか？

リクエスト用に作成され、エンドポイントで検証されるmd5（timestamp + token）などの変更キーを作成しますか？

oauth（2本足の認証）を使用しますか？

OAuthを使用すると、これらの両方の質問が解決されます。そして、OAuthの使用法は次の理由で優れています。

  • あなたは車輪の再発明をしていません

  • テクノロジースタックに応じて、すでに多くのライブラリとアプローチがあります

JWTトークンを使用して、サービス間でカスタムクレームを含むセキュリティコンテキストを渡すこともできます。

また、参考として、さまざまなプロバイダーが問題をどのように解決するかを確認できます。たとえば、Azure Active Directoryは、この目的のために代わりにフローを持ってい ますhttps://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow

OAuth2 / OpenID Connectの使用は、サービス間で必須ではありません。他のプロトコルや代替手段、さらにはカスタムもあります。すべては、どちらの関係がサービスであり、どちらも完全に信頼できる環境にあるかどうかによって異なります。

サービスアカウントのクレデンシャルやユーザーのクレデンシャルなどのサービス間で機密情報を共有しないようにすることを主な目的として、好きなものを使用できます。

RESTAPIセキュリティが主な要件である場合-OAuth2/ OpenID Connectがおそらく最良の選択であり、完全な信頼環境で最も簡単な方法で（認証の意味で）安全な呼び出しが必要な場合-Kerberos、それらの間に暗号化されたカスタムトンネルが必要な場合転送中のデータの暗号化-VPNなどの他のオプション。サービスAとサービスBがあり、それらの間の呼び出しが認証されていることを確認したい場合は、機密情報の結合と共有を避けるために、IDプロバイダーとして常に中央サービスCが必要になるため、カスタムを実装することは意味がありません。 。したがって、tis povから考えると、OAuth2/OIDCはやり過ぎではありません

于 2012-08-26T18:14:25.900 に答える
0

API のコンシューマーが Web ブラウザーであろうと、制御していないサーバーであろうと、セキュリティの状況は変わりません。

HTTPS を使用していて、クライアントがすでにキー/パスワードを持っている場合、他のメカニズムがどのような種類の攻撃から保護されるかは明確ではありません。

クライアント側で妥協すると、とにかくすべてが公開されます。

于 2012-08-26T17:58:08.383 に答える