2

RESTful Web サービスの実装と RESTful API の作成について読み始めたところです。REST の基本的な概念は理解しましたが、安全に実装する方法について頭を悩ませています。

たとえば、私の webapp にユーザー ログイン プロセスがあるとします。ログインに成功したら、サーバーで認証するために RESTful リクエストで他に何を渡す必要がありますか? 私が考えることができるのは、次のプロセスです。

  • ユーザーのログイン (POST ユーザー名/パスワードを API に)
  • API はユーザーキーで応答します
  • ユーザーキーはローカルに保存されます
  • さらにリクエストを行うときは、このキーを認証リクエストに含めます

しかし、ここではuserkeyAPIに送信している状態のようですが、RESTはたまたまステートレスです。GETまた、リクエストを送信する場合、これはあまり安全ではありません。

OAUTH は私のジレンマの解決策ですか? それとも他の方法ですか?誰かがこれについて私を案内できますか...

ありがとう

4

2 に答える 2

3

UserKey、またはそれをtokenと呼んだほうがよいのは、クライアント側の状態です。このトークンはどこにも保存されないため、RESTful API はステートレスのままになります。

通常、このトークンは、MD5、SHA (またはその他のアルゴリズム) としてハッシュ化されたいくつかのセグメント (ユーザー名、パスワード、ログイン日) の組み合わせです。クライアントが RESTful API の操作を呼び出すたびに、サービスは着信トークンを、同じセグメントを使用してオンザフライで生成されたトークンと比較します。生成された両方のトークンが等しい場合、リクエストは認証されます。

GET または POST メソッドに問題はありません。クエリ文字列または HTTP ヘッダーからトークンを取得する必要があります。

接続を保護するポイントは、SSL を介して RESTful API を呼び出すことです。これにより、通信のセキュリティが高度になります。

GET とクエリ文字列を使用してこのトークンを送信する際の重要な問題は、おそらく長すぎることと、URL の長さの制限により、トークン自体に加えて多くの引数を使用できないことです。

私の意見では、POST動詞を使用する必要があります。より多くのデータを送信でき、より柔軟であり、ユーザー名をログに記録するため、ログの観点から悪い可能性があるクエリ文字列で問題のある引数を指定することを回避できるためです。パスワード、トークン、その他のもの。これらは、ハッカーがログを盗んだ場合 (または不要な人がログをチェックした場合)、ユーザーを危険にさらす可能性がある機密情報です。

于 2012-01-30T09:29:58.403 に答える
2

OAuth はステートレスです。これは、誰かがクライアントに何かを行うことを許可したことを証明するトークンです。たとえば、運転免許証のように、市民が路上で車を運転することを政府が許可した場合などです。

だから - はい - OAuth を使用してください。

于 2012-01-30T09:27:50.400 に答える