拡張基本認証
ユーザー名とパスワードに依存する基本認証を使用してREST APIを実装したいと思います。RESTはステートレスであるため、ユーザーはユーザー名とパスワードを再入力する必要があります。ユーザー名とパスワードをCookieに保存することはオプションではないため、別のソリューションが必要です。
私が考えているシナリオは次のとおりです。
- ユーザーは次の場所に移動します https://www.myapi.com/login
- ユーザーはユーザー名とパスワードを入力します（SSLで暗号化されています）。
- システムは、提供された資格情報が正しいかどうかをチェックします。
- 正しければ：システムはGUIDを生成し、GUIDをユーザーのパスワードで暗号化して、ユーザーに送信します。
- 正しくない場合：FailedPasswordAttemptCounterを増やし、ユーザーのログインをロックする必要があるかどうかを確認します。
クライアントへのサーバーの応答は暗号化されていないため、GUIDはユーザーのパスワードで暗号化されます。GUIDを復号化できるのはユーザーのみです。
ユーザーは、ユーザー名とパスワードの代わりに認証を必要とする他のすべてのリソースにGUIDを提供します。
このアプローチは、各リクエストにユーザー名とパスワードを提供するよりも優れていますか？
誰かがGUIDを生成し、それを使用して認証を試みることができるという事実を認識しています。ただし、ログインリソースがロックメカニズムを提供するため、特定のユーザーを標的とした攻撃はほぼ不可能です。
私の質問はどういうわけかこれに関連しています： https://stackoverflow.com/questions/290405/is-using-a-guid-security-though-obscurity
RESTはステートレスであるため、ユーザーはリクエストごとにユーザー名とパスワードを再入力する必要があります
と直接矛盾している
ユーザーは、ユーザー名とパスワードの代わりに認証を必要とする他のすべてのリソースにGUIDを提供します。
次のいずれかを実行できます。
A.リクエストごとにパスワードを送信するか、
B。リクエストごとにパスワードを送信しないでください。
ただし、1つを選択する必要があります。
これが理想的なシナリオです。それはあなたが説明しているものに近いです：
- ユーザーがログインします。ユーザー名、パスワード、認証トークンなど。
- サーバーはその認証イベントをサーバー側に保存し、クライアントに提供するランダムトークン（GUIDまたは必要なもの）を作成します
- クライアントがリクエストを送信する場合、クライアントは自分を識別するトークンもサーバーに送信します。これは、Cookie、URL、フォーム変数、別のヘッダーに含まれている可能性があります。関係ありません。リクエストのどこでも問題ありません。
- サーバーexpires使用されなくなった後のトークン。おそらく5分間は問題ありませんが、1回の操作に使用されるまでは問題ありません。おそらくそれが行くまでそれは良いです未使用 5分間。あなたが望むものなら、なんでも。