TsgcWSAPIServer_WebAuthn

El componente TsgcWSAPIServer_WebAuthn ofrece una solución sencilla pero potente para implementar el servidor de parte confiante WebAuthn, habilitando la autenticación sin contraseña en su aplicación web. Una aplicación WebAuthn consta de un servidor WebAuthn que gestiona el registro y la autenticación del lado del servidor, y una aplicación del lado del cliente que normalmente es una aplicación JavaScript.

 

WebAuthn requiere el uso de conexiones seguras (SSL/TLS), por lo que las bibliotecas OpenSSL deben desplegarse y configurarse con el servidor.

 

Solo se admite la API de OpenSSL 3.0.0+, por lo que las versiones anteriores de OpenSSL pueden no funcionar.

 

Configuración

 

El TsgcWSAPIServer_WebAuthn debe asociarse a un servidor HTTP, TsgcWebSocketHTTP_Server o TsgcWebSocketServer_HTTPAPI, mediante la propiedad Server. Puede configurar los endpoints del servidor que gestionarán el registro y las opciones de autenticación, así como las opciones de WebAuthn como los algoritmos admitidos, los orígenes y más.

 

Opciones de Endpoints

Aquí puede configurar los endpoints del servidor que gestionarán las solicitudes HTTP/JavaScript para usar WebAuthn como autenticador. El componente ya está configurado con endpoints predeterminados, pero puede cambiarlos todos para adaptarlos a sus necesidades.

 

• AuthenticationOptions: por defecto es /sgcWebAuthn/Authentication/Options
• AuthenticationVerify: por defecto es /sgcWebAuthn/Authentication/Verify
• RegistrationOptions: por defecto es /sgcWebAuthn/Registration/Options
• RegistrationVerify: por defecto es /sgcWebAuthn/Registration/Verify
• Webauthn: incluye la biblioteca javascript utilizada por defecto. Puede deshabilitar esta propiedad y usar su propia biblioteca webauthn.
• Test: está deshabilitado de forma predeterminada; úselo únicamente para probar la funcionalidad de WebAuthn.

 

Ejemplo: si su servidor escucha en el dominio www.test.com, la solicitud de opciones de autenticación por defecto será http://www.test.com/sgcWebAuthn/Authentication/Options

 

Opciones de WebAuthn

En esta propiedad puede configurar las opciones principales del componente servidor WebAuthn.

 

• RelyingParty: una propiedad obligatoria donde se debe definir el nombre DNS del servidor. Ejemplo: si el servidor se ejecuta en el dominio www.test.com, establezca esta propiedad en "www.test.com".

 

WebAuthn utiliza orígenes para aplicar restricciones de política del mismo origen, que son esenciales para prevenir ataques de phishing y entre sitios. Durante los procesos de registro y autenticación de WebAuthn, el origen es validado estrictamente por el navegador y el autenticador.

 

• Origins: Si las solicitudes pueden provenir de diferentes orígenes, use la propiedad Origin para establecer los orígenes adicionales. Ejemplo: si las solicitudes pueden provenir de login.test.com y www.test.co.uk, configure la propiedad Origins con los valores: https://login.test.com y https://www.test.co.uk

 

• TopOrigins: Normalmente, WebAuthn se basa en el origen del marco que realiza la llamada (es decir, el que invoca navigator.credentials.create() o navigator.credentials.get()). Sin embargo, las páginas web pueden incrustarse en iframes, que pueden proceder de un origen diferente al de la página de nivel superior. Esto abre la posibilidad de abusos o ataques de tipo clickjacking. Para mitigarlo, la especificación WebAuthn Level 2 introduce TopOrigin, donde puede definir los TopOrigins.

 

En WebAuthn, crossOrigin es un parámetro booleano que indica si la operación WebAuthn se está realizando desde un contexto de origen cruzado, como un iframe incrustado desde un origen diferente al del contexto de navegación de nivel superior.

Este parámetro fue introducido para ayudar a los navegadores y autenticadores a gestionar de forma segura las solicitudes de autenticación en entornos integrados, un escenario común en las aplicaciones web modernas.

 

