ステートレス（セッションなし）およびCookieなしの認証を行う方法は？

ボブは何かを達成するためにWebアプリケーションを使用します。そして：

• 彼のブラウザはダイエット中であるため、クッキーをサポートしていません。
• Webアプリケーションは人気があり、特定の瞬間に多くのユーザーに対応します。適切にスケーリングする必要があります。セッションを維持することが同時接続数に制限を課し、そしてもちろん無視できないパフォーマンスのペナルティをもたらす限り、私たちはセッションのないシステムを持ちたいかもしれません:)

重要な注意事項：

• 我々は持っているトランスポート・セキュリティ（HTTPSとその親友が）。
• カーテンの裏側では、Webアプリケーションは現在のユーザーに代わって多くの操作を外部サービスに委任します（これらのシステムはBobをユーザーの1人として認識します）。つまり、Bobの資格情報を転送する必要があります。

では、どのようにしてボブを認証するのですか（すべてのリクエストで）。そのようなことを実装する合理的な方法はどれでしょうか？

• HTMLフォームの非表示フィールドを介して資格情報でテニスをする... ボールには資格情報（ユーザー名とパスワード）が含まれ、2つのラケットはそれぞれブラウザーとWebアプリケーションです。つまり、Cookieではなくフォームフィールドを介してデータをやり取りする場合があります。各Web要求で、ブラウザーは資格情報を投稿します。ただし、1ページのアプリケーションの場合、これはテニスではなく、ゴムの壁でスカッシュをするように見えます。これは、資格情報を含むWebフォームがWebページの存続期間全体にわたって維持される可能性があるためです。 （サーバーは、資格情報を返さないように構成されます）。
• ユーザー名とパスワードをページのコンテキストに保存する-JavaScript変数など。ここでは単一ページが必要、IMHO。
• 暗号化トークン-ベースの認証。この場合、ログインアクションにより、暗号化されたセキュリティトークン（ユーザー名+パスワード+その他）が生成されます。このトークンはクライアントに返され、今後のリクエストにはトークンが付随します。これは理にかなっていますか？すでにHTTPSを使用しています...
• その他...
• 最後の手段：これを行わないで、資格情報をセッションに保存してください！セッションはいいです。クッキーの有無にかかわらず。

以前に説明されたアイデアのいずれかに関して、Web /セキュリティの懸念が思い浮かびますか？例えば、

• タイムアウト - 資格情報とともにタイムスタンプを保持する場合があります（タイムスタンプ=ボブが資格情報を入力した時間）。たとえば、NOW-timestamp> thresholdの場合、リクエストを拒否する可能性があります。
• クロスサイトスクリプティング保護-どのような違いもないはずですよね？

これを読んでくれてありがとう:)

ああ、私はこれらの質問が大好きです-セッションなしでセッションを維持します。

私は、アプリケーションの評価中に私のスティント中にこれを行う複数の方法を見てきました。人気のある方法の1つは、あなたが言及したテニスをする方法です-ユーザーを認証するすべてのリクエストでユーザー名とパスワードを送信します。私の意見では、これは特にアプリケーションが単一ページでない場合は安全ではありません。特に将来的に認証に加えてアプリに承認を追加する場合は特に、スケーラブルではありません（ただし、ログインに基づいて何かを構築することもできると思います）

完全にステートレスではありませんが、人気のあるメカニズムの1つは（JavaScriptを実行している場合）、セッションCookieをJavaScriptに埋め込むことです。私のセキュリティ担当者はこれを叫んでいますが、実際には機能する可能性があります-すべてのリクエストにはX-Authentication-Tokenヘッダーまたはそのようなもの、そしてそれをユーザーに検証するためにバックエンドのデータベース、メモリ内のファイルストアなどにマップします。このトークンには、指定した時間のタイムアウトを設定できます。タイムアウトになると、ユーザーは再度ログインする必要があります。これはかなりスケーラブルです。データベースに保存して1つのSQLステートメントを実行し、正しいインデックスを使用すれば、複数の同時ユーザーがいても、実行にほとんど時間がかかりません。ここでの負荷テストは間違いなく役立ちます。質問を正しく読んだ場合、これは暗号化されたトークンメカニズムになります。ただし、ユーザー名+パスワード+その他の組み合わせを使用するのではなく、32文字の暗号化ランダムトークンを使用することを強くお勧めします-このようにして、予測不可能ですが、それをユーザーIDまたはそのようなものと関連付けることができます。

どちらを使用しても、安全に送信されていることを確認してください。HTTPSは通信を介してユーザーを保護しますが、URLを介してセッショントークン（または、さらに悪いことに、URLを介して資格情報）を漏らしても保護しません。ヘッダーを使用することをお勧めします。それが不可能な場合は、毎回POSTリクエストを介してトークンを送信します（これは、ユーザーのブラウザーの非表示フォームフィールドを意味します）。POSTリクエストを使用する後者のアプローチでは、CSRF防御を使用する必要があります。万が一、トークン自体を使用することは、なんらかのCSRF防御策になるのではないかと思います。

最後になりますが、有効期限が切れたトークンをパージするメカニズムがバックエンドにあることを確認してください。これは過去の多くのアプリケーションの悩みの種でした-認証トークンのデータベースが急速に成長し、消えることはないようです。複数のユーザーログインをサポートする必要がある場合は、数を制限するか、各トークンの時間制限を短くしてください。前に述べたように、負荷テストはこれに対する答えかもしれません。

私が考えることができる他のいくつかのセキュリティの懸念がありますが、それらはこの段階で対処するには広すぎるため、すべての使用（および乱用）ケースを念頭に置いている場合は、おそらくかなり良い実装を行うことができるはずですこのシステム。

ログインオプションについて-通常はゲスト向けのセッションもサポートしたいと思います。

したがって、ログインを強制する場合は、暗号化トークンオプションが適している可能性があります。ゲストセッションにも何とかいいかもしれません。別の方向では、URLへのトークンの追加とテニスオプションを組み合わせます。

URLでのみ資格情報を送信することは危険な場合があることに注意してください。たとえば、HTTPリファラーヘッダーを介して、またはトラフィックを検査したりコンピューターを監視したりする誰かによってトークンが漏洩する可能性があります。

もう1つ、Cookieを使用できる場合でも、ランダムなトークンまたはランダムな検証を追加して、クロスサイトリクエストフォージェリ（CSRF）攻撃から身を守ることをお勧めします。