モバイル アプリに公開する Web サービスを作成しています。現在、トークンベースの認証ソリューションを実装しています（過去に行ったことがあるため）。ただし、このコンテキストでは、毎回ユーザー名とパスワードを単純に渡さない理由を理解するのに苦労していますか? モバイル アプリの実行中にパスワードを RAM に保持し (過度に複雑にしたい場合は、暗号化して使用します)、サーバーに接続するたびにパスワードを渡し、毎回ハッシュ検証を繰り返します。もちろん、すべてが SSL であるため、ネットワーク転送に関しては、毎回行うのと比べてリスクはありませんか? 私が見る唯一のCONは、ハッシュ検証プロセスがトークン検証よりも高価になる可能性があるということです. ここで見逃している他の短所はありますか？
1013 次
1 に答える
2
これを行わない理由はいくつかあります。
- 情報を送信するたびに、傍受のリスクが生じます。(そのリスクは、SSL などの暗号化システムを使用することでほとんど軽減されますが)。
- すべてのリクエストでユーザー名とパスワードの組み合わせを渡すことは、リクエストごとにサーバー側でそれらの組み合わせをチェックすることを意味します。通常、これには追加のデータベース ヒットと、不要なロジックが必要です。
- すべてのリクエストでこのような認証を渡す場合、すべてのリクエストで SSL を使用する必要があり、これはオーバーヘッドが高くなります。暗号化された認証トークンをプレーンテキスト (サーバー側のみが読み取ることができる) で送受信する方がはるかに安価です。
RESTful認証などに関するいくつかの質問に答えたので、これはここ数日SOで少し話題になっているようです。以下に、これらの回答へのリンクをいくつか提供しています。これは、より詳細な情報です。おそらく、私が提案している認証スキームを見てみると、リクエストごとにユーザー名/パスワードを送信するだけでなく、それがどのように保護されているかがわかります。
于 2012-11-02T16:51:40.437 に答える