3

モバイル アプリに公開する Web サービスを作成しています。現在、トークンベースの認証ソリューションを実装しています（過去に行ったことがあるため）。ただし、このコンテキストでは、毎回ユーザー名とパスワードを単純に渡さない理由を理解するのに苦労していますか? モバイル アプリの実行中にパスワードを RAM に保持し (過度に複雑にしたい場合は、暗号化して使用します)、サーバーに接続するたびにパスワードを渡し、毎回ハッシュ検証を繰り返します。もちろん、すべてが SSL であるため、ネットワーク転送に関しては、毎回行うのと比べてリスクはありませんか? 私が見る唯一のCONは、ハッシュ検証プロセスがトークン検証よりも高価になる可能性があるということです. ここで見逃している他の短所はありますか？

4

1 に答える 1

2

これを行わない理由はいくつかあります。

  1. 情報を送信するたびに、傍受のリスクが生じます。(そのリスクは、SSL などの暗号化システムを使用することでほとんど軽減されますが)。
  2. すべてのリクエストでユーザー名とパスワードの組み合わせを渡すことは、リクエストごとにサーバー側でそれらの組み合わせをチェックすることを意味します。通常、これには追加のデータベース ヒットと、不要なロジックが必要です。
  3. すべてのリクエストでこのような認証を渡す場合、すべてのリクエストで SSL を使用する必要があり、これはオーバーヘッドが高くなります。暗号化された認証トークンをプレーンテキスト (サーバー側のみが読み取ることができる) で送受信する方がはるかに安価です。

RESTful認証などに関するいくつかの質問に答えたので、これはここ数日SOで少し話題になっているようです。以下に、これらの回答へのリンクをいくつか提供しています。これは、より詳細な情報です。おそらく、私が提案している認証スキームを見てみると、リクエストごとにユーザー名/パスワードを送信するだけでなく、それがどのように保護されているかがわかります。

RESTful Web サービスでの認証

REST の公開認証メカニズム

于 2012-11-02T16:51:40.437 に答える