REST APIを設計するとき、最初にユーザーを認証するのは一般的ですか?
私が探している典型的なユースケースは次のとおりです。
私は一度それを構築し、Webアプリ、AndroidアプリケーションまたはiPhoneアプリケーションがそれを使用することを許可することを許可したいと思います。
REST APIは、このような要件を持つ論理的な選択のようです
私の質問を説明するために、簡単な例を使用します。
データベースにアイテムがあり、rating属性(整数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」がratingをitemに追加する場合
これは次を使用して実行できます。
http://example.com/product/addrating/{id}/{givenRating}/
この時点で、「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)とにかくCookieを使用し、RESTのステートレス部分を破壊します。
2番目のアプローチは私には良いように見えますが、本当にこの全体を再発明する必要があるのか疑問に思っています。ハッシュ、保存、キーの生成などをすべて自分で行いますか?
これは、典型的なWebアプリケーションでセッションを使用し、スタック全体を自分で書き直すのとよく似ています。通常、特にセキュリティを扱う場合は「間違っている」という意味です。
編集:私はOAuthも同様に言及すべきだったと思います。
5年後に編集
OAuth2を使用してください!
以前のバージョン
いいえ、Cookieを使用する必要はまったくありません。 HTTP Digest、OAuthまたはAmazonのAWS(コピーするのは難しくありません)ほど安全ではありません。
Cookieを確認する方法は、Basic/Digest/OAuth /のいずれかと同じくらいの認証トークンですが、あまり適切ではないということです。
ただし、Cookieの使用がRESTful原則自体に反するとは感じません。ただし、セッションCookieの内容がサーバーから返すリソース。
クッキーは悪です。使用をやめてください。
「RESTful」であること、セキュリティを心配する必要はありません。以下にその方法を示します。
手順1:ユーザーが資格情報を使用して認証サービスにアクセスします。
ステップ2:資格情報をチェックアウトし、フィンガープリント、セッションIDなどを返し、後ですばやく取得できるように共有メモリにポップするか、Webサービスの所要時間に数ミリ秒を追加することを気にしない場合はデータベースを使用します。
ステップ3:エントリポイントコールを、everyWebサービスリクエストのフィンガープリントとセッションIDを検証するすべてのWebサービススクリプトの先頭に追加します。
ステップ4:指紋とセッションIDが有効でない場合、または認証へのリダイレクトがタイムアウトした場合。
これを読む:
3年後編集
私はEvertに完全に同意し、HTTPSで OAuth2 を使用し、車輪を再発明しないでください! :-)
単純なREST APIによって-サードパーティクライアント向けではありません- JSON Web Tokens も同様に有効です。
以前のバージョン
とにかくCookieを使用して、RESTのステートレス部分を破壊します。
セッションを使用しないでください。RESTサービスは十分にスケーラブルではありません...ここには、アプリケーション状態(またはクライアント状態またはセッション)とリソース状態の2つの状態があります。アプリケーションの状態にはセッションデータが含まれ、RESTクライアントによって維持されます。リソース状態にはリソースのプロパティと関係が含まれ、RESTサービスによって維持されます。特定の変数がアプリケーション状態またはリソース状態の一部であるかどうかを非常に簡単に決定できます。アクティブなセッションの数とともにデータ量が増加する場合、そのデータはアプリケーション状態に属します。したがって、たとえば、現在のセッションによるユーザーIDはアプリケーション状態に属しますが、ユーザーのリストまたはユーザー権限はリソース状態に属します。
したがって、RESTクライアントは識別要素を保存し、要求ごとに送信する必要があります。 RESTクライアントとHTTPクライアントを混同しないでください。それらは同じではありません。 RESTクライアントは、curlを使用する場合はサーバー側にも存在できます。たとえば、CORSを介してRESTサービスと共有できるサーバー側httpのみのCookieを作成できます。重要なのは、RESTサービスがすべてのリクエストで認証する必要があるため、すべてのリクエストで資格情報(ユーザー名、パスワード)を送信する必要があることです。
credentials -> (identity, permissions)
キャッシュを作成して、認証を高速化できます。キャッシュをクリアし、ユーザーが同じリクエストを送信すると、同じレスポンスが返されることに注意してください。少し時間がかかります。これをセッションと比較できます。セッションストアをクリアすると、ユーザーはstatus: 401 unauthorized
応答を受け取ります...クッキーは必ずしも悪いわけではありません。クライアント状態を保持し、サービスがリソース状態のみを保持するまで、RESTfulな方法で使用できます。たとえば、カートまたは優先ページ付け設定をCookieに保存できます...