Pero, pero, pero auT es haaRrRrRrRrRd

No, no lo es. Es aburrido, burocrático, un problema resuelto... pero no lo llames difícil como una afirmación general.

Tengo años de "usar MD5 para codificar contraseñas en PHP". Claro, era una idea horrible, incluso en 2012. Pero, en ese entonces, no recuerdo haber considerado la autenticación "difícil". Era una tarea bastante sencilla en sí misma: obtener un correo electrónico o un nombre de usuario, obtener una contraseña, codificarla (con MD5, como "dios lo quiso") y, si eras especialmente consciente de la seguridad, [ agregar sal ] a la contraseña. Almacenar todo eso en algún lugar, generalmente en una base de datos. Ta-da, registro hecho.

Hoy en día, la narrativa ha cambiado. "La autenticación es difícil" parece una narrativa omnipresente que se encuentra a un clic de distancia en HackerNews o Reddit. Pero, ¿realmente lo es? En mi opinión, la verdad es que la autenticación no es difícil de crear: cualquiera puede aprenderla (y todos en esta línea de trabajo deberían aprender los conceptos básicos). El verdadero desafío radica en los extras: MFA, administración de usuarios, restablecimiento de contraseñas, cada uno de los cientos de proveedores de OAuth y fusiones de cuentas de diferentes proveedores. Es una muerte por mil cortes. Dado que la autenticación es un problema resuelto, reinventar la rueda no es el mejor uso de su tiempo. Pero eso no significa que "la autenticación es difícil" como una afirmación general sea correcta o incluso cercana a ser correcta. Debe experimentar, comprender los conceptos básicos y desarrollar a partir de allí. La complejidad solo aumenta con la escala (o escala potencial) de lo que está creando.

Entonces, ¿qué tan difícil puede ser realmente la autenticación? Profundicemos en ello.

En los tiempos de antaño...

Continuando donde dejé la historia sobre PHP y md5, construir una funcionalidad de inicio de sesión siguió un conjunto similar de pasos: obtener un correo electrónico y una contraseña, verificar la existencia del correo electrónico en su almacenamiento, hacer un hash de la contraseña junto con la sal almacenada para ese correo electrónico, comparar el hash resultante con el almacenado en la base de datos y, si todo funciona bien, configurar una cookie a través de setcookie (todavía estamos en el mundo de PHP aquí, no es que la lógica general fuera demasiado diferente en otros ecosistemas).

Cerrar sesión era aún más sencillo: bastaba con invalidar la cookie en el servidor y listo. Si el servidor no ve una cookie en la siguiente solicitud, no se inicia sesión. Por lo tanto, realizar rutas autenticadas también fue una tarea sencilla en general. Las cosas podían complicarse cuando se trataba de permisos, pero la mayoría de las veces, con las aplicaciones que tenía que crear, solo teníamos administradores y usuarios. Esto era algo que simplemente se podía almacenar junto con el registro de usuario o en una tabla de permisos si alguna vez necesitabas ampliar la cantidad de roles que tenías para tu aplicación.

Divulgación total: trabajo para SuperTokens . Sin embargo, este artículo surge de mi frustración personal por la omnipresente narrativa sobre lo difícil que es la autenticación como una declaración general. En otras palabras, no estoy tratando de "venderte mi producto". Usa lo que quieras.

Arma tu propio whisky: una versión "moderna"

Correo electrónico/contraseña y autenticación social

Para llegar a donde estamos hoy, empezaremos por el principio... Sorprendente, lo sé. Probablemente podamos estar de acuerdo en que estos componentes son suficientes para crear una prueba de concepto con correo electrónico/contraseña + inicio de sesión con redes sociales:

1. Un servidor que maneja rutas: registro, inicio de sesión, cierre de sesión...
2. Algún tipo de almacenamiento para mantener los registros del usuario (una matriz en memoria también funciona)
3. Vistas: inicio de sesión, registro y pantallas de "panel de control" autenticadas.
4. Controladores para autenticación social

Si nos basamos en Express y Passport, como no vamos a reinventar la rueda, llegamos exactamente a 150 líneas de código muy, muy aburrido y repetitivo: https://github.com/supertokens/auth-express/blob/master/index.mjs . La siguiente sección será una explicación superficial de lo que sucede en el código, así que siéntete libre de saltarte este paso si ya estás familiarizado con los conceptos. La aplicación Express es una PoC de todos modos.

Vamos a diseccionarlo rápidamente:

Representar cosas en la pantalla