• AllowCrossOrigins: si es verdadero, indica que se permiten las solicitudes realizadas desde un iframe de origen cruzado (por ejemplo, un iframe en https://auth.example.com incrustado en una página en https://app.example.org). De forma predeterminada, está deshabilitado.

 

WebAuthn admite una variedad de algoritmos criptográficos para la generación y verificación de credenciales de clave pública. Estos algoritmos se utilizan durante el registro de credenciales (con navigator.credentials.create()) y la autenticación (con navigator.credentials.get()), y garantizan la firma y validación seguras de los desafíos mediante pares de claves asimétricas. El servidor está configurado de forma predeterminada con ES256 y RS256, que son los algoritmos más comunes. Puede cambiar en cualquier momento qué algoritmos son compatibles desde la propiedad Algorithms. Se admiten los siguientes algoritmos:

 

• ES256
• ES384
• ES512
• RS256
• RS384
• RS512
• PS256
• PS384
• PS512
• RS1
• EdDSA

 

En WebAuthn, la attestation es un mecanismo opcional que permite al autenticador (p. ej., dispositivo o clave de seguridad) proporcionar información sobre su fabricante, modelo y características de seguridad durante la creación de credenciales. Esta información ayuda a la Parte Confiante (RP) a decidir si confiar en el autenticador.

 

Los distintos formatos de attestation definen cómo se estructuran y verifican estos datos. Tres formatos de uso frecuente son android-key, packed y otros como fido-u2f, apple o none. De forma predeterminada, todos los formatos de attestation están habilitados. A continuación puede encontrar la lista de formatos de attestation admitidos:

 

• NoneAttestation: en este caso no se devuelven datos de atestación. Prioriza la privacidad del usuario evitando la exposición de identificadores de dispositivo. Es habitual en aplicaciones que no se preocupan por la procedencia del dispositivo.

 

• PackedAttestation: es un formato flexible y compacto utilizado por muchos autenticadores. El autenticador devuelve un certificado de atestación y una firma. Puede ser: Atestación completa: Firmada con una clave y certificado proporcionados por el proveedor o Autoatestación: Firmada con la clave privada de la credencial. La más ampliamente utilizada en diferentes plataformas (por ejemplo, YubiKey, Windows Hello).

 

• TPMAttestation: Utilizado por dispositivos con un Módulo de Plataforma Segura (TPM). La atestación se firma usando claves del TPM e incluye una cadena de certificados. Se usa en equipos de escritorio/portátiles empresariales con chips TPM (p. ej., máquinas Windows).

 

• AndroidKeyAttestation: Utilizado por dispositivos Android con el Android Keystore. La clave se genera en hardware y la attestation incluye información firmada por una cadena de certificados emitida por el fabricante del dispositivo. Usado por teléfonos Android con keystores respaldados por hardware (TEE o StrongBox).

 

• AppleAttestation: Utilizado por los autenticadores de la plataforma Apple, como Touch ID y Face ID. La atestación es generada por las API internas de Apple e incluye un formato de certificado especial. Se usa en Safari con biometría Apple.

 

• FidoU2FAttestation: Formato de atestación heredado utilizado por los autenticadores FIDO U2F. Devuelve un certificado y una firma compatibles con U2F. Utilizado por llaves de seguridad más antiguas (p. ej., las primeras YubiKeys) que admiten FIDO U2F.

 

En la API de WebAuthn, AllowCredentials es un campo opcional utilizado durante el proceso de autenticación (a través de navigator.credentials.get()). Especifica una lista de IDs de credenciales que tienen permiso para autenticar al usuario para una Parte Confiante (RP) particular. Este mecanismo permite a la RP controlar qué credenciales se consideran válidas para un intento de inicio de sesión. La propiedad credentials tiene los siguientes campos:

 

• AllowCredentials: si está habilitado (falso por defecto), especifica una lista de IDs de credenciales que tienen permiso para autenticar al usuario

 

• ExcludeCredentials: dado un nombre de usuario, muestra todas las credenciales existentes ya almacenadas en el componente del servidor.

 

• Limit: el número máximo de credenciales que se enviarán cuando ExcludeCredentials sea true.

 

Protocolo WebAuthn

 

• Registro WebAuthn: El servidor genera un desafío y lo envía al cliente, que utiliza un autenticador (p. ej., una llave de seguridad o un dispositivo biométrico) para crear un par de claves. La clave pública se devuelve y el servidor la almacena para futuras autenticaciones. A continuación encontrará más información sobre los eventos del flujo de registro:
  • Solicitud de registro WebAuthn
  • Respuesta de registro WebAuthn
  • Resultado del registro WebAuthn

 

• Autenticación WebAuthn: El servidor envía un desafío al cliente, que lo firma usando la clave privada previamente registrada almacenada en el autenticador. La respuesta firmada es verificada por el servidor usando la clave pública almacenada para confirmar la identidad del usuario. A continuación encontrará más información sobre los eventos del flujo de autenticación:
  • Solicitud de autenticación WebAuthn
  • Respuesta de autenticación WebAuthn
  • Resultado de autenticación WebAuthn

 

• MDS: El servicio de metadatos de la FIDO Alliance (MDS) es un repositorio centralizado de declaraciones de metadatos utilizado por las partes dependientes para validar la atestación del autenticador y probar la autenticidad del modelo de dispositivo.

 

 

• Autorización: El cliente puede solicitar un token de portador al servidor durante el flujo de autenticación. Este token puede usarse posteriormente para abrir una nueva conexión WebSocket o HTTP sin necesidad de iniciar sesión con claves de acceso.
  • Autorización WebAuthn WebSocket
  • Autorización WebAuthn HTTP