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

Device Bound Session Credentials（DBSC）は、ハードウェアで保護されたセッション セキュリティを追加することで認証を強化します。

Daniel Rubery
Daniel Rubery
José Luis Zapata

はじめに

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

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

DBSC の仕組み

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

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

実装の概要

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

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

既存のエンドポイントのほとんどは変更を必要としません。DBSC は、追加可能で中断を伴わないように設計されています。

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

実装の手順

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

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

DBSC フローを示す図

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

ユーザーがログインしたら、有効期間の長い Cookie と Secure-Session-Registration ヘッダーで応答します。次に例を示します。

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

HTTP/1.1 200 OK
Secure-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-Secure-Session-Id: session_id

  2. サーバーはチャレンジで応答します。

    HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "challenge_value"

  3. Chrome は、保存された秘密鍵を使用してチャレンジに署名し、リクエストを再試行します。

    POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id
Secure-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 とともに、2 つ目の DBSC 以外の Cookie を追加できます。この有効期間の長い Cookie は、有効期間の短い新しいトークンを発行するためにのみ使用され、認証されていないリクエストと一時的な DBSC エラーを区別するのに役立ちます。

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

このパターンを使用すると、サイトでエッジケースの処理方法をより詳細に制御できます。

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

Chrome は、次のシナリオでは DBSC オペレーションをスキップし、DBSC 管理の短命 Cookie を使用せずにリクエストを送信する場合があります。

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

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

概要

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

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