ネイティブ アプリが一度ログインすれば、ログアウトするよう指示するまでその内容が記憶されることは誰にでもあるでしょう。残念ながら、ウェブは必ずしもそうとは限りません。
デバイス（特にモバイル デバイス）はカスタマイズ性が高く、より多くのサイトが HTTPS 経由ですべてのトラフィックを送信するようになり、トークンが盗まれるリスクが減っているため、ウェブサイトは有効期間の短い Cookie ポリシーを再検討し、よりユーザー フレンドリーで長期のセッションを採用する必要があります。
ただし、セッションを長くしたい場合でも、ウェブサイトによっては、リクエストごとにユーザーの認証を確認しないことがあります（つまり、一度発行したセッション Cookie を取り消す方法はありません）。その結果、セッションが短くなり、ユーザーは頻繁にログインしなければならなくなるため、認証を再検証できます。これにより、パスワードの変更などにより、既知の時間内に既存のセッションが無効になります。
この方法を使用する場合は、ステートレス認証 Cookie を自動的に再検証できる技術的ソリューションがあります。これは、既存の有効期間が短い認証 Cookie の更新に使用できる、有効期間が長いセカンダリ トークンを持つことで機能します。新しい Service Worker パターンを利用すると、有効期間の長いトークンで定期的に「チェックイン」を行い、ユーザーの認証を検証（たとえば、最近パスワードを変更していないか、セッションを取り消していないかなど）を確認し、新しい有効期間の短い認証 Cookie を再発行できます。
ウェブ上で安全な長時間のセッションに移行するための実践的な提案
この投稿では、2-Cookie-Handoff（2CH）という新たな手法について説明します。この記事を使用して、このアプローチが好ましいかどうかについてコミュニティからのフィードバックを聞きたいと考えています。また、肯定的な場合は、業界と連携して 2CH の使用に関するベスト プラクティスを文書化したいと考えています。
Service Worker は、Chrome、Firefox、Opera などの複数のブラウザでサポートされている新しいテクノロジーで、まもなく Edge に搭載される予定です。既存のページに変更を加えることなく、クライアント上の共通のコードポイントを介してサイトからのすべてのネットワーク リクエストをインターセプトできます。これにより、ログイン ユーザー用に「2CH ワーカー」をセットアップできます。モバイルアプリの場合と同様に、ページで行われているすべてのネットワーク リクエストをインターセプトして、トークンのスワップを実行できます。
ほとんどの場合、モバイルアプリが有効期間の短いトークンを取得するために使用するエンドポイントがサーバーにすでに存在しています（通常は OAuth プロトコルを使用します）。上記のパターンをウェブ上で有効にするには、そのエンドポイントを更新して Service Worker から呼び出されたタイミングを把握し、サイトの他のページがすでに想定している形式で新しい有効期間の短いセッション Cookie を返す必要があります。
このようなエンドポイントがサーバーにまだない場合は、ブラウザ セッション管理のためだけにエンドポイントを作成できます。
Service Worker での 2 つのトークンのパターンは、OAuth 2.0 のパターンにほぼ従っています。すでに OAuth トークン エンドポイントを実行している場合は、ウェブ認証のために Service Worker で再利用できる可能性があります。
また、Service Worker をサポートしていないブラウザにユーザーがアクセスするとどうなるのか、疑問に思われるかもしれません。上記のアプローチを実装しても違いはなく、引き続き短いセッションが発生します。
サンプル クライアントとバックエンドを公開しています。 ぜひ実際にお試しのうえ、セッション管理に関するアンケートにご回答ください。