これが一部の人にとって常識かもしれない場合は申し訳ありませんが、私はまだ学んでいます。ファイルを Web サーバーに同期する iOS アプリがあります。ユーザーがデバイスにログインすると、サインアウトしない限りログインしたままになります。現在、ユーザーがファイルの追加、更新、削除などのサーバー要求を開始するたびに、ユーザーは既にデバイスで認証されているため、パスワードではなくユーザーの電子メールのみをサーバーに送信します。
ユーザーがリクエストを行うたびに保存されたパスワードを送信し、リクエストを続行する前にサーバーに認証させる必要がありますか? なぜですか、そうでないのですか？
電子メール アドレスではなく、セッション ID を送信する必要があります。
セッション ID は、ユーザーが正常に認証されたときに暗号乱数ジェネレーターによって選択される大きな数値 (128 ビットで十分) です。これは、ユーザーの Web デバイスで「Cookie」として設定され、セキュア チャネル (TLS) を介して各要求と共に送信されます。
メールアドレスは公開されています。パスワードやセッション ID などのシークレットを使用してのみ、リクエストを認証できます。
私は専門家ではありませんが、より良い答えが得られるまで、いくつかのヒントを以下に示します。
HTTPS を使用している場合は、これについてあまり心配する必要はないかもしれません。暗号化されていないトラフィックの場合は、追加のハッシュ値を使用して各メッセージに「署名」することができます。
Using an email address to identify a user means someone can possibly forge access to your service by using an existing users email address. As Kristopher Johnson suggests, using a session identifier avoids exposing credentials and is probably a good design choice.
The good people at OWASP have a session management cheat sheet which is an excellent starting point for any design.
They do recommend using an existing framework for session management (Java EE, ASP.NET, PHP) if one is available.
SSL を使用する場合は、リクエストごとにユーザー名とパスワードを送信するのが最適です。なんで？それは、より単純なプログラミング インターフェイスであり、トークンが実際の価値を追加しないためです。ある時点でトークンを取得するには、資格情報を送信する必要があります。時間に見合った方法で SSL を解読できる人はいません。現在、Web サーバー自体のような他のセキュリティの抜け穴がある可能性がありますが、それはクライアントからサーバーへのトランスポート (保護されている) とは関係ありません。したがって、すべてのリクエストで User/pass が最適です。
また、iOS アプリであるため、資格情報を NSUserDefaults に保存できます (これは特定のアプリにサンドボックス化されており、他のアプリはアクセスできません)。
投票して受け入れてください。他の回答は誤解を招くものです
iOS アプリではなく、資格情報を NSUserDefaults ではなく Cookie に保存する必要がある場合は、セッションを使用する引数を作成できます。しかし、それ以外のセッションは頭痛の種ではありません!