Опубликовано: 12 ноября 2024 г.
API сигналов WebAuthn позволяет проверяющим сторонам передавать существующие учетные данные подключенным поставщикам ключей доступа. Благодаря этому поддерживающий поставщик ключей доступа может обновить или удалить неправильные или отозванные ключи доступа из своего хранилища, чтобы они больше не предлагались пользователям.
Совместимость
Chrome на рабочем столе поддерживает Signal API, начиная с Chrome 132. Диспетчер паролей Google может обновлять ключи доступа, отражающие сигнал. Поставщики ключей доступа на основе расширений Chrome решают, будут ли они отражать сигнал или нет.
Поддержка Chrome на Android появится позже.
Safari поддерживается , но еще не реализован. Firefox еще не поделился своим мнением .
Фон
При создании ключа доступа ( обнаруживаемых учетных данных ) метаданные, такие как имя пользователя и отображаемое имя, сохраняются поставщику ключа доступа (например, диспетчеру паролей) вместе с закрытым ключом, а учетные данные открытого ключа сохраняются в хранилище проверяющей стороны. (RP) сервер. Сохранение имени пользователя и отображаемого имени помогает пользователю определить, какой из предложенных ключей доступа следует использовать для входа в систему при появлении соответствующего запроса. Это особенно полезно, когда у них есть более двух ключей доступа от разных поставщиков ключей доступа.
Однако в нескольких случаях несоответствия между списком ключей поставщика ключей и списком учетных данных сервера могут привести к путанице.
В первом случае пользователь удаляет учетные данные на сервере, оставляя ключ доступа в поставщике ключей доступа нетронутым. В следующий раз, когда пользователь попытается войти в систему с помощью ключа доступа, этот ключ доступа все равно будет предоставлен пользователю поставщиком ключа доступа. Однако попытка входа завершится неудачей, поскольку сервер не сможет выполнить проверку с помощью открытого ключа, который был удален.
Второй случай — когда пользователь обновляет свое имя пользователя или отображаемое имя на сервере. В следующий раз, когда пользователь попытается войти в систему, ключ доступа в поставщике ключей доступа продолжит отображать старое имя пользователя и отображаемое имя, несмотря на то, что они обновлены на сервере. В идеале они должны быть синхронизированы.
Сигнальный API
Signal API — это API WebAuthn, который разрешает эту путаницу, позволяя RP сигнализировать об изменениях поставщику ключей доступа. Существует три метода:
-
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 можно вызвать , если вход на основе пароля не удался из-за отсутствия учетных данных . Таким образом, RP может предотвратить попытку пользователя войти в систему с ключом доступа, у которого нет связанных учетных данных. В отличие от 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 помогает вам улучшить работу с ключами доступа, устраняя вероятность неожиданного сбоя входа в систему. С помощью Signal API проверяющие стороны могут сообщать список существующих учетных данных и их метаданных, чтобы они могли синхронизировать ключи доступа у поставщика ключей доступа.
Чтобы узнать больше о ключах доступа, начните с входа в систему без пароля с помощью ключей доступа .