Учетные данные сеанса, привязанного к устройству (DBSC)

Учетные данные сеанса, привязанного к устройству (DBSC), усиливают аутентификацию за счет обеспечения аппаратной безопасности сеанса.

Daniel Rubery

José Luis Zapata

Введение

Многие веб-сайты используют долгоживущие файлы cookie для аутентификации пользователей, но они подвержены перехвату сеанса. Учетные данные сеанса с привязкой к устройству (DBSC) добавляют уровень аппаратной безопасности для снижения этого риска, гарантируя привязку сеансов к конкретным устройствам.

Это руководство предназначено для разработчиков, которые поддерживают потоки аутентификации в веб-приложениях. В нем объясняется, как работает DBSC и как интегрировать его в ваш сайт.

Как работает ДБСК

На высоком уровне DBSC представляет пару криптографических ключей, связанную с устройством пользователя. Chrome генерирует эту пару ключей во время входа в систему и сохраняет закрытый ключ на защищенном оборудовании, например в доверенном платформенном модуле (TPM) , если он доступен. В сеансах используются кратковременные файлы cookie. Когда срок действия одного из этих файлов cookie истекает, Chrome доказывает владение закрытым ключом, прежде чем обновлять его. Этот процесс связывает непрерывность сеанса с исходным устройством.

Если устройство пользователя не поддерживает безопасное хранение ключей, DBSC корректно возвращается к стандартному поведению, не нарушая поток аутентификации.

Обзор реализации

Чтобы интегрировать DBSC в ваше приложение, вам необходимо внести следующие изменения:

• Измените процесс входа в систему, включив в него заголовок Sec-Session-Registration .
• Добавьте конечную точку регистрации сеанса, которая:
  • Связывает открытый ключ с сеансом пользователя.
  • Обслуживает конфигурацию сеанса.
  • Переход на кратковременные файлы cookie.
• Добавьте конечную точку обновления для обработки обновления файлов cookie и проверки владения ключом.

Большинство существующих конечных точек не требуют каких-либо изменений. DBSC спроектирован так, чтобы быть аддитивным и не нарушающим работу.

Если необходимый кратковременный файл cookie отсутствует или срок его действия истек, Chrome приостанавливает запрос и пытается обновить файл cookie. Это позволяет вашему приложению продолжать использовать обычные проверки файлов cookie сеанса для подтверждения входа пользователя в систему. Поскольку это соответствует типичным потокам аутентификации, DBSC работает с минимальными изменениями в вашей логике входа.

Этапы реализации

В этом разделе описаны необходимые изменения в вашей системе аутентификации, в том числе способы изменения процесса входа в систему, обработки регистрации сеанса и управления кратковременными обновлениями файлов cookie. Каждый шаг предназначен для плавной интеграции с существующей инфраструктурой.

Шаги реализации соответствуют обычному процессу, который происходит с вошедшим в систему пользователем, когда DBSC активен: регистрация при входе в систему, за которой следуют регулярные кратковременные обновления файлов cookie. Вы можете протестировать и реализовать каждый шаг независимо, в зависимости от уровня чувствительности вашего приложения к сеансу.

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 связывается с конечной точкой /StartSession с помощью открытого ключа в веб-токене JSON (JWT).

auth_cookie в этом примере представляет ваш токен сеанса. Вы можете назвать этот файл cookie как угодно, при условии, что оно соответствует полю name в конфигурации вашего сеанса и последовательно используется во всем вашем приложении.

2. Реализуйте конечную точку регистрации сеанса.

В /StartSession ваш сервер должен:

• Свяжите полученный открытый ключ с сеансом пользователя.
• Ответьте конфигурацией сеанса.
• Замените долгоживущий файл 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, наряду с недолговечным файлом cookie. Этот долгосрочный файл cookie используется только для выдачи новых кратковременных токенов и помогает отличить действительно неаутентифицированные запросы от временных сбоев DBSC.

• Долгосрочный файл cookie сохраняется даже в случае сбоя DBSC.
• Кратковременный файл cookie обновляется с помощью DBSC и необходим для конфиденциальных операций.

Этот шаблон дает сайтам больше контроля над тем, как обрабатывать крайние случаи.

Предостережения и резервное поведение

Chrome может пропускать операции DBSC и отправлять запросы без недолговечных файлов cookie, управляемых DBSC, в следующих сценариях:

