Autenticación de usuarios de React para la identidad soberana con Magic

Hola, bienvenido a esta charla, donde hablaré sobre la autenticación de usuarios en React para la identidad soberana con Magic Labs. Soy Muhammad Shahbaz Alam, uno de los defensores del desarrollo en Magic Labs, y en esta charla aprenderemos cómo el modelo de confianza del usuario en Internet está roto, una solución novedosa para solucionarlo y cómo lograr la identidad soberana en React. Aprenderemos qué es DID, DIDT y también cómo construir el tuyo propio. Así que entendamos cómo está roto el modelo de confianza de Internet. Los usuarios piensan en contraseñas o secretos específicos para ellos para verificar su identidad y los entregan a aplicaciones propiedad de diversas empresas. El 59% de todos los usuarios reutilizan su contraseña en diferentes aplicaciones. Los usuarios confían en que las empresas almacenarán los secretos de forma segura y responsable, pero muchas empresas no tienen una autenticación adecuada y conocimiento previo de seguridad, lo que lleva a violaciones de seguridad. Los usuarios acceden a los servicios de la empresa mostrando el secreto cada vez que inician sesión, y cada vez que se muestra el secreto, existe el riesgo de exponerlo a los hackers. Las empresas pueden ser hackeadas y perder los secretos de los usuarios, junto con su confianza. El 48% de los clientes nunca regresan después de una violación de seguridad. La violación de seguridad de Equifax les ha costado al menos $4.1 mil millones. Los hackers utilizan los secretos robados para suplantar a los usuarios y acceder a sus servicios en línea vitales. Este problema se agrava hasta el punto en que la identidad del usuario ya no está en sus manos, sino controlada por grandes corporaciones. Construir tu propia autenticación es muy costoso. Requiere experiencia en seguridad e infraestructura. Requiere cumplimiento de seguridad y privacidad. Asegurar la disponibilidad global a gran escala. Mantenerse actualizado con las últimas tendencias de seguridad. Asegurar la entrega de correo electrónico y SMS. Implementar la internacionalización para permitir el acceso de una audiencia global. Además, defenderse contra ataques de denegación de servicio distribuido (DDoS) y spam.

Estoy aquí para presentar una solución novedosa para solucionar todos los problemas. En esta parte, vamos a entender qué es la prueba de conocimiento cero. En la prueba de conocimiento cero, el propietario de una clave privada no necesita revelar su clave privada para demostrar que es dueño de la clave. Lo que las personas intentaron antes de Magic es un modelo basado en claves. En lugar de que los usuarios piensen en sus propios secretos, utilizan pares de claves públicas y privadas basadas en blockchain generadas al azar para acceder a aplicaciones. Tiene sus pros y sus contras. Los pros son que los usuarios tienen un control completo de su identidad. Las empresas ya no pueden ver los secretos del usuario. Y el usuario utiliza el mismo secreto para acceder a las aplicaciones, lo cual es un modelo de confianza más limpio.

Las desventajas son que los usuarios tienen más probabilidades de perder sus claves, lo que los desconectará, así como perder su identidad en línea, o peor aún, que les roben. El concepto de usar una clave en Internet es demasiado desconocido para la mayoría de los usuarios comunes, principalmente debido a una mala experiencia de usuario. En la autenticación de conocimiento cero, un usuario firma un fragmento de datos utilizando su clave privada y lo envía al servidor como prueba. El servidor recibe la prueba, ejecuta métodos criptográficos estándar sin estado para recuperarla. Esto significa que el usuario ya no necesita enviar un secreto al servidor para validar su identidad, y el servidor ya no necesita almacenar esta clase de información. Mejor experiencia de inicio de sesión. Aprendamos cómo Magic mejora la confianza hasta ahora, utilizando un modelo delegado. Magic aprovecha la gran Infraestructura como Servicio y claves de usuario seguras con módulos de seguridad de hardware, con tecnología que oculta y protege la clave privada del usuario de las empresas e incluso de Magic. Añade ventajas adicionales, como proporcionar una experiencia de autenticación sin contraseña familiar. Para que los usuarios recuperen sus claves, es una mejor experiencia de usuario y ya no pueden perder sus claves. Magic no almacena contraseñas y no puede conocer las claves o secretos del usuario, lo que permite una mayor confianza y seguridad, y tiene soporte nativo para múltiples blockchains.

