Si leyó la publicación de blog anterior o ya es un experto, sabe que la especificación de credenciales verificables es lo suficientemente interesante como para cambiar por completo la forma en que manejamos las identidades de los usuarios. Sin embargo, al final del día, lo que importa es hacer que funcione y que esté en manos de usuarios reales. En esta publicación, le mostraré cómo implementamos Entra Verified ID.
Construyendo la demostración
Dado que Verifiable Credentials se basa en una API REST Web2 regular, no hay una curva de aprendizaje pronunciada para descubrir cómo anclar datos a la cadena de bloques o IPFS: Microsoft se encarga de eso por usted. Sin embargo, informa sus decisiones de arquitectura. Efectivamente, tienes dos opciones:
1. Integre Verified ID con su solución de identidad existente
Así funciona la demostración de Woodgrove y el verificador presencial. Este enfoque se recomienda para aplicaciones que están actualmente en producción e integradas con un proveedor de identidad basado en OpenID Connect (OIDC) (básicamente cualquier cosa que no sea de campo verde).
Esencialmente, su proveedor de identidad trabaja con una API para emitir una Credencial verificable con la clave de usuario de su proveedor de identidad (objectId en nuestro caso). Cuando presenta esa credencial nuevamente al IdP, puede resolver su cuenta e iniciar sesión. Dado que la credencial está firmada criptográficamente por el emisor, puede actuar como un identificador válido. La demostración a continuación utiliza el flujo de atestación de “sugerencia de token de identificación” donde el identificador del usuario (ID de objeto en este caso) se pasa directamente a la API de ID verificada para emitir la credencial.
Tenga en cuenta que hay otro flujo: la atestación de “token de identificación” , que vincula el VC directamente al IdP de OpenID y requiere que el usuario inicie sesión en su dispositivo.
Para probar la demostración, vaya a https://woodgrovedemo.com/Configuration y seleccione “Local & Social with Integrated DID” y presione “update”.
Luego, vaya a ” https://woodgrovedemo.com/Account/LogIn ” y seleccione “Iniciar sesión con su cuenta personal”.
Esto lo llevará a través del flujo de registro donde se le presentará una identificación para escanear y agregar a su billetera. A continuación, debería poder cerrar la sesión y volver a iniciarla utilizando la Credencial verificable que se le emitió.
2. Use Entra Verified ID directamente en una aplicación totalmente nueva
Con este método, necesita controlar toda la pila web. Dado que Verified ID es una API REST que requiere un token, su aplicación debe poder mantener un secreto. Por lo tanto, necesita un backend, y ese backend debe interactuar con Verified ID.
Otro problema es que hay múltiples eventos de devolución de llamada a los que su aplicación debe responder. Cuando el usuario escanea el código QR, Azure notifica a su aplicación (request_retrieved). Si la verificación o emisión fue exitosa, también obtiene un evento allí:
Por lo tanto, su aplicación necesita efectivamente un punto de enlace similar a un webhook al que Azure pueda enviar una POST… pero entonces, ¿cómo notifica a la interfaz? Podría hacer sondeos… pero eso puede ser costoso a gran escala y desperdicia recursos buscando eventos que aún no existen. Introduzca WebSockets:
Ahora, cuando el servidor recibe un evento de devolución de llamada de Verified ID, ¡podemos notificar al cliente de inmediato, en tiempo real! La aplicación frontend también se siente mejor con esto, ya que no hay que esperar para el siguiente intervalo de encuesta.
Pero espera hay mas. En las pruebas, descubrimos que iOS es bastante agresivo al terminar las conexiones de WebSocket. Dado que los usuarios móviles deben cambiar a Microsoft Authenticator para presentar su credencial, esto fue un gran problema, porque cuando los usuarios regresaron, su conexión WebSocket no se restauró y el flujo se interrumpió.
Estaba un poco perdido, pero pensé que si los juegos de Jackbox lo hacían funcionar, yo también podría (¿alguien más jugó mucho a Jackbox durante la pandemia? Por cierto, Party Pack 9 ya está disponible).
Terminé escribiendo un identificador de dispositivo + una solución de almacenamiento en caché del lado del servidor para permitir que los clientes se vuelvan a conectar y obtengan el último evento que sucedió mientras estaban desconectados.
Bueno, eso fue mucho trabajo, ¡pero diría que valió la pena! Puede ejecutar toda la demostración en su teléfono si lo desea, lo que creo que es genial (sin mencionar que es útil y práctico).
Envolver
Como puede ver, Verifiable Credentials es en gran medida un servicio en el que debe envolver su propia solución. Habiendo dicho eso, la parte más difícil es reconfigurar tu cerebro para aprender todos los nuevos conceptos y nuevas formas de hacer las cosas. En mi experiencia, la API tiene un tiempo de actividad sólido. La documentación es buena, pero faltan ejemplos de código para cualquier cosa que no sea C# .NET.
Recursos
- Documentación: configure su instancia de Entra Verified ID
- Consulte el directorio de ejemplos de código
- Documento técnico de OpenID para credenciales verificables (por la fundación OpenID)
- Agregue todos los documentos estándar a su lista de lectura (para cuando necesite una lectura ligera)
Notas
*Consulte el atributo “configuración” en la definición de reglas: https://learn.microsoft.com/en-us/azure/active-directory/verifiable-credentials/how-to-use-quickstart-idtoken#sample-json- reglas-definiciones