• Конечная точка обновления недоступна из-за сетевых ошибок или проблем с сервером.
• Доверенный платформенный модуль занят или возникли ошибки подписи. Поскольку TPM используется совместно всеми системными процессами, чрезмерные обновления могут превысить его ограничения по скорости.
• Кратковременный файл cookie, управляемый DBSC, является сторонним файлом cookie, и пользователь заблокировал сторонние файлы cookie в настройках своего браузера.

В таких ситуациях Chrome возвращается к использованию долгоживущего файла cookie, если он все еще присутствует. Этот запасной вариант работает только в том случае, если ваша реализация включает в себя как долгосрочные, так и кратковременные файлы cookie. Если нет, Chrome отправляет запрос без файла cookie.

Краткое содержание

Учетные данные сеанса, привязанного к устройству, повышают безопасность сеанса с минимальными изменениями в вашем приложении. Они обеспечивают более надежную защиту от перехвата сеанса, привязывая сеансы к конкретным устройствам. Большинство пользователей получают выгоду, не испытывая каких-либо сбоев, а DBSC изящно переходит на неподдерживаемое оборудование.

Для получения дополнительной информации обратитесь к спецификации DBSC .

Учетные данные сеанса, привязанного к устройству (DBSC), усиливают аутентификацию за счет обеспечения аппаратной безопасности сеанса.

Daniel Rubery

José Luis Zapata

Введение

Многие веб-сайты используют долгоживущие файлы cookie для аутентификации пользователей, но они подвержены перехвату сеанса. Учетные данные сеанса с привязкой к устройству (DBSC) добавляют уровень аппаратной безопасности для снижения этого риска, гарантируя привязку сеансов к конкретным устройствам.

Это руководство предназначено для разработчиков, которые поддерживают потоки аутентификации в веб-приложениях. В нем объясняется, как работает DBSC и как интегрировать его в ваш сайт.

Как работает ДБСК

На высоком уровне DBSC представляет пару криптографических ключей, связанную с устройством пользователя. Chrome генерирует эту пару ключей во время входа в систему и сохраняет закрытый ключ на защищенном оборудовании, например в доверенном платформенном модуле (TPM) , если он доступен. В сеансах используются кратковременные файлы cookie. Когда срок действия одного из этих файлов cookie истекает, Chrome доказывает владение закрытым ключом, прежде чем обновлять его. Этот процесс связывает непрерывность сеанса с исходным устройством.

Если устройство пользователя не поддерживает безопасное хранение ключей, DBSC корректно возвращается к стандартному поведению, не нарушая поток аутентификации.

Обзор реализации

Чтобы интегрировать DBSC в ваше приложение, вам необходимо внести следующие изменения:

• Измените процесс входа в систему, включив в него заголовок Sec-Session-Registration .
• Добавьте конечную точку регистрации сеанса, которая:
  • Связывает открытый ключ с сеансом пользователя.
  • Обслуживает конфигурацию сеанса.
  • Переход на кратковременные файлы cookie.
• Добавьте конечную точку обновления для обработки обновления файлов cookie и проверки владения ключом.

Большинство существующих конечных точек не требуют каких-либо изменений. DBSC спроектирован так, чтобы быть аддитивным и не нарушающим работу.

Если необходимый кратковременный файл cookie отсутствует или срок его действия истек, Chrome приостанавливает запрос и пытается обновить файл cookie. Это позволяет вашему приложению продолжать использовать обычные проверки файлов cookie сеанса для подтверждения входа пользователя в систему. Поскольку это соответствует типичным потокам аутентификации, DBSC работает с минимальными изменениями в вашей логике входа.

Этапы реализации

В этом разделе описаны необходимые изменения в вашей системе аутентификации, в том числе способы изменения процесса входа в систему, обработки регистрации сеанса и управления кратковременными обновлениями файлов cookie. Каждый шаг предназначен для плавной интеграции с существующей инфраструктурой.

Шаги реализации соответствуют обычному процессу, который происходит с вошедшим в систему пользователем, когда DBSC активен: регистрация при входе в систему, за которой следуют регулярные кратковременные обновления файлов cookie. Вы можете протестировать и реализовать каждый шаг независимо, в зависимости от уровня чувствительности вашего приложения к сеансу.

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 связывается с конечной точкой /StartSession с помощью открытого ключа в веб-токене JSON (JWT).