Una desventaja es que depende de una única infraestructura como servicio. Y en la serie de soluciones novedosas, debemos tener una optimización de confianza no custodial. Por lo tanto, el DKM de Magic, que es la arquitectura de gestión delegada de claves, delega operaciones críticas de cifrado y descifrado a un AWS KMS y AWS Cognito de confianza, evitando por completo el backend de Magic. De esta manera, Magic se mantiene no custodial, ya que Magic nunca ve las claves privadas del usuario y, por lo tanto, ofrece una mejor seguridad y confianza tanto para los desarrolladores como para los usuarios finales. Esto nos permite tener una identidad soberana.

El primer obstáculo para un Internet más auténtico es la identidad. La identidad ha sido predominantemente controlada por proveedores de identidad centralizados. Los desarrolladores dependen completamente de estos proveedores para el acceso de los usuarios. Crear autenticación y seguridad desde cero es extremadamente desafiante para mantenerla segura, escalable y confiable, lo que está llevando a una gran cantidad de violaciones de datos y credenciales de usuario. Magic resuelve esto descentralizando la identidad. En lugar de que el proveedor de identidad centralizado firme tokens de autenticación, los usuarios son quienes firman los tokens de autenticación con su propia clave privada, lo que permite la identidad soberana.

Entonces, comprendamos la recapitulación de la solución novedosa, que consiste en lograr la identidad soberana utilizando la prueba de conocimiento cero, la gestión delegada de claves y la no custodia. Aprendamos cómo podríamos lograr esto en un ejemplo de aplicación de React. Este es un enlace de demostración. Cualquiera en el chat puede ver cómo se ve la demostración, lo que voy a mostrar visitando react-submit-magic.purrsel.app. Comenzaremos utilizando el NPX make magic scaffolding con una plantilla que hemos preparado para ti, que es Hello World React. Ejecútalo en tu terminal. Se te dará la bienvenida con esto. Solo necesitas crear un nombre de proyecto y te pedirá una clave de API publicable de Magic. Puedes obtener la tuya visitando magic.link y registrarte de forma gratuita.

Y visita el panel de control y crea una aplicación y copia la clave publicable de prueba. Luego pega esa clave aquí y elige tu cliente de NPM. Con el tiempo, tu aplicación estará lista y serás recibido con esta pantalla. Esto es lo que ves en la aplicación de demostración que es react-summit-magic.vercel.app.

Luego, simplemente ingresa tu ID de correo electrónico, lo cual habilitará una ventana emergente que dirá que revises tu correo electrónico, te enviará un enlace mágico a tu correo electrónico. En este momento, no cierres esta pestaña. Recibirás un correo electrónico de Magic con el nombre de tu aplicación y un botón para iniciar sesión. Y una vez que hayas terminado, serás recibido con tu estado de usuario actual que muestra tu ID de correo electrónico y un botón de cierre de sesión. Permíteme mostrarte cómo se ve en un React. En tu terminal, solo necesitas ejecutar eso, crear una aplicación, pegar aquí, elegir tu paquete de NPM. Y en cuestión de segundos, tu aplicación estará lista. Gracias a Mary-Chris por hacer este video rápido. También es una colega en Magic Labs. Y luego veamos qué nos ofrece el andamiaje de Magic CLI. Te brinda esta estructura de código en particular que tiene componentes como apps, callback, loading, login, profile y un archivo index y un archivo magic.js. También hay un archivo .env.

Todo sucede aquí. Puedes crear así o puedes tener un enfoque diferente que mostraré más adelante. Solo importa el SDK de Magic y pasa la clave publicable de Magic. Luego úsalo en el archivo app.js. Así es como lo usamos. Ejemplo usando inicio de sesión, callback y perfil. Puedes tener una mejor comprensión del código visitando este enlace. El archivo callback.js y aquí es donde intentamos iniciar sesión con las credenciales mágicas en la consulta de URL. Y esto es simplemente un estado de carga cuando esperamos que ocurra el inicio de sesión. Y aquí es donde ocurre todo, el archivo login.js que realiza acciones de inicio de sesión a través del flujo sin contraseña de Magic. Al completar con éxito el flujo de inicio de sesión, el usuario es redirigido a la página de inicio mediante history.push. Y luego hay una página de perfil que muestra los metadatos del usuario. Puedes tener una mejor comprensión del código visitando este enlace en GitHub.

Eso fue el inicio rápido de cómo podrías usar Magic y React, pero ¿qué tal implementar Magic en tu aplicación existente de React? Puedes hacerlo a través de la instalación del SDK de Magic mediante npm install Magic SDK o yarn add Magic SDK.

