Webアプリケーション（http）：トークンベースの認証の安全性を把握しない
このようなものを見てください：
またはより具体的：
私の質問は今です：
真ん中の人はトークンを読み取るだけで、それを自分の要求で使用できます。つまり、トークンが実際に何を意味するのかを知る必要はなく、そのまま使用することができます。何が欠けていますか？セキュリティの観点から、これがセッションCookieを持つよりも優れていると思いませんか？
だから私が知る限り、実際にできる唯一のことは常にsslを使用することであり、それからトークン全体を削除してすべてのリクエストに基本認証を使用することができますか？
私が見るトークンの唯一の利点は、基本的な認証を使用する必要がなく、実際のログアウトやより優れたログインフォームなど（より複雑になることを犠牲にして）などのより詳細な制御を取得する必要がないことです。
何が欠けていますか？
トークンベースの認証は、第三者の攻撃者からの通信を保護するためのものではありません。 サーバーをクライアント自身に対して保護することです。
適切なセキュリティを確保するには、とにかくSSLが必要です。 SSLなしで、active攻撃者を想像してください。同じレストランであなたから2つのテーブルに座っているその変なひげを生やしたオタク-あなたはそれを知りませんが、彼のバックパックには 偽のWiFiアクセスポイント があり、彼は現在インターネットを傍受していますあなたがあなたがレストランの「無料WiFi」を通過すると信じるトラフィック。その男はいつでもあなたの通信を乗っ取ることができます。彼はあなたがWebサイトに送信するものとこれらのサイトから受信するものを確認し、両方の種類のデータを自由に変更できます。彼がくすくす笑い、ミルクシェイクでギャグを振るうとき、それは彼があなたのメールを読んでいるからです。
アクティブな攻撃者を打ち負かすには、データの機密性と整合性を保護し、 Bearded-Geek-in-the-Middle ではなく、適切なサーバーと通信する必要があります。そして、その「何か」は [〜＃〜] ssl [〜＃〜] です。
SSLを使用すると、実際に HTTP Basic Authentication を使用できます。これは機能します...ただし、HTTP基本認証を使用するwantが必要ですが、その認証はWebブラウザによって処理され、独自のポップアップが表示され、醜い場合があります。たとえば、次のようになります。
ほとんどのWebデザイナーは、このポップアップの実用性とミニマリズムに非常に失望しています。このポップアップは、スターリン時代の輝かしい建築実験を連想させます。したがって、ほとんど誰もそれをしません。代わりに、Webサイトは独自の「ログインページ」を純粋なHTMLで実装するため、ブラウザによる基本認証の固有のサポートから利益を得ることができません。彼らはクッキー、つまり私たちが話している「認証トークン」を使わなければなりません。
さらに、ユーザー認証は、必ずしもログインとパスワードに基づくものではありません。 OAuthプロトコル を使用して、認証を別のサーバーに委任するなど、一部のサイトはより面白い機能を実行します。このサイト、security.stackexchange.com、そうします。この場合も、クライアントブラウザでのデータの保存が必要です。このデータは、ログインとパスワードではないではありません。
クライアントブラウザにデータを保存し始めると、ユーザー自身にとっては不透明なままである必要があり（ユーザーがCookieを確認するのに十分な疑問がある場合）、ユーザーからの変更に抵抗するデータを保存することを想定できます（依存します）。データとその用途）。これには、それぞれencryptionおよびchecked integerが必要です。この種の「保護」とは、すべてをクライアントシステムに保存することですが、クライアントシステムを信頼しません。