auth_cookie в этом примере представляет ваш токен сеанса. Вы можете назвать этот файл cookie как угодно, при условии, что оно соответствует полю name в конфигурации вашего сеанса и последовательно используется во всем вашем приложении.

2. Реализуйте конечную точку регистрации сеанса.

В /StartSession ваш сервер должен:

• Свяжите полученный открытый ключ с сеансом пользователя.
• Ответьте конфигурацией сеанса.
• Замените долгоживущий файл 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, наряду с недолговечным файлом cookie. Этот долгосрочный файл cookie используется только для выдачи новых кратковременных токенов и помогает отличить действительно неаутентифицированные запросы от временных сбоев DBSC.

• Долгосрочный файл cookie сохраняется даже в случае сбоя DBSC.
• Кратковременный файл cookie обновляется с помощью DBSC и необходим для конфиденциальных операций.

Этот шаблон дает сайтам больше контроля над тем, как обрабатывать крайние случаи.

Предостережения и резервное поведение

Chrome может пропускать операции DBSC и отправлять запросы без недолговечных файлов cookie, управляемых DBSC, в следующих сценариях:

• Конечная точка обновления недоступна из-за сетевых ошибок или проблем с сервером.
• Доверенный платформенный модуль занят или возникли ошибки подписи. Поскольку TPM используется совместно всеми системными процессами, чрезмерные обновления могут превысить его ограничения по скорости.
• Кратковременный файл cookie, управляемый DBSC, является сторонним файлом cookie, и пользователь заблокировал сторонние файлы cookie в настройках своего браузера.

В таких ситуациях Chrome возвращается к использованию долгоживущего файла cookie, если он все еще присутствует. Этот запасной вариант работает только в том случае, если ваша реализация включает в себя как долгосрочные, так и кратковременные файлы cookie. Если нет, Chrome отправляет запрос без файла cookie.

Краткое содержание

Учетные данные сеанса, привязанного к устройству, повышают безопасность сеанса с минимальными изменениями в вашем приложении. Они обеспечивают более надежную защиту от перехвата сеанса, привязывая сеансы к конкретным устройствам. Большинство пользователей получают выгоду, не испытывая каких-либо сбоев, а DBSC изящно переходит на неподдерживаемое оборудование.

Для получения дополнительной информации обратитесь к спецификации DBSC .

Учетные данные сеанса, привязанного к устройству (DBSC), усиливают аутентификацию за счет обеспечения аппаратной безопасности сеанса.

Daniel Rubery

José Luis Zapata

Введение

Многие веб-сайты используют долгоживущие файлы cookie для аутентификации пользователей, но они подвержены перехвату сеанса. Учетные данные сеанса с привязкой к устройству (DBSC) добавляют уровень аппаратной безопасности для снижения этого риска, гарантируя привязку сеансов к конкретным устройствам.

Это руководство предназначено для разработчиков, которые поддерживают потоки аутентификации в веб-приложениях. В нем объясняется, как работает DBSC и как интегрировать его в ваш сайт.

Как работает ДБСК

На высоком уровне DBSC представляет пару криптографических ключей, связанную с устройством пользователя. Chrome генерирует эту пару ключей во время входа в систему и сохраняет закрытый ключ на защищенном оборудовании, например в доверенном платформенном модуле (TPM) , если он доступен. В сеансах используются кратковременные файлы cookie. Когда срок действия одного из этих файлов cookie истекает, Chrome доказывает владение закрытым ключом, прежде чем обновлять его. Этот процесс связывает непрерывность сеанса с исходным устройством.

Если устройство пользователя не поддерживает безопасное хранение ключей, DBSC корректно возвращается к стандартному поведению, не нарушая поток аутентификации.

Обзор реализации

Чтобы интегрировать DBSC в ваше приложение, вам необходимо внести следующие изменения:

• Измените процесс входа в систему, включив в него заголовок Sec-Session-Registration .
• Добавьте конечную точку регистрации сеанса, которая:
  • Связывает открытый ключ с сеансом пользователя.
  • Обслуживает конфигурацию сеанса.
  • Переход на кратковременные файлы cookie.
• Добавьте конечную точку обновления для обработки обновления файлов cookie и проверки владения ключом.

Большинство существующих конечных точек не требуют каких-либо изменений. DBSC спроектирован так, чтобы быть аддитивным и не нарушающим работу.

