車輪の再発明をせずにREST APIを保護する

質問

REST APIを設計する場合、最初にユーザー認証を行うのが一般的でしょうか？

私が探している典型的なユースケースは、以下の通りです。

• ユーザーはデータを取得したい。 もちろん、私たちは共有するのが好きです! 公開APIキーを取得し、読み出しましょう!
• ユーザーはデータを保存/更新したい...うわー待って！あなたは誰ですか？

一度構築して、Webアプリやアンドロイドアプリ、iPhoneアプリなどで利用できるようにしたいです。

REST APIは、次のような要件を満たす論理的な選択肢のように思われます。

私の質問を説明するために、簡単な例を使ってみましょう。

あるデータベースにあるアイテムに 評価 属性があります (1 から 5 の整数)。

私がRESTを正しく理解していれば、このようにcsv、xmlまたはjsonを返す好きな言語を使用してGETリクエストを実装します。

http://example.com/product/getrating/{id}/

返すJSONを選ぶとします。

{
  "id": "1",
  "name": "widget1",
  "attributes": { "rating": {"type":"int", "value":4} }
}

公開用のAPIはこれでいいんです。その部分はわかった。

大量の疑問があるのは、これをどのようにセキュリティモデルと組み合わせるかということです。私は、Webアプリケーションのセキュリティに慣れていて、常にユーザーを識別するセッションの状態を持っているので、ユーザーが何を送るか決定しても、彼らができることを制御できます。 私が理解しているように、これはRESTfulではないので、このケースでは悪い解決策になるでしょう。

同じ項目/評価を使用した別の例を使ってみます。

ユーザ "JOE"さんが、quot;JOE"さんに 評価 に 項目

を使って行うことができた。

http://example.com/product/addrating/{id}/{givenRating}/

このとき、quot;JOE"が製品{id}に{givenRating}の評価を与えたというデータを保存したいのです。

質問です。要求が "BOB"ではなく、"JOE"から来たことをどのように確認すればよいですか。

さらに、それがユーザーの電話番号のような、より賢明なデータであった場合はどうでしょうか？

今までのところ、私が得たものは

1) HTTP の組み込み機能を使用して、プレーン HTTP または HTTPS のいずれかのリクエストごとに認証を行います。

これは、すべてのリクエストが現在、次のような形式をとっていることを意味します。

https://joe:[email protected]/product/addrating/{id}/{givenRating}/

2) 秘密鍵と公開鍵でAmazonのS3のようなアプローチを使う。 http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

3) とにかくクッキーを使って、RESTのステートレスな部分を壊してください。

2番目のアプローチは私にとってはより良いように見えますが、私は本当にこの全体を再発明する必要があるのだろうかと疑問に思っています。ハッシュ化、保存、キーの生成など、すべて自分自身で行う必要があるのでしょうか?

これは、典型的な Web アプリケーションでセッションを使用し、スタック全体を自分で書き直すようなもので、通常、特にセキュリティを扱う場合は、「あなたは間違っている」という意味になります。

編集：OAuthについても言及するべきだったようです。

どのように解決するのですか？

5年後の編集

OAuth2を使ってください!

旧バージョン

いいえ、クッキーを使用する必要は全くありません。HTTP DigestやOAuth、AmazonのAWS（コピーするのは難しくない）の半分も安全ではありません。

クッキーの見方は、ベーシック/ダイジェスト/OAuth/どれと同じように認証トークンであるが、より適切ではないということです。

しかし、私はクッキーを使うことがRESTfulの原則に反するとは思っていません。 それ自体 セッション Cookie のコンテンツが、サーバーから返すリソースのコンテンツに影響を与えない限りは。

クッキーは悪だ、使うのを止めろ。