セッションの絶対タイムアウトはどれくらいの長さですか？
OWASPセッション管理チートシート（ https://www.owasp.org/index.php/Session_Management_Cheat_Sheet ）は、（アイドルセッションタイムアウトに加えて）絶対セッションタイムアウトを実装することを推奨しています。これは、セッションアクティビティに関係なく、アプリケーションがユーザーに再認証を強制することを意味します。
そのタイムアウトの期間が十分に安全でエンドユーザーを煩わせないようにするための推奨事項はありますか？絶対セッションタイムアウトを24時間に設定するだけで十分でしょうか？もっと？
私が取り組んでいるアプリケーションは、社内ネットワーク内に配置され、ユーザーが日常の職務を実行するために使用されるため、frequest再認証リクエストは使いやすさの問題になる可能性があります。
時間の長さに厳密な答えはありません。アイドルタイムアウトの制限は、規制および場合によっては管轄法に依存します。
PCIでのカード会員データへのセッションベースのアクセスDSS 3.1は「合理的」である必要があります。PCIDSS 3.1の項目8.1.8は、これに関する特定のガイダンスを提供します
8.1.8セッションが15分以上アイドル状態であった場合は、端末またはセッションを再度アクティブにするために、ユーザーに再認証を要求します。
出典： https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf
他のコンプライアンスプログラムにも同様の提案があります。データ感度のコンテキストに応じて構成可能で柔軟にすることは、おそらく最善の策です。
絶対タイムアウトは、私が知っているどのフレームワークでも必須ではありませんが、興味深いようです。ユーザーエクスペリエンスへの影響は潜在的に重要ですが、セッションハイジャックの期間を制限することの利点も重要です。アプリケーションコードを制御する場合は、アプリケーションが定期的に新しいセッションIDを生成するセッションローテーション（つまり、OWASP用語の更新タイムアウト）の方が適切なソリューションのようです。
アプリケーションで許可されている場合は更新タイムアウトを追跡し、1時間以内の更新タイムアウトを使用することをお勧めします。これにより、ハイジャックのリスクが大幅に軽減され、単純な（小さい、手動でコピー可能な）セッション状態またはシリアル化可能なセッション状態を持つアプリケーションで実用的です。
絶対タイムアウトが唯一のオプションである場合、タイムアウトを24時間にします。それは賢明な制限であり、驚きを制限します。複数日の絶対タイムアウトは、ユーザーに再プロンプトを恣意的またはアプリケーション障害を示す可能性があると見なすため、ユーザーを混乱させる可能性があります。
PHPセッション（session.gc_maxlifetime）のデフォルト値は24時間ですが、24分が多すぎる可能性がありますが、この時間（session.gc_divisor ）。
ガベージコレクションの除数を1に設定する必要があります。除数は100％です。
https://stackoverflow.com/questions/156712/php-what-is-the-default-lifetime-of-a-session
使用するサーバーサイド言語でセッションとガベージコレクションがどのように機能するかを確認する必要があります。
ブラウザーが閉じられると、セッションも閉じられ、ガベージコレクションから削除される可能性があります。
チートシートには明確な推奨事項があります。
Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.
ただし、ガベージコレクションでセッションが確実に削除されない場合（除数）、セッションは24分後に自動的に終了しないことに注意してください。
コードでセッションをいつでも再開し、ユーザーがアクティブなときにセッションの寿命を延ばすことができます。ユーザーが特定の時間アクティブでない場合は、セッションを期限切れにして削除します。
ただし、1つのセッションはできるだけ短くする必要があり、期限切れになることを意図しています。