Обеспечьте соответствие ключей доступа учетным данным на вашем сервере с помощью Signal API.

Eiji Kitamura

Опубликовано: 12 ноября 2024 г., Последнее обновление: 29 ноября 2024 г.

API WebAuthn Signal позволяет проверяющим сторонам передавать существующие учётные данные подключённым поставщикам ключей доступа. Благодаря этому поставщик ключей доступа может обновить или удалить неверные или отозванные ключи из своего хранилища, чтобы они больше не предлагались пользователям.

Совместимость

Chrome для ПК поддерживает API Signal, начиная с Chrome 132. Менеджер паролей Google может обновлять ключи доступа, отражая сигнал. Поставщики ключей доступа на основе расширений Chrome сами решают, будут ли они отображать сигнал.

Поддержка Chrome на Android появится позже.

Safari поддерживает эту функцию , но пока не реализовал её. Firefox пока не поделился своим мнением .

Фон

При создании ключа доступа ( обнаруживаемых учётных данных ) метаданные, такие как имя пользователя и отображаемое имя, сохраняются у поставщика ключей доступа (например, в менеджере паролей) вместе с закрытым ключом, в то время как учётные данные открытого ключа сохраняются на сервере проверяющей стороны (RP). Сохранение имени пользователя и отображаемого имени помогает пользователю определить, какой из предложенных ключей доступа использовать для входа при запросе. Это особенно полезно, если у него есть более двух ключей доступа от разных поставщиков.

Однако существуют некоторые случаи, когда несоответствия между списком ключей доступа поставщика и списком учетных данных сервера могут привести к путанице.

Первый случай — когда пользователь удаляет учётные данные на сервере, оставляя ключ доступа у поставщика ключей доступа нетронутым. При следующей попытке входа с ключом доступа поставщик ключей доступа по-прежнему предоставит этот ключ. Однако попытка входа завершится неудачей, поскольку сервер не сможет выполнить проверку с помощью удалённого открытого ключа.

Второй случай — когда пользователь обновляет своё имя пользователя или отображаемое имя на сервере. При следующей попытке входа в систему ключ доступа в поставщике ключей доступа продолжает отображать старые имя пользователя и отображаемое имя, несмотря на то, что они были обновлены на сервере. В идеале они должны быть синхронизированы.

API сигналов

Signal API — это API WebAuthn, который решает эти проблемы, позволяя проверяющим сторонам сообщать об изменениях поставщику ключей доступа. Существует три метода:

• PublicKeyCredential.signalUnknownCredential : сигнал о том, что учетные данные не существуют.
• PublicKeyCredential.signalAllAcceptedCredentials : выдать список сохраненных учетных данных
• PublicKeyCredential.signalCurrentUserDetails : Сигнал об обновлении имени пользователя и/или отображаемого имени

Сигнал о том, что учетные данные не существуют

const credential = await navigator.credentials.get({ ... });
const payload = credential.toJSON();

const result = await fetch('/login', { ... });

// Detect authentication failure due to lack of the credential
if (result.status === 404) {
  // Feature detection
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
    });
  } else {
    // Encourage the user to delete the passkey from the password manager nevertheless.
    ...
  }
}

Вызывая метод PublicKeyCredential.signalUnknownCredential() с идентификаторами RP и учётных данных, RP может сообщить поставщику ключа доступа о том, что указанные учётные данные удалены или не существуют. Поставщик ключа доступа самостоятельно решает, как обрабатывать этот сигнал, но ожидается, что связанный с ним ключ доступа будет удалён, чтобы пользователь не смог войти с ключом доступа, поскольку связанные с ним учётные данные отсутствуют.

Этот API можно вызвать , если вход с помощью ключа доступа не удался из-за отсутствия учётных данных . Таким образом, проверяющая сторона может предотвратить попытку пользователя войти с ключом доступа, с которым не связаны учётные данные. В отличие от signalAllAcceptedCredentials , этот метод не требует передачи всего списка идентификаторов учётных данных, поэтому его следует использовать, когда пользователь не аутентифицирован, чтобы не раскрывать количество ключей доступа для данного пользователя.

Вывести список сохраненных учетных данных

// After a user deletes a passkey or a user is signed in.

// Feature detection
if (PublicKeyCredential.signalAllAcceptedCredentials) {
  await PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "M2YPl-KGnA8", // base64url encoded user ID
    allAcceptedCredentialIds: [ // A list of base64url encoded credential IDs
      "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA",
      ...
    ]
  });
}

Вызывая метод PublicKeyCredential.signalAllAcceptedCredentials() с идентификатором RP, идентификатором пользователя и списком идентификаторов сохранённых учётных данных, RP может сообщить поставщику ключей доступа об оставшихся учётных данных в его хранилище. Поставщик ключей доступа самостоятельно решает, как обрабатывать этот сигнал, но ключи доступа, не соответствующие этому списку, должны быть удалены, чтобы пользователь не видел при входе ключи доступа, для которых соответствующие учётные данные отсутствуют.

Этот API следует вызывать , когда пользователь удаляет ключ доступа на RP и при каждом входе в систему , чтобы поставщик ключей доступа мог вести синхронизированный список ключей доступа.

Сигнал обновил имя пользователя и отображаемое имя

// After a user updated their username and/or display name
// or a user is signed in.

// Feature detection
if (PublicKeyCredential.signalCurrentUserDetails) {
  await PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "M2YPl-KGnA8", // base64url encoded user ID
    name: "a.new.email.address@example.com", // username
    displayName: "J. Doe"
  });
} else {
}

Вызывая метод PublicKeyCredential.signalCurrentUserDetails() с идентификатором RP, идентификатором пользователя, именем пользователя и отображаемым именем, RP может сообщить поставщику ключей доступа об обновлении информации о пользователе. Поставщик ключей доступа решает, как обрабатывать этот сигнал, но ожидается, что ключи доступа, принадлежащие пользователю, будут обновлены с учетом новой информации о пользователе.

Этот API может вызываться при обновлении имени пользователя или отображаемого имени , а также при каждом входе в систему , чтобы поставщик ключа доступа мог синхронизировать эту информацию с сервером.

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

API Signal помогает улучшить работу с ключами доступа, исключая вероятность непредвиденных ошибок входа. С помощью API Signal проверяющие стороны могут передавать список существующих учётных данных и их метаданные, чтобы синхронизировать ключи доступа с поставщиком ключей доступа.

Чтобы узнать больше о ключах доступа, начните с раздела Вход без пароля с ключами доступа .