Chrome 128 y 129 presentan nuevas e interesantes funciones para WebAuthn: el subyacente para compilar sistemas de autenticación basados en llaves de acceso.
- Pistas: Las sugerencias les brindan a los usuarios de confianza (RP) un mejor control sobre WebAuthn. IU en el navegador. Son especialmente útiles para los usuarios empresariales que desean usen llaves de seguridad.
- Solicitudes de origen relacionadas: Con un origen relacionado solicitudes, las RP pueden hacer que las llaves de acceso sean válidas en varios dominios. Si tienes varias ahora puedes permitir que los usuarios reutilicen su llave de acceso en tus sitios, lo que elimina la fricción en el acceso.
- Serialización JSON: Las APIs de serialización JSON te permiten simplificar el código de frontend de un RP con las opciones de codificación y decodificación. credenciales que se pasan desde y hacia la API de WebAuthn.
Sugerencias
Con hints
, los usuarios de confianza (RP) ahora pueden especificar preferencias de IU para crear un
o autentica con una llave de acceso.
Anteriormente, cuando una parte restringida quería restringir el autenticador que el usuario podía usar para
una llave de acceso o para autenticarse, podrían usar
authenticatorSelection.authenticatorAttachment
para especificar "platform"
"cross-platform"
Limitan respectivamente el autenticador a una plataforma
autenticador
o un roaming
autenticador.
Con hints
, esta especificación puede ser más flexible.
La parte restringida puede usar hints
opcionales en la PublicKeyCredentialCreationOptions
o
PublicKeyCredentialRequestOptions
para especificar "security-key"
"client-device"
y "hybrid"
en un orden de preferencia en un array.
El siguiente es un ejemplo de solicitud de creación de credenciales que prefiere
"cross-platform"
autenticadores con "security-key"
como pista. Esto le indica
Chrome mostrará una IU enfocada en las llaves de seguridad para los usuarios empresariales.
const credential = await navigator.credentials.create({
publicKey: {
challenge: *****,
hints: ['security-key'],
authenticatorSelection: {
authenticatorAttachment: 'cross-platform'
}
}
});
![Especificando "security-key" como pista, el navegador muestra un diálogo enfocado en la llave de seguridad.](https://developer.chrome.google.cn/static/blog/passkeys-updates-chrome-129/image/security-key.png?hl=es-419)
Cuando una parte restringida quiere priorizar una situación de verificación en varios dispositivos, puede
envía una solicitud de autenticación que prefiere autenticadores "cross-platform"
con "hybrid"
como pista.
const credential = await navigator.credentials.create({
publicKey: {
challenge: *****,
residentKey: true,
hints: ['hybrid']
authenticatorSelection: {
authenticatorAttachment: 'cross-platform'
}
}
});
![Con la especificación de "híbrido" como pista, el navegador muestra un diálogo enfocado en el acceso multidispositivo.](https://developer.chrome.google.cn/static/blog/passkeys-updates-chrome-129/image/cross-device.png?hl=es-419)
Solicitudes de origen relacionadas
Con origen relacionado Las solicitudes, las RP pueden permiten que las llaves de acceso se puedan usar desde varios dominios. Creación de un acceso centralizado y el uso de protocolos de federación sigue siendo la solución recomendada para en la mayoría de los sitios. Pero si posee varios dominios y la federación no es posible los orígenes relacionados puede ser una solución.
Todas las solicitudes de WebAuthn deben especificar un ID de usuario de confianza (ID de RP) y todas las llaves de acceso.
se asocian con un solo ID de RP. Tradicionalmente, un origen solo podía especificar
un ID de RP basado en su dominio, por lo que, en ese caso, www.example.co.uk
podría especificar
un ID de RP de example.co.uk
, pero no de example.com
. Con origen relacionado
Solicitudes, un ID de RP reclamado se puede validar si se recupera un archivo JSON conocido
ubicado en /.well-known/webauthn
del dominio de destino. Entonces example.co.uk
(y example.in
, example.de
, etc.) podrían usar un ID de RP de
example.com
si example.com
las especifica en el siguiente formato:
URL: https://example.com/.well-known/webauthn
{
"origins": [
"https://example.co.uk",
"https://example.de",
"https://example.sg",
"https://example.net",
"https://exampledelivery.com",
"https://exampledelivery.co.uk",
"https://exampledelivery.de",
"https://exampledelivery.sg",
"https://myexamplerewards.com",
"https://examplecars.com"
]
}
Para obtener información sobre cómo configurar las solicitudes de origen relacionadas, visita Permitir la reutilización de llaves de acceso en tus sitios con Origen relacionado Solicitudes.
Serialización JSON
Los objetos de solicitud y respuesta de WebAuthn tienen varios campos que contienen datos binarios en un ArrayBuffer, como el ID de credencial, el ID de usuario o el desafío. Si un sitio web quiere usar JSON para intercambiar estos datos con su servidor, el objeto binario los datos primero deben codificarse, por ejemplo, con Base64URL. Esto agrega entradas innecesarias para los desarrolladores que quieran comenzar a usar llaves de acceso en sus sitios web.
WebAuthn ahora ofrece APIs para analizar
PublicKeyCredentialCreationOptions
y
PublicKeyCredentialRequestOptions
WebAuthn solicita los objetos directamente desde JSON y serializa el
PublicKeyCredential
respuesta directa en JSON. Todos los campos con valores ArrayBuffer que tienen objetos binarios sin procesar
los datos se convierten automáticamente a partir de sus valores codificados en Base64URL o a ellos.
Estas APIs están disponibles a partir de Chrome 129.
Antes de crear una llave de acceso, recupera un archivo JSON
PublicKeyCredentialCreationOptions
del servidor y decodificarlo con
PublicKeyCredential.parseCreationOptionsFromJSON()
export async function registerCredential() {
// Fetch encoded `PublicKeyCredentialCreationOptions`
// and JSON decode it.
const options = await fetch('/auth/registerRequest').json();
// Decode `PublicKeyCredentialCreationOptions` JSON object
const decodedOptions = PublicKeyCredential.parseCreationOptionsFromJSON(options);
// Invoke the WebAuthn create() function.
const cred = await navigator.credentials.create({
publicKey: decodedOptions,
});
...
Después de crear una llave de acceso, codifica la credencial resultante con toJSON()
para
que puede enviarse al servidor.
...
const cred = await navigator.credentials.create({
publicKey: options,
});
// Encode the credential to JSON and stringify
const credential = JSON.stringify(cred.toJSON());
// Send the encoded credential to the server
await fetch('/auth/registerResponse', credential);
...
Antes de autenticarte con una llave de acceso, recupera un archivo JSON codificado
PublicKeyRequestCreationOptions
del servidor y decodifícalo con
PublicKeyCredential.parseRequestOptionsFromJSON()
export async function authenticate() {
// Fetch encoded `PublicKeyCredentialRequestOptions`
// and JSON decode it.
const options = await fetch('/auth/signinRequest').json();
// Decode `PublicKeyCredentialRequestOptions` JSON object
const decodedOptions = PublicKeyCredential.parseRequestOptionsFromJSON(options);
// Invoke the WebAuthn get() function.
const cred = await navigator.credentials.get({
publicKey: options
});
...
Luego de autenticarte con una llave de acceso, codifica la credencial resultante usando
toJSON()
para que se pueda enviar al servidor.
...
const cred = await navigator.credentials.get({
publicKey: options
});
// Encode the credential to JSON and stringify
const credential = JSON.stringify(cred.toJSON());
// Send the encoded credential to the server
await fetch(`/auth/signinResponse`, credential);
...
Más información
Para obtener más información sobre WebAuthn y las llaves de acceso, consulta los siguientes recursos: