トークンベースの認証についての私の理解は、認証時に（おそらくssl経由で）、その場で安価なユーザー検証のためにトークンがユーザーに渡されるということです。これの 1 つの実装は、セッション管理のためにユーザーに渡される Cookie を生成することです。
しかし、私の理解では、トークン ベースの認証 (少なくとも Cookie による) は、firesheep のような中間者攻撃の影響を受けやすいということです。
この主要なセキュリティ問題を回避する実装の他の方法はありますか、それとも私は tba について根本的な誤解を持っていますか?
あなたの理解は良いです。基本的に、アプリケーションがそれをどのように認識するかという観点から、トークンはユーザー名とパスワードである場合もあります。誰かがトークンを持っている場合、その人はあなたのアプリケーションに対して自分自身を認証することができます。http cookieの場合の主な目的は、クロスサイトスクリプティングの脆弱性（XSS）などによって誰かがcookieを取得した場合に、ユーザー名とパスワードが漏洩しないようにすることです。はい、適切な状況を考えると、このトークンを「中間者」としてアプリケーションに「再生」することはできますが、ユーザー名とパスワードのペアをそこから把握することはできませんが、トークンの場合、これは保証されません。たとえば、BASE64で連結されたユーザー名とパスワードをエンコードし、それを値として使用する場合のように、生成アルゴリズムは脆弱です。
通常、サーバー側でトークン->ユーザーマッピングを安全に保ちます。したがって、最終的には、セキュリティはすべて、トークンを安全に保ち、その存続期間が制御されるようにすることに基づいています（たとえば、トークンの有効期限が切れたり、資格情報の元のプロバイダーが使用したのと同じIPから与えられた場合にのみ有効になります）。単なる例）
お役に立てれば、
-オシーン