Если необходимый кратковременный файл cookie отсутствует или срок его действия истек, Chrome приостанавливает запрос и пытается обновить файл cookie. Это позволяет вашему приложению продолжать использовать обычные проверки файлов cookie сеанса для подтверждения входа пользователя в систему. Поскольку это соответствует типичным потокам аутентификации, DBSC работает с минимальными изменениями в вашей логике входа.

Этапы реализации

В этом разделе описаны необходимые изменения в вашей системе аутентификации, в том числе способы изменения процесса входа в систему, обработки регистрации сеанса и управления кратковременными обновлениями файлов cookie. Каждый шаг предназначен для плавной интеграции с существующей инфраструктурой.

Шаги реализации соответствуют обычному процессу, который происходит с вошедшим в систему пользователем, когда DBSC активен: регистрация при входе в систему, за которой следуют регулярные кратковременные обновления файлов cookie. Вы можете протестировать и реализовать каждый шаг независимо, в зависимости от уровня чувствительности вашего приложения к сеансу.

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 связывается с конечной точкой /StartSession с помощью открытого ключа в веб-токене JSON (JWT).

auth_cookie в этом примере представляет ваш токен сеанса. Вы можете назвать этот файл cookie как угодно, при условии, что оно соответствует полю name в конфигурации вашего сеанса и последовательно используется во всем вашем приложении.

2. Реализуйте конечную точку регистрации сеанса.

В /StartSession ваш сервер должен:

• Свяжите полученный открытый ключ с сеансом пользователя.
• Ответьте конфигурацией сеанса.
• Замените долгоживущий файл 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, наряду с недолговечным файлом cookie. Этот долгосрочный файл cookie используется только для выдачи новых кратковременных токенов и помогает отличить действительно неаутентифицированные запросы от временных сбоев DBSC.

• Долгосрочный файл cookie сохраняется даже в случае сбоя DBSC.
• Кратковременный файл cookie обновляется с помощью DBSC и необходим для конфиденциальных операций.

Этот шаблон дает сайтам больше контроля над тем, как обрабатывать крайние случаи.

Предостережения и резервное поведение

Chrome может пропускать операции DBSC и отправлять запросы без недолговечных файлов cookie, управляемых DBSC, в следующих сценариях:

• Конечная точка обновления недоступна из-за сетевых ошибок или проблем с сервером.
• Доверенный платформенный модуль занят или возникли ошибки подписи. Поскольку TPM используется совместно всеми системными процессами, чрезмерные обновления могут превысить его ограничения по скорости.
• Кратковременный файл cookie, управляемый DBSC, является сторонним файлом cookie, и пользователь заблокировал сторонние файлы cookie в настройках своего браузера.

В таких ситуациях Chrome возвращается к использованию долгоживущего файла cookie, если он все еще присутствует. Этот запасной вариант работает только в том случае, если ваша реализация включает в себя как долгосрочные, так и кратковременные файлы cookie. Если нет, Chrome отправляет запрос без файла cookie.

Краткое содержание

Учетные данные сеанса, привязанного к устройству, повышают безопасность сеанса с минимальными изменениями в вашем приложении. Они обеспечивают более надежную защиту от перехвата сеанса, привязывая сеансы к конкретным устройствам. Большинство пользователей получают выгоду, не испытывая каких-либо сбоев, а DBSC изящно переходит на неподдерживаемое оборудование.

Для получения дополнительной информации обратитесь к спецификации DBSC .

Учетные данные сеанса, привязанного к устройству (DBSC), усиливают аутентификацию за счет обеспечения аппаратной безопасности сеанса.

Daniel Rubery

José Luis Zapata

Введение

Многие веб-сайты используют долгоживущие файлы cookie для аутентификации пользователей, но они подвержены перехвату сеанса. Учетные данные сеанса с привязкой к устройству (DBSC) добавляют уровень аппаратной безопасности для снижения этого риска, гарантируя привязку сеансов к конкретным устройствам.

Это руководство предназначено для разработчиков, которые поддерживают потоки аутентификации в веб-приложениях. В нем объясняется, как работает DBSC и как интегрировать его в ваш сайт.

Как работает ДБСК

На высоком уровне DBSC представляет пару криптографических ключей, связанную с устройством пользователя. Chrome генерирует эту пару ключей во время входа в систему и сохраняет закрытый ключ на защищенном оборудовании, например в доверенном платформенном модуле (TPM) , если он доступен. В сеансах используются кратковременные файлы cookie. Когда срок действия одного из этих файлов cookie истекает, Chrome доказывает владение закрытым ключом, прежде чем обновлять его. Этот процесс связывает непрерывность сеанса с исходным устройством.