Ya sea, siempre se recomienda usar tus claves de entorno en el archivo .env, pero depende de ti cómo vas a usarlo. Una forma es usar el archivo Magic.js y tener todo ahí. La otra forma es tener todo en un solo archivo, algo como esto, que importa el SDK de Magic, pasa la clave publicable, y luego llama a Magic.auth.login con el enlace mágico y pasa el ID de correo electrónico. El correo electrónico que inicia sesión con el enlace mágico tiene varios parámetros, por ejemplo, correo electrónico, mostrar interfaz de usuario o redirigir interfaz de usuario. Así que depende de ti cómo vas a usar eso, pero la demostración tiene una URI de redirección. Así que una vez que hagas clic en el botón, lo que recibas en tu correo electrónico, iniciarás sesión desde ahí mismo.

Entonces, ¿cómo podrías usar DID y resolver el problema de autenticación sin usar el SDK de Magic? Entendamos qué es la identidad descentralizada. Una identidad descentralizada es un nuevo tipo de identificador que es globalmente único, resoluble y tiene disponibilidad y verificación criptográfica. Los tokens DID se utilizan como pruebas generadas criptográficamente que se utilizan para gestionar el acceso del usuario al servidor de recursos de tus aplicaciones.

Para la identidad soberana, que se puede definir como una identidad digital portátil de por vida que no depende de ninguna autoridad centralizada. Así es como se ve el formato DID, que tiene un esquema. Incluye DID y también tiene un método DID, que depende de leer, escribir, actualizar y eliminar según lo que desees realizar. También incluye, por ejemplo, UUID, que es el ID único. Y por último, tiene una cadena específica del método DID. Depende de los métodos DID que utilices. Visita este enlace para entender más sobre el formato DID.

Entendamos sobre los DIDT, que son los tokens de identidad descentralizada. Adaptando el protocolo DID del W3C, el token DID creado por el SDK cliente de Magic aprovecha la cadena de bloques de Ethereum y la criptografía elíptica para generar una prueba verificable de identidad y autorización. Las pruebas se codifican en una firma digital ligera. Esta firma digital ligera se puede compartir entre el cliente y el servidor para gestionar permisos, rutas protegidas y recursos o autenticar usuarios.

Así es como se vería la estructura típica de un código DID, que consta de una prueba y una afirmación. La prueba es una firma digital que demuestra la validez de una afirmación dada. Y la afirmación no es más que un dato que representa el acceso del usuario. Y la prueba está firmada con el método de firma personal de Ethereum. Visita este enlace para entender cómo funciona el enlace de firma personal de Ethereum. Y luego está la codificación de binario a ASCII desde la prueba y la afirmación. La especificación del token DID tiene sus claves, por ejemplo, fecha de emisión, marca de tiempo de caducidad, marca de tiempo no válida antes, emisor, sujeto, audiencia, y agrega una firma cifrada de datos serializados arbitrarios y luego un identificador de token único, que es algo como esto. Así es como generas un token DID, que es un pseudocódigo, que tiene IAT en este formato, tiempo de caducidad con la duración de vida, emisor, que es tu emisor, que utiliza el formato DID, que utiliza el DID y el método DID y la cadena especificada, luego el sujeto sería, qué sería el sujeto, y luego la audiencia y NF, NBF, que utiliza este formato y luego un identificador de token. Esto firma la afirmación con la clave privada del usuario, de esta manera la afirmación es verificable e imposible de falsificar. Y todo se codifica utilizando binario a ASCII.

Así es como generas un token DID. Espero que hayas aprendido mucho sobre cómo gestionar la identidad descentralizada. No se trata solo de construir tu DID y cómo lo construyes. Magic hace muchas cosas bajo el capó. Gestiona la clave de una manera muy única. Todos pueden generar un token DID, pero depende de cómo vayas a gestionarlo. Para aprender más sobre cómo Magic maneja su gestión de claves delegada, visita estos enlaces, así como aprende sobre Magic en la documentación de Magic y las guías de Magic. Estas son las formas en las que puedes conectarte conmigo. No dudes en contactarme si tienes alguna pregunta sobre cualquier tema, y compartiré el enlace de las diapositivas después de esta charla. Espero que hayas tenido un día maravilloso y que esta charla te haya dado una visión para pensar en el espacio de la identidad descentralizada. Adiós, que tengas un buen día. Adiós.