0 a Auth en una Hora Usando NodeJS SDK

Permíteme comenzar presentándome. Mi nombre es Asaf. Soy ingeniero de software en Dscope. Dscope es una plataforma de autenticación que ayuda a todos los desarrolladores a facilitar la autenticación de manera segura. En el próximo taller, vamos a agregar una autenticación sin contraseña a una aplicación estándar de Node. Comenzaremos revisando algunos conceptos básicos de autenticación y repasaremos las fallas que vamos a agregar. Esto es como un trasfondo y conocimiento que necesitamos adquirir para incorporar la autenticación correctamente. Esto probablemente tomará unos 15 minutos y en el resto del tiempo, vamos a tomar una aplicación existente y agregarle la capa de autenticación. Si te preguntas qué hay para ti en este taller. Creo que al final del taller, tendrás una mejor comprensión del flujo de autenticación. Esto es algo que puede parecer un poco intimidante al principio, pero creo que es bastante simple si lo revisas bien. Y tal vez más importante, creo que podrás tomar una aplicación estándar y agregarle autenticación. Si tienes cualquier aplicación de Node, puedes tomarla y agregar autenticación en unos pocos pasos. Como dije antes, comenzamos con el concepto principal y luego pasaremos a la codificación y daré más información al respecto más adelante. Hola a la persona que escribió en el chat. También estoy muy emocionado. Voy a asumir que tienes un conocimiento básico de Node y el framework Express. La aplicación está escrita en TypeScript. Así que, probablemente si también conoces JavaScript, es suficiente. No usamos mucho TypeScript, pero la aplicación de Node estará escrita en TypeScript. Además, solo para prepararnos para la sesión de codificación, si quieres hacerlo por tu cuenta, debes tener una cuenta de GitHub, cualquier IDE que elijas para codificar y Node versión 18 o superior. Esto depende de ti, pero por supuesto, lo haré aquí, así que esto es opcional.

Comencemos cubriendo el concepto muy básico. Entonces, ¿qué es la autenticación? ¿Qué es la autenticación? La forma en que lo veo, el proceso de autenticación es básicamente verificar la identidad de alguien. Internet es un lugar muy distribuido, por lo que si alguien en otra máquina dice que es alguien, ya sea un usuario, un sistema o un dispositivo, básicamente tienen que demostrarlo antes de querer acceder a la aplicación, a un recurso específico de la aplicación o al sistema. Este es un aspecto muy, muy esencial de la seguridad de la aplicación. Y esto es, usamos la capa de autenticación básicamente para proteger nuestro sistema de accesos no autorizados. Y esto es algo que es súper importante en la era digital. Hay tantas violaciones de datos, robos de identidad en el mundo. Realizar una autenticación adecuada es crucial para la seguridad de tu aplicación.

Y cada vez escuchamos más incidentes de acceso no autorizado. Y si queremos desarrollar una aplicación segura, debemos invertir en ella. Solo como una nota aparte, tenemos un centro de aprendizaje muy bueno con muchos recursos gráficos allí. A veces vuelvo allí y refresco mi memoria. Y hay un enlace en la presentación que también se mostrará.

Entonces, ¿qué vamos a construir? Y esto está más relacionado con los flujos que queremos agregar. Si desglosamos las partes de los pasos de la autenticación, básicamente podemos dividirlo en dos pasos principales. El primer paso es cuando el usuario desea acceder al recurso o la aplicación por primera vez, debe autenticarse. Por lo general, comienza cuando el usuario desea acceder al recurso. Envía algún tipo de solicitud de acceso. El usuario generalmente proporciona su identidad. Esto puede ser básicamente un correo electrónico, un nombre de usuario. Número de teléfono móvil, identificación de seguridad social o ¿qué? Esto es muy específico de la aplicación. Y una prueba generalmente es algo que básicamente demuestra quién eres.