Если устройство пользователя не поддерживает безопасное хранение ключей, DBSC корректно возвращается к стандартному поведению, не нарушая поток аутентификации.

Обзор реализации

Чтобы интегрировать DBSC в ваше приложение, вам необходимо внести следующие изменения:

• Измените процесс входа в систему, включив в него заголовок Sec-Session-Registration .
• Добавьте конечную точку регистрации сеанса, которая:
  • Связывает открытый ключ с сеансом пользователя.
  • Обслуживает конфигурацию сеанса.
  • Переход на кратковременные файлы cookie.
• Добавьте конечную точку обновления для обработки обновления файлов cookie и проверки владения ключом.

Большинство существующих конечных точек не требуют каких-либо изменений. DBSC спроектирован так, чтобы быть аддитивным и не нарушающим работу.

Если необходимый кратковременный файл cookie отсутствует или срок его действия истек, Chrome приостанавливает запрос и пытается обновить файл cookie. Это позволяет вашему приложению продолжать использовать обычные проверки файлов cookie сеанса для подтверждения входа пользователя в систему. Поскольку это соответствует типичным потокам аутентификации, DBSC работает с минимальными изменениями в вашей логике входа.

Этапы реализации

В этом разделе описаны необходимые изменения в вашей системе аутентификации, в том числе способы изменения процесса входа в систему, обработки регистрации сеанса и управления кратковременными обновлениями файлов cookie. Каждый шаг предназначен для плавной интеграции с существующей инфраструктурой.

Шаги реализации соответствуют обычному процессу, который происходит с вошедшим в систему пользователем, когда DBSC активен: регистрация при входе в систему, за которой следуют регулярные кратковременные обновления файлов cookie. Вы можете протестировать и реализовать каждый шаг независимо, в зависимости от уровня чувствительности вашего приложения к сеансу.

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 связывается с конечной точкой /StartSession с помощью открытого ключа в веб-токене JSON (JWT).

auth_cookie в этом примере представляет ваш токен сеанса. Вы можете назвать этот файл cookie как угодно, при условии, что оно соответствует полю name в конфигурации вашего сеанса и последовательно используется во всем вашем приложении.

2. Реализуйте конечную точку регистрации сеанса.

В /StartSession ваш сервер должен:

• Свяжите полученный открытый ключ с сеансом пользователя.
• Ответьте конфигурацией сеанса.
• Замените долгоживущий файл 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, наряду с недолговечным файлом cookie. Этот долгосрочный файл cookie используется только для выдачи новых кратковременных токенов и помогает отличить действительно неаутентифицированные запросы от временных сбоев DBSC.

• Долгосрочный файл cookie сохраняется даже в случае сбоя DBSC.
• Кратковременный файл cookie обновляется с помощью DBSC и необходим для конфиденциальных операций.

Этот шаблон дает сайтам больше контроля над тем, как обрабатывать крайние случаи.

Предостережения и резервное поведение

Chrome может пропускать операции DBSC и отправлять запросы без недолговечных файлов cookie, управляемых DBSC, в следующих сценариях:

• Конечная точка обновления недоступна из-за сетевых ошибок или проблем с сервером.
• Доверенный платформенный модуль занят или возникли ошибки подписи. Поскольку TPM используется совместно всеми системными процессами, чрезмерные обновления могут превысить его ограничения по скорости.
• Кратковременный файл cookie, управляемый DBSC, является сторонним файлом cookie, и пользователь заблокировал сторонние файлы cookie в настройках своего браузера.

В таких ситуациях Chrome возвращается к использованию долгоживущего файла cookie, если он все еще присутствует. Этот запасной вариант работает только в том случае, если ваша реализация включает в себя как долгосрочные, так и кратковременные файлы cookie. Если нет, Chrome отправляет запрос без файла cookie.

Краткое содержание

Учетные данные сеанса, привязанного к устройству, повышают безопасность сеанса с минимальными изменениями в вашем приложении. Они обеспечивают более надежную защиту от перехвата сеанса, привязывая сеансы к конкретным устройствам. Большинство пользователей получают выгоду, не испытывая каких-либо сбоев, а DBSC изящно переходит на неподдерживаемое оборудование.

Для получения дополнительной информации обратитесь к спецификации DBSC .