私はこの質問を何度も聞いたことがありますが、私の答えは通常「なぜあなたはこれを望んでいますか？」です。 1つは他のものを必要とせず、それらの有効期限は異なる基準を用いて決定されるべきである。
セッション状態では、ユーザーがログインする必要はありません。アプリはセッション状態を使用するために認証を使用する必要もありません。ユーザーが既にログインしていてもセッション状態を使用していて、ログアウト後もセッション状態を使用しているWebアプリケーションを作成することができます。ここでの「セッション」とは、クライアント（ウェブブラウザ）がサイトに接続し、数ページを飛び越えて去ったときである。ユーザーがログインしているかどうかは関係ありません。ブラウザを閉じて新しいブラウザを開いてサイトに戻ると、新しいセッションが作成されます。しかし、サーバーは古いブラウザウィンドウを閉じたことを知らないので、元のセッションはまだ存在します。スケーラビリティ（主にメモリ）を目的として、セッションを終了し、メモリとセッショントラッキングリソースを解放します。クライアントが新しいリクエストを作成するのに時間がかかりすぎると、新しいリクエストによって新しいセッションが作成されます。
一方、認証を使用してセッション状態をまったく使用することはできません。私は通常、セッション状態とビューステートの両方を無効にしてアプリケーションを起動し、本当に必要な場合にのみ有効にし、ページ単位（またはviewstateのコントロールごとに）で有効にします。
セッションの有効期限は、各セッションで使用されるメモリ、Webサーバーで使用可能なメモリ、同時ユーザー数、およびその他のスケーラビリティのニーズによって決まります。それは通常、数分から1時間の範囲内である。
認証はクライアント上でクッキーとして維持され、基本的にサーバーのリソースを消費しません。スケーラビリティに基づいたログインの有効期限は、通常、セッションの有効期限よりも長くなる可能性があります。実際には、ユーザーは無期限にログインしておくことができます。認証の有効期限を短く保つと、通常はセキュリティ上の理由からです。自分のコンピュータから離れて15分移動した場合、あなたの銀行のWebサイトアカウントを誰かが利用できるようにしたくないでしょうか？あなたはGmailやFacebookにログインして「私を覚えている」を選択し、数日後に返信すると、がまだになります。もちろん、いくつかのセッション情報を保持するWebアプリケーションがないため、これは新しいセッションになります日々。
今、多くの人が同じ長さの認証とセッションの有効期限を使用していることがわかりました。また、多くの場合、ユーザーがログアウトしたときのセッションを放棄（）またはクリア（）します。しかし、彼らはまだは、ユーザーがまだログインしているが、セッションが期限切れの場合（次の要求で新しい空のセッションを作成する）、またはユーザーの認証が期限切れでセッション（再度ログインする必要がありますが、期限切れではない古いセッションを別のユーザーの機密データで持ち歩かなければならない）。どのようなタイムアウトを最終的にアプリケーションに適用しても、これらのケースを処理することは非常に重要です。