Hay algunos factores de prueba de autenticación que generalmente se llaman factores. Un factor de autenticación se basa en algo que sabes, por ejemplo, una contraseña o tal vez una pregunta de seguridad. Por cierto, un consejo rápido en la pregunta de seguridad, generalmente si te importa la seguridad, no respondas con información real porque generalmente esto es algo muy fácil de obtener, como el nombre de tu mascota, etc. Otro factor de autenticación es algo que tienes, un ejemplo muy común de esto es un dispositivo móvil. Entonces, si te envío un SMS con un código y luego me devuelves el código, puedo decir que esto es básicamente una prueba de que tienes un dispositivo móvil. Y también algo que eres o algo que heredas. Este es un factor relativamente nuevo de información biométrica, ya sea con una huella digital o reconocimiento facial. También he oído hablar de soluciones que escanean la retina y cosas así. ¿Alguien tiene alguna idea o ha oído hablar de más factores de autenticación que los tres que mencionamos? Algo que sabes, algo que tienes, algo que eres.

Así como, y solo para compartir desde nuestra experiencia, hay factores algo nuevos de un factor geográfico. Entonces, básicamente, si inicias sesión desde una ubicación geográfica determinada, esto es algo que generalmente te hace sospechoso o no sospechoso. Si has oído hablar de un escenario de viajero imposible cuando un mismo usuario accede a la misma aplicación desde ambas ubicaciones, básicamente una persona no puede cambiar la ubicación en esa cantidad de tiempo. Y otro es el factor de comportamiento. Básicamente, si te comportas de una manera que no te corresponde, como acceder a resultados a los que no estás acostumbrado o la velocidad, este es otro factor. Entonces, básicamente, después de que la aplicación obtiene la prueba y la identidad, se verifica, básicamente se verifica que coincidan. Y luego la aplicación otorga al usuario acceso. Este acceso generalmente se otorga en forma de una sesión o un token.

Lo veremos muy pronto. Y por lo general, este token o sesión se utiliza en las solicitudes siguientes. Esto se hace para que el usuario no tenga que proporcionar todas las pruebas en cada solicitud. Por lo general, te autenticas una vez, obtienes un token o una sesión y lo usas durante un cierto período de tiempo. Y la parte de verificación después de obtener una sesión, por lo general, proporcionas esta sesión o token y la aplicación solo necesita validarla.

Entonces, si hablamos de la gestión de sesiones, hablamos de sesión versus token, hay dos procesos técnicos para implementar esto. Uno es usar una sesión en el lado del servidor y el otro es usar un token en el lado del cliente. Una sesión generalmente significa que el servidor almacena su información de sesión en una base de datos y proporciona un identificador al cliente y en las solicitudes siguientes se utiliza este ID de sesión para recuperar la información de sesión de la base de datos. La sesión en el lado del servidor generalmente es muy segura, el servidor, que es un lugar seguro, tiene un control total sobre ella. Por ejemplo, si quieres revocar una sesión, es algo que es relativamente sencillo de hacer en una sesión en el lado del servidor, y por otro lado, están los tokens en el lado del cliente. Creo que alguien en el chat mencionó antes los JWT. Los JWT son básicamente el acrónimo de JSON Web Tokens, y esto es un JSON que contiene información sobre quién eres, y se firma de manera asimétrica con una clave privada en el backend, en el servidor, y el token en sí, todo el token se envía al cliente y en las solicitudes siguientes, el JWT se valida básicamente y su información se utiliza para determinar, básicamente el servidor o la aplicación pueden utilizar para determinar información sobre el usuario. ¿Alguien puede compartir cuáles creen que son las ventajas de los tokens en el lado del cliente, tokens, JWTs? Vale, compartiré que básicamente todas todas las aplicaciones modernas prefieren usar un JWT por razones de escalabilidad. Y, básicamente, si hablamos de una arquitectura de microservicios, no necesitas tener un único punto de acceso para acceder, por ejemplo, a una base de datos, y el rendimiento de validar un JWT es algo que es relativamente barato de calcular en comparación con acceder a una entidad de base de datos. Y esto es básicamente, creo que Kevin también mencionó que no tienes que almacenar la sesión en el servidor, y esto es absolutamente cierto. Vale, una última cosa antes de pasar a la sesión de codificación, describamos la aplicación que vamos a construir. El propósito de la aplicación, la mostraré rápidamente en un minuto, es básicamente mostrar al usuario algún tipo de ingreso financiero sobre el cliente de la organización. No importa realmente, pero lo importante es que muestra contiene un recurso y queremos proteger este recurso con una capa de autenticación. La aplicación está compuesta por una aplicación de escritorio, una aplicación web, en React.js. No vamos a dedicar tiempo al código, pero si quieres, puedes ir al repositorio de código abierto y echar un vistazo. El servidor de aplicaciones Node.js, esto es lo que sirve la información al cliente. Vamos a utilizar un servidor Express muy simple. Y otro componente es el servicio de autenticación. Por lo general, este es un servicio externo que gestiona la identidad del usuario y la autenticación. Por lo general, la aplicación se comunica con el servicio de autenticación mediante una biblioteca SDK. En este taller, vamos a utilizar este código como el servicio de autenticación. Vale. Antes de empezar, unas palabras sobre mí. Mi nombre es Asaf, como dije antes. A partir de este código, este código es una plataforma de autenticación que ayuda a todos los desarrolladores a construir seguridad, seguridad y autenticación sin fricciones y a construir experiencias de usuario para aplicaciones B2B, B2C.

