Saltar al contenido principal

WebAuthn, OpenID Connect y OAuth

WebAuthn, OpenID Connect y OAuth resuelven problemas diferentes en la capa de acceso de UbID:

  • WebAuthn y FIDO2 proporcionan autenticación robusta con clave pública y passkeys.
  • OpenID Connect establece una sesión autenticada interoperable y comunica claims de identidad sobre esa sesión.
  • OAuth otorga a un cliente autorización acotada para invocar una API protegida.

Ninguno de estos protocolos es un formato de credencial verificable, un método DID ni una política de verificación de credenciales.

WebAuthn y passkeys​

WebAuthn permite que una parte usuaria registre y utilice credenciales de clave pública creadas por un autenticador. La llave privada permanece bajo control del autenticador, mientras la parte usuaria almacena material público de verificación.

La autenticación está acotada a la parte usuaria y mediada por el navegador o la plataforma. Esto reduce la exposición al phishing de contraseñas y al compromiso de contraseñas en servidores.

Un despliegue de passkeys todavía debe gobernar:

  • enrolamiento y vinculación con la cuenta;
  • ciclo de vida del autenticador y del dispositivo;
  • requisitos de presencia o verificación del usuario;
  • política de sincronización cuando corresponda;
  • pérdida de dispositivos y tratamiento de recuperación;
  • reenrolamiento y eliminación de credenciales;
  • requisitos step-up para operaciones sensibles;
  • rutas de fallback y su evidencia.

WebAuthn demuestra control de un autenticador enrolado. No demuestra que la identidad civil del usuario se haya establecido correctamente ni que una credencial presentada después deba aceptarse.

Sesiones OpenID Connect​

OpenID Connect añade una capa de identidad a OAuth. Un OpenID Provider autentica al usuario y devuelve a un cliente un ID Token y claims relacionados.

En UbID, OIDC puede respaldar federación empresarial y sesiones de aplicaciones mientras la confianza en credenciales permanece como un dominio separado. Un login OIDC satisfactorio no demuestra automáticamente posesión de una credencial verificable concreta ni autoriza toda operación de identidad.

El diseño de sesiones debe abordar validación del issuer, audiencia, nonce, state, validación de redirects, vida de tokens, logout, reautenticación y contexto de assurance.

Autorización OAuth​

OAuth permite que un cliente obtenga un access token para un recurso protegido bajo un grant de autorización definido. El token debe limitarse por audiencia, scope, recurso, duración, cliente y política.

UbID sigue los principios actuales de seguridad de OAuth, incluidos flujos authorization code, PKCE para clientes públicos, coincidencia exacta de redirects, protección contra replay de códigos y tokens, privilegios acotados, autenticación segura del cliente cuando corresponda y rechazo de patrones deprecados.

Un access token no es una contraseña de usuario, una credencial ni una prueba universal de identidad. Los resource servers deben validarlo para la API y operación previstas.

Uso complementario en UbID​

Una interacción típica puede utilizar las tres capas:

  1. WebAuthn autentica al usuario en la Wallet o portal.
  2. OpenID Connect establece una sesión de aplicación.
  3. OAuth autoriza a un cliente para invocar una API de credenciales o confianza.
  4. Un protocolo separado emite o presenta evidencia verificable.
  5. Un verificador aplica política de credenciales y transacciones.

Mantener separadas estas capas facilita revisar responsabilidades y evidencia.

Consideraciones de seguridad y privacidad​

  • No utilizar claims de autenticación como sustituto de política de autorización.
  • No conceder scopes amplios de API solo porque el usuario se autenticó de forma robusta.
  • No exponer tokens en historial del navegador, logs, referrers u orígenes no relacionados.
  • No inferir la identidad de una persona únicamente de la attestation del autenticador.
  • No hacer que el fallback sea más fácil de abusar que la autenticación ordinaria.
  • No correlacionar usuarios entre partes usuarias mediante identificadores evitables.
  • Exigir autorización reciente o step-up para operaciones de alto impacto.

Posición de UbID​

Las passkeys y la política de autenticación server-side forman parte de la baseline implementada de UbID. OIDC y OAuth proporcionan contratos de referencia para federación, sesión y autorización de APIs. Los flujos exactos, requisitos de assurance, proveedores de identidad, scopes y políticas de fallback dependen del despliegue.

Límite de la documentación pública​

El portal público no publica orígenes registrados, redirect URIs, client secrets, audiencias de tokens, scopes privados, configuración de sesiones, allow-lists de autenticadores, secuencias de fallback ni metadatos productivos de federación.

Estándares fuente​

Consulta Autenticación y seguridad de dispositivos y UbID Access.