En mi opinión, hay dos formas de abordar esto: comenzar con la representación y pasar a la ruta de autenticación o al revés. En gran parte por casualidad, terminé siendo un experto en FE (todavía puedo hacer SQL, en caso de que te lo estés preguntando), así que comenzaré con el enfoque de "representar cosas en pantalla".

Dado que se trata de una prueba de concepto, no vamos a utilizar React como si fuera una versión sofisticada. El SSR simple con ejs funcionará bien: https://github.com/supertokens/auth-express/tree/master/views

Agregar rutas

Basándonos en algunos ejemplos de passport.js , pero simplificados aún más, necesitamos lo siguiente:

1. Algunas dependencias: npm i passport passport-local express-session . Repasemos brevemente cada una de ellas:

   1. Passport.js : el middleware de autenticación original para Express y Node.
   2. passport-local : una estrategia de autenticación para Passport; una estrategia de autenticación en un módulo que maneja el proceso de autenticación para un método de autenticación específico; en este caso, un inicio de sesión local utilizando un nombre de usuario (correo electrónico) y una contraseña.
   3. express-session : middleware que administra los datos de sesión y permite almacenar y conservar las sesiones de usuario entre solicitudes HTTP. Funciona asignando un ID de sesión único a cada cliente, que se almacena en una cookie en el lado del cliente y se utiliza para recuperar los datos de la sesión en el servidor.

2. Un lugar para almacenar a nuestros usuarios (el ejemplo vinculado arriba usa una matriz en memoria): https://github.com/supertokens/auth-express/blob/master/index.mjs#L13

3. Configuración para nuestra instancia de pasaporte y nuestra instancia de LocalStrategy para manejar solicitudes entrantes de búsqueda de usuarios: https://github.com/supertokens/auth-express/blob/master/index.mjs#L18

4. Inicialice el pasaporte ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L60 ) y la sesión rápida ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L69 ).

Verbosa, seguro. ¿Difícil? No lo creo, al menos no en el sentido de implementarlo como un juguete. Pero hace un tiempo que dejamos de usar combinaciones de correo electrónico y contraseña. Veamos lo difícil que es agregar un proveedor de redes sociales a lo que ya tenemos.

Como proveedor de ejemplo, decidí utilizar GitHub por una sencilla razón: si decides seguirlo en su totalidad, es uno de los proveedores con los que es más fácil comenzar (te estoy mirando a ti, Google).

Si decides seguirlo completamente, aquí hay un enlace que describe cómo obtener esas claves de GitHub: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app Ah, y por cierto, las que están en el repositorio no son válidas, en caso de que estuvieras preocupado ;)

Integración de GitHub OAuth2 en nuestra PoC

En primer lugar, necesitamos una dependencia más, npm i passport-github2 . passport-github2 es una estrategia de autenticación para Passport, que nos permite integrarnos con la API OAuth2 de GitHub.

Después de algunos controladores ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L122-L133 ) y configuraciones ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L29-L45 ), bueno, eso es todo. ¿Complicado? Probablemente no. ¿Burbujas? Seguro. ¿Aburrido? Absolutamente. Especialmente si puedes hacerlo una y otra vez. Es un problema resuelto; reinventar la rueda no suele ser el mejor uso del tiempo, como hemos establecido.

La gran idea

A esta altura, probablemente podamos estar de acuerdo en que Auth no es difícil de crear . Por lo tanto, no es algo mágico que solo los magos de barba blanca que hablan el lenguaje místico de los JWT pueden entender e implementar.

No, de hecho, yo diría que, como desarrollador, uno debería comprender los conceptos básicos de cómo funciona la autenticación. Y a menudo veo una narrativa que afirma lo contrario, algo así como "confía en mí, hermano, podemos encargarnos de eso por ti". Y, claro, estoy de acuerdo en que, en su mayor parte, crear tu propia autenticación es una pérdida de tiempo. Pero no es tan difícil de crear y, sin duda, no es algo místico. Donde realmente se complica es con todo lo que rodea a la autenticación y la experiencia del usuario.

Piense en esto: en el ejemplo anterior, tenemos una autenticación que funciona. Más o menos. Pero esto es lo que no puede hacer (también se menciona en la introducción del artículo):

• Autenticado en dos pasos, autenticación multifactor
• Restablecimiento de contraseña
• Todos y cada uno de los cientos de proveedores OAuth con su especificidad
• Gestión de usuarios
• Fusiones de cuentas de diferentes proveedores
• Cubrir todos los posibles casos extremos y posibles agujeros de seguridad.
• ...y puedo continuar