De acuerdo, sin más preámbulos, comencemos. Vamos a utilizar el siguiente repositorio. Este es un repositorio en la organización Scope SampleApp. Si hay alguna pregunta, no dudes en interrumpirme ahora o escribir en el chat. Voy a compartir el enlace en, oh, gracias Chris por compartir el enlace. Y ahora, voy a repasar los pasos que describimos antes. Básicamente, creo que tengo la aplicación en ejecución. De acuerdo. Ya he clonado un repositorio en mi computadora. Siéntete libre de copiar, clonar este repositorio en tu máquina. Puedes usar la rama principal. ¿De acuerdo? Pero ya he construido las ramas del frontend. Veamos todas las ramas. Como, vamos a comenzar con la masterclass 01. Y luego, a partir de ahí, vamos a progresar. Voy a mostrar cada paso para agregar otra parte de la autenticación en los siguientes pasos. Puedes decidir si quieres codificarlo, o simplemente escucharme y repasar los pasos más tarde. Voy a usar las ramas para mostrar el progreso. Así que, comencemos. Ya he clonado. Puedes hacer NPM install. Esto instalará todas las dependencias, y si quieres ver la aplicación en ejecución, simplemente ejecuta npm run dev. Esto abrirá una aplicación básica. El frontend está en React. El

