ネイティブ アプリは、一度ログインするだけで、ログアウトするよう指示されるまでユーザーの使用を記憶します。これは非常に便利です。残念なことにウェブは 必ずしもそうとは言えません
デバイス、特にモバイル デバイスのパーソナライズ性が高まり、すべてのトラフィックを 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 をサポートしていないブラウザをユーザーが訪問した場合はどうなるのか疑問に思われるかもしれません。上記のアプローチを実装しても、違いは見られず、引き続き短いセッションが発生します。
サンプル クライアントとバックエンドが公開されています。ぜひお試しいただき、セッション管理に関するアンケートにご回答ください。