Probablemente podamos implementar cada una de estas cosas. Y, por sí sola, cada parte puede considerarse simple, pero se va sumando. Por lo tanto, no se trata necesariamente de la implementación, sino de su mantenimiento, de ser responsable de ella, de mantenerse al día con los estándares, las violaciones de seguridad, etc. Además, levanten la mano: ¿a cuántos de ustedes les gusta leer las solicitudes de comentarios? No creo que vea muchas manos levantadas si estuviéramos en una reunión.

Lo que quiero decir es que la autenticación no es fácil, en su conjunto. Claro, podemos improvisar algo fácilmente para una prueba de concepto, como hicimos anteriormente, pero no es mágico, no es imposible de entender y, por favor, no digan que lo es. Esa línea de pensamiento (y marketing), en mi opinión, es perjudicial para la industria en su conjunto.

Entonces, la pregunta natural que sigue sería: ¿cuándo deberías armar tu propio cigarrillo?

Proyecto de juguetes, actividades independientes y educativas.

...por supuesto. Incluso lo recomendaría. Se aprende mucho con la práctica, así que ¿por qué no? Si tu proyecto o blog independiente o de juguetes crece hasta tener una base de usuarios o seguidores considerable, cámbialo por un servicio, una solución alojada por ti mismo o algo más. Después de todo, en ese momento tienes un producto y, sin duda, tu tiempo se empleará mejor en desarrollar ese producto en lugar de en mantener la autenticación.

Empresas emergentes

En general, si estás creando productos, no crees tu propia autenticación. Es como reinventar una rueda muy aburrida y burocrática. Tienes muchas opciones para elegir. Además, estás creando algo, ¿no? ¿Por qué estamos teniendo esta conversación si tu producto no es de autenticación?

Empresas de escala y superiores (como sea que elijamos definirlas)

No lo hagas. Por la misma razón que con las empresas emergentes, pero sin duda se aplica más en este caso.

Probablemente puedas entender a dónde quiero llegar con esto. "La autenticación es difícil" es, diría yo, un discurso de marketing cuando se utiliza como una declaración general. Puedes entender la autenticación, puedes crearla, pero es aburrida, no es divertido mantenerla y es un problema que ya está resuelto. Por lo tanto, se puede considerar un producto básico, uno que puedes elegir en cualquier versión que elijas (algunas opciones a continuación).

El panorama de FOSS y alojamiento propio

Para aquellos que desean tener su propia pila (como yo), también tienen muchas opciones para elegir:

Bibliotecas de autenticación

• Passport.js, explicado en detalle anteriormente
• Lucia : una biblioteca de autenticación simple y flexible para aplicaciones web modernas, centrada en la experiencia del desarrollador y la facilidad de uso.
• Auth.js : una biblioteca de autenticación liviana y personalizable para Node.js, diseñada para integrarse fácilmente en varios marcos y aplicaciones. Comenzó como una biblioteca para Next.

Servidores de autenticación

• Keycloak : un servidor de gestión de acceso e identidad de código abierto que ofrece funciones como inicio de sesión único (SSO), intermediación de identidad y federación de usuarios.
• SuperTokens (ver descargo de responsabilidad más arriba): una solución de autenticación de código abierto que ofrece funciones prediseñadas como gestión de sesiones, inicio de sesión social y autenticación de correo electrónico/contraseña con un enfoque en la seguridad y la simplicidad.
• FusionAuth : una plataforma de autenticación flexible dirigida a desarrolladores, que ofrece funciones como gestión de usuarios, autenticación multifactor (MFA) e inicio de sesión único (SSO).
• Authelia : un servidor de autenticación de código abierto que proporciona autenticación multifactor (MFA) y SSO, diseñado para proteger aplicaciones mediante servidores proxy inversos.

Almacenamiento + Autenticación

• Supabase : una plataforma back-end-as-a-service (BaaS) de código abierto que ofrece bases de datos, autenticación y capacidades en tiempo real, diseñada como una alternativa a Firebase.
• Pocketbase : una solución de backend de código abierto que combina bases de datos, autenticación y almacenamiento de archivos, destinada a simplificar el desarrollo de aplicaciones web y móviles modernas.

Entonces, incluso si no te interesa usar software de terceros para autenticación, puedes elegir uno de código abierto disponible en el mercado, según tus necesidades y preferencias, y seguir adelante.

La moraleja: la autenticación es la "burocracia" del desarrollo

Mi "gran" mensaje es que hay que evitar reinventar la rueda, especialmente si se trata de un problema resuelto, como es el caso de la autora. Hay que informarse sobre las ruedas, experimentar con ellas, construir una rueda de juguete y comprenderla. Pero, por favor, no hay que venderla como algo imposible de entender y construir. Hay que educar, no limitar las posibilidades.