Entonces, creo que ahora es un buen momento para la parte principal y la parte importante sobre la autenticación es básicamente proteger esos resultados. Ahora mismo, hemos completado la primera parte de autenticar al usuario. El usuario está autenticado, pero aún no hemos verificado que el usuario esté verificado. Entonces, lo que queremos hacer ahora es agregar un middleware delante de todas esas rutas que se asegurará de que el usuario esté autenticado. Veamos cómo se ve. Entonces, agregamos el siguiente código. Aquí tenemos una función. Este es un middleware de express, y lo cubriremos en un momento, y hemos creado el DedicateRouter. El enrutador, ejecutaremos el middleware antes de cada solicitud, y cambiamos todas las API que queremos proteger que queremos proteger para que se ejecuten en este enrutador específico. Veamos qué hace este middleware. Básicamente, este middleware toma la solicitud y la respuesta y qué se debe ejecutar después. El middleware puede decidir si ejecutar la siguiente función, que en este caso es la función que devuelve los datos, o no. Veamos qué hace el middleware. Lo primero que hace es analizar las cookies. Las cookies están en la solicitud. Las configuramos en pasos anteriores, por lo que podemos ver básicamente un código muy simple que toma la solicitud, toma la cookie y la descompone. Lo escribí aquí en código simple para que podamos ver qué sucede internamente, pero hay muchos paquetes dedicados para estos propósitos, por ejemplo, CookieJS y otras bibliotecas de Javascript que pueden hacerlo por ti. Luego extraemos el token de actualización y de sesión y utilizamos la autenticación del cliente, el SDK para validar la sesión. Lo que hará esta acción es tomar la sesión y asegurarse de que la firma coincida con la información del JWT. Si no has visto JWT antes, contiene tres partes que están codificadas en Base64. La primera parte contiene metadatos sobre qué algoritmo usar y otra información sobre el token. La parte central contiene la información sobre el usuario, el ID del usuario y tal vez cosas como roles y otra información personalizada. Y la última parte es la firma. Entonces, lo que hará esta parte es validar que la firma coincida con lo que el usuario dice que es. Y si esta parte básicamente tiene éxito, creamos el contexto de la solicitud. Por cierto, aquí arriba declaramos cómo debería verse el contexto

Intentamos actualizar la sesión. Si la actualización falla, devolvemos una respuesta no autorizada. Y si la actualización tiene éxito, queremos establecer cookies de autenticación como lo hemos hecho en la autenticación porque queremos comunicar al usuario con el nuevo token de sesión. Y eso es todo. Nuevamente, este token de actualización es este middleware de autenticación que se ejecuta antes de cada solicitud. Veámoslo en vivo. De acuerdo, voy a actualizar la página. Y podemos ver que todavía estamos obteniendo la información. También quiero ir a incógnito, y ver qué sucede cuando enviamos una solicitud aquí. Podemos ver que obtenemos un 401. La razón es porque las cookies no se mantienen entre la ventana de incógnito, podemos ver que no tenemos ninguna cookie aquí. Y debido a que no hemos enviado la autenticación, no hemos enviado la información de notificación, todas las solicitudes fallaron. Veo que hay una pregunta en el chat. ¿Y la validación de Jot también verifica que el token de acceso Jot haya caducado? Esta es una muy buena pregunta. Sí, la función del SDK que vimos aquí también valida que la sesión sea válida y no haya caducado.

En cada sesión, podemos echar un vistazo aquí. Vamos a echar un vistazo aquí a la sesión. Voy a copiarlo. Hay un buen sitio web llamado Jot.io. Y puedes ver que son las tres partes que hemos discutido antes. Metadatos, los encabezados del JOT. Esta es la carga útil, contiene, básicamente, el emisor, este es el ID del proyecto, en el ámbito. Este es el ID del usuario y puede haber más metadatos en esto, y la tercera parte que vemos en azul es la firma. También puedes ver que una parte de la carga útil es cuando expira. Por ejemplo, este token expiró hace aproximadamente dos minutos, si no me equivoco.

De acuerdo. Aquí hay otra pregunta. Entonces, la validación de la sesión está a punto de generar un nuevo token de acceso una vez que haya expirado. Así que para la segunda pregunta, la validación de la sesión no lo hace sola. Para este propósito, hemos creado una actualización. Si la validación de la sesión falla, enviamos una solicitud de actualización para obtener una nueva sesión. Por cierto, el SDK también admite, lo siento, validar y actualizar la sesión en la misma parte. Básicamente encapsula las partes que hemos visto aquí por ti. Omkar, adelante. Desactiva el silencio. En la función de validación de sesión, ¿simplemente valida el token JWT o hace una llamada al servidor de autenticación para validar el token? Entonces, para los tokens JWT generalmente se validan, no se validan en el backend, pero la forma en que se hace, la validación se realiza descargando una clave pública. La forma en que se construye JWT es con una clave privada y se genera con una clave privada y se valida con una clave pública. Lo que hace la API en el fondo es descargar una vez públicamente y la utiliza para verificar la firma del token. Espero que eso responda la pregunta. Básicamente, la descarga de la clave pública se realiza una vez. Hay un protocolo sobre cómo verificar JWT, un tema muy interesante. Hay otros aspectos, tal vez podamos verlo aquí. Por lo general, hay otra información sobre el JWT, como cuál es el ID de clave, porque generalmente el proveedor de servicios, el ámbito también lo hace. Rota las claves públicas por razones de seguridad. Así que cada clave pública se descarga una vez. De acuerdo, entendido. Gracias.

Sí. Y otra pregunta es si Validar y Actualizar también reescribe las cookies que se envían al cliente. Así que Validar y Actualizar también devuelve cookies. Y cuando creamos esta sesión, como divulgación completa, cuando creamos esta sesión, descubrimos que hay algunas brechas en la funcionalidad de Validar y Actualizar. Esta es una de las razones por las que estoy demostrando esto de esta manera. Pero sí, idealmente, Validar y Actualizar hará todo este trabajo por ti, y devolverá las cookies, y luego podrás tomar las cookies y ponerlas en la solicitud del usuario. Permíteme continuar.

De acuerdo, ¿alguna pregunta sobre lo que hemos hecho hasta ahora? En el token JWT, mencionaste que el token JWT se crea utilizando la clave privada y luego se valida utilizando la clave pública. ¿Entonces el servidor almacena la clave pública en memoria o con ella? Sí, el SDK básicamente, este objeto client auth, este es el SDK. Lo almacena internamente en la memoria. Solo para reiterar las primeras dos cosas, esta clave pública no es secreta, cualquier persona puede acceder a ella. Y su único propósito es validar que la firma del JWT coincida con la información que el usuario, que está en el payload. Esto básicamente demuestra que el JWT fue generado con la clave privada correspondiente. Wow. Y lo otro que quiero mencionar es que esta clave pública es muy liviana y no afecta el rendimiento de la aplicación. Es muy baja.

De acuerdo, otra pregunta. ¿Qué es diferente? Aquí, con OAuth, tenemos un servicio de identidad externo y la generación del token. Entonces, esta es una muy buena pregunta. Básicamente, está relacionado con el propósito de OAuth. Y OAuth no... La salida del inicio de sesión social es solo para generar el código. El código, esto es básicamente algo que se mueve hacia las identidades. En OAuth, OAuth es un protocolo vasto, pero básicamente, además del usuario, está el proveedor de servicios, que es la aplicación que tenemos aquí. Perdón, esta es la aplicación que tenemos aquí, y el proveedor de identidad. El proveedor de identidad, en este caso, es Google. Entonces, la aplicación lleva al usuario al proveedor de identidad, obtiene el código y la responsabilidad de generar el JOT sigue en el proveedor de servicios, que en este caso es la aplicación Node que tenemos. Creo que si quieres leer un poco más sobre OAuth, tenemos muy buenos artículos en el blog de Dscope. Así que recomendaría leer más al respecto allí. En el minuto que tengo antes de responder más preguntas, quiero presentar un enfoque diferente a lo que hemos hecho aquí. Hasta ahora, vimos un enfoque en el que la autenticación se realiza directamente desde el servidor de la aplicación hacia el servicio de autenticación. Hay otro enfoque que creemos que es un poco más flexible y simple de incorporar, que se realiza desde el frontend directamente hacia el servicio de autenticación. Entonces puedes ver que eliminé todos los métodos de autenticación , el OTP y el OAuth. Me quedé con un middleware muy, muy mínimo que solo hace la validación y todo el trabajo de mostrar los formularios y gestionar los tokens se hace con el frontend. No voy a cubrirlo demasiado porque esto se hace básicamente en React. Esto no es el alcance de esta masterclass. Pero el resumen de esto es que básicamente agregamos el SDK de React en el lado del frontend. Envolvemos la aplicación en un proveedor de autenticación. Y luego, en lugar de los flujos, lo siento, en lugar de los formularios que vimos antes, simplemente agregamos un componente de alcance mínimo. Y este componente básicamente controla todo. Creo que olvidé instalar la aplicación de React. De acuerdo. Entonces este formulario es completamente sin código. Puedes ir básicamente, a la aplicación de alcance y ir a la página de flujos y controlar las pantallas y los flujos de autenticación directamente desde aquí. Esta es la pantalla que vemos aquí en la aplicación. Es muy fácil de incrustar.

