デバイスにバインドされたセッション認証情報(DBSC)

デバイスにバインドされたセッション認証情報(DBSC)は、ハードウェアに裏打ちされたセッション セキュリティを追加することで認証を強化します。

はじめに

多くのウェブサイトは、ユーザー認証に長期間有効な Cookie を使用していますが、これはセッション ハイジャックの影響を受けやすくなります。デバイスにバインドされたセッション認証情報(DBSC)は、ハードウェア ベースのセキュリティ レイヤを追加してこのリスクを軽減し、セッションが特定のデバイスにバインドされるようにします。

このガイドは、ウェブ アプリケーションの認証フローを管理するデベロッパーを対象としています。DBSC の仕組みと、サイトに統合する方法について説明します。

DBSC の仕組み

大まかに言うと、DBSC はユーザーのデバイスに関連付けられた暗号鍵ペアを導入します。Chrome はログイン時にこの鍵ペアを生成し、利用可能な場合は、トラステッド プラットフォーム モジュール(TPM)などの安全なハードウェアに秘密鍵を保存します。セッションでは有効期間の短い Cookie が使用されます。これらの Cookie のいずれかが期限切れになると、Chrome は秘密鍵を保持していることを証明してから Cookie を更新します。このプロセスにより、セッションの継続性が元のデバイスにリンクされます。

ユーザーのデバイスが安全な鍵ストレージをサポートしていない場合、DBSC は認証フローを中断することなく、標準動作に正常にフォールバックします。

実装の概要

DBSC をアプリケーションに統合するには、次の変更を行う必要があります。

  • ログインフローを変更して、Sec-Session-Registration ヘッダーを含めます。
  • 次のようなセッション登録エンドポイントを追加します。
    • 公開鍵をユーザーのセッションに関連付けます。
    • セッション構成を提供します。
    • 有効期間の短い Cookie への移行。
  • Cookie の更新と鍵の所有権の検証を処理する更新エンドポイントを追加します。

既存のエンドポイントのほとんどは変更不要です。DBSC は、追加型で中断のない方法で設計されています。

必要な有効期間の短い Cookie が存在しない場合や期限切れの場合、Chrome はリクエストを一時停止して Cookie の更新を試みます。これにより、アプリは通常のセッション Cookie チェックを使用して、ユーザーがログインしていることを確認できます。これは一般的な認証フローと同じであるため、DBSC はログイン ロジックを最小限に変更して機能します。

実装の手順

このセクションでは、ログインフローの変更方法、セッション登録の処理方法、有効期間の短い Cookie の更新の管理方法など、認証システムに必要な変更について説明します。各ステップは、既存のインフラストラクチャとスムーズに統合するように設計されています。

実装手順は、DBSC が有効なときにログインしたユーザーが経験する一般的なフロー(ログイン時の登録、その後の短時間の Cookie の定期的な更新)に沿って行います。アプリのセッションの機密性レベルに応じて、各ステップを個別にテストして実装できます。

DBSC フローを示す図

1. ログインフローを変更する

ユーザーがログインしたら、長期間有効な Cookie と Sec-Session-Registration ヘッダーを返します。次に例を示します。

セッション登録に成功すると、次の HTTP レスポンス ヘッダーが返されます。

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

デバイスが安全な鍵ストレージをサポートしている場合、Chrome は JSON Web Token(JWT)の公開鍵を使用して /StartSession エンドポイントに接続します。

この例の auth_cookie はセッション トークンを表します。この Cookie の名前は、セッション構成の name フィールドと一致し、アプリケーション全体で一貫して使用される限り、任意の名前を付けることができます。

2. セッション登録エンドポイントを実装する

/StartSession で、サーバーは次の処理を行う必要があります。

  • 受信した公開鍵をユーザーのセッションに関連付けます。
  • セッション構成を返します。
  • 有効期間の長い Cookie を有効期間の短い Cookie に置き換えます。

次の例では、有効期間の短い Cookie が 10 分後に期限切れになるように設定されています。

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. 更新エンドポイントを実装する

有効期間の短い Cookie が期限切れになると、Chrome は更新フローを開始して秘密鍵の所有権を証明します。このプロセスでは、Chrome とサーバーの両方による調整されたアクションが含まれます。

  1. Chrome はユーザーのリクエストをアプリに延期し、/RefreshEndpoint に更新リクエストを送信します。

    POST /RefreshEndpoint HTTP/1.1
    Sec-Session-Id: session_id
    
  2. サーバーはチャレンジで応答します。

    HTTP/1.1 401 Unauthorized
    Sec-Session-Challenge: "challenge_value"
    
  3. Chrome は、保存されている秘密鍵を使用してチャレンジに署名し、リクエストを再試行します。

    POST /RefreshEndpoint HTTP/1.1
    Sec-Session-Id: session_id
    Sec-Session-Response: <JWT proof>
    
  4. サーバーは署名付き証明書を検証し、更新された有効期間の短い Cookie を発行します。

    HTTP/1.1 200 OK
    
    Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
    
  5. Chrome は更新された Cookie を受け取り、元の延期されたリクエストを再開します。

別の統合パターン

レジリエンスを強化するために、サイトは短時間の Cookie の横に DBSC 以外の 2 つ目の Cookie を追加できます。この長時間 Cookie は、新しい有効期間の短いトークンを発行する場合にのみ使用され、真正な未認証リクエストと一時的な DBSC 障害を区別するのに役立ちます。

  • 長期間保持される Cookie は、DBSC が失敗しても保持されます。
  • 短期間有効な Cookie は DBSC を使用して更新され、機密性の高いオペレーションに必要です。

このパターンにより、サイトはエッジケースの処理方法をより細かく制御できます。

注意点とフォールバック動作

次のシナリオでは、Chrome が DBSC オペレーションをスキップし、DBSC が管理する有効期間の短い Cookie なしでリクエストを送信することがあります。

  • ネットワーク エラーまたはサーバーの問題により、更新エンドポイントにアクセスできません。
  • TPM がビジー状態であるか、署名エラーが発生している。TPM はシステム プロセス間で共有されるため、過度の更新によりレート制限を超える可能性があります。
  • DBSC が管理する有効期間の短い Cookie がサードパーティ Cookie であり、ユーザーがブラウザの設定でサードパーティ Cookie をブロックしている。

このような場合、Chrome は長期間保持される Cookie がまだ存在する場合は、その Cookie を使用します。このフォールバックは、実装に長期間と短期間のコッキーの両方が含まれている場合にのみ機能します。そうでない場合、Chrome は Cookie なしでリクエストを送信します。

概要

デバイスにバインドされたセッション認証情報を使用すると、アプリケーションの変更を最小限に抑えながらセッションのセキュリティを強化できます。セッションを特定のデバイスに関連付けることで、セッション ハイジャックに対する保護を強化します。ほとんどのユーザーは中断することなくメリットを得ることができ、DBSC はサポートされていないハードウェアに正常にフォールバックします。

詳細については、DBSC の仕様をご覧ください。