Y puedes controlar los métodos de autenticación que deseas agregar en la interfaz de alcance. Creemos que esta forma es mucho más flexible y sencilla de hacer. Por ejemplo, si deseas agregar otro método de autenticación, como la biometría, todo lo que necesito hacer es agregar aquí, por ejemplo, un botón de biometría. Esta interfaz es altamente personalizable. Por ejemplo, puedo tener un control completo sobre el diseño de la aplicación y puedo agregar otro paso aquí de biometría, ¿de acuerdo? Por ejemplo, registrarse o iniciar sesión usando biometría, conectado con una experiencia de arrastrar y soltar muy sencilla. Y una vez que presiono guardar, puedo ver los cambios aquí. Esto es algo que ahora, por ejemplo, puedo usar para autenticarme y esto es, no tuve que cambiar nada en el frontend o en el backend. La autenticación funcionará de la misma manera.

Creo que esto es lo que tengo que mostrar en la masterclass. Estoy disponible para preguntas aquí. Y antes de eso, quiero dar las gracias. Muchas gracias a todos, a los participantes. Fue un placer conocerlos.

Hola, lo que estabas describiendo la última vez era que hay una forma de que la aplicación frontend tome el token directamente del servidor de identidad o el código, y ese código será el código de seguridad que se utilizará para comunicarse de forma segura con el backend. Ese código se validará desde el backend hacia el servidor de identidad. Cuando hablo aquí de servidor de identidad, me refiero a una entidad que no forma parte del servidor que estamos utilizando. Puede ser Google, puede ser Amazon, puede ser otra entidad, ¿verdad?

Correcto. Te refieres al flujo de OAuth, ¿verdad?

Sí, exactamente. Correcto, tienes razón. El protocolo OAuth redirige al usuario al proveedor de identidad en este caso, Google. El proveedor de identidad en este caso es Google. Realizas la autenticación con Google. Google, a su vez, lleva al usuario, permíteme mostrarlo en el código, lleva al usuario de vuelta al proveedor de identidad, una URL directa con el código como parámetro de consulta. Y la aplicación toma este código, lo valida contra Google. Y si la validación contra Google tiene éxito, generará un token de sesión. Espero que esto responda la pregunta.

Sí. Muchas gracias por aclarar todas mis preguntas.

No hay problema, fue un placer. Otra pregunta sobre Jot Auth.

¿Cómo almacenar una clave pública si estás utilizando múltiples instancias del servidor o un servidor sin estado? Esto es algo de lo que no tienes que preocuparte. Es completamente transparente para ti. Solo necesitas llamar a la validación de sesión y la validación de sesión se encargará automáticamente... Básicamente, esto es lo que hará. Tomemos un ejemplo de una sesión aquí y vayamos a JotIO, ¿de acuerdo? Tomará el ID de clave del encabezado y descargará el ID de clave y el emisor y el ID de clave y lo descargará desde el servicio de identidad. Descargará... Perdón, desde el servicio de autenticación, descargará la clave pública correspondiente. Así es como se hace. No necesitas preocuparte por almacenarla o gestionarla. El SDK lo hace automáticamente. Y esto no está vinculado a ninguna instancia específica. Se puede hacer desde una función sin servidor sin ningún problema. Genial, una vez más, quiero dar las gracias a todos. Fue un placer y nos vemos la próxima vez.