Passport.js

Qué es Passport.js y cómo funciona

Passport.js es un middleware de autenticación open source para Node.js, creado originalmente por Jared Hanson y ahora mantenido por una pequeña comunidad. Está integrado o referenciado por la mayoría de los principales frameworks de Node.js (Express, wrappers de Fastify, módulo Passport de NestJS). Su fortaleza es el patrón de estrategias: cada mecanismo de autenticación se implementa como un plugin (passport-local, passport-google-oauth20, passport-saml, passport-jwt, etc.), y el código de la aplicación permanece igual sea cual sea el proveedor habilitado.

Datos y cookies que maneja Passport.js

Passport.js no establece cookies por sí mismo. Las cookies de sesión las gestiona el middleware de sesiones (express-session, fastify-session o similar) y se almacenan en el lado cliente (cookie firmada) o en el servidor (Redis, Memcached, base de datos). Passport trata los datos que la estrategia escogida le devuelve, que pueden incluir tokens OAuth, el perfil del usuario (nombre, correo, a veces teléfono, URL de avatar), el ID de usuario del proveedor y los scopes personalizados solicitados. La biblioteca no contacta con terceros ni comparte datos.

Implicaciones del RGPD

Como Passport.js es una biblioteca que se ejecuta en la infraestructura del editor, el editor es el único responsable del tratamiento para la autenticación. No existe una Passport.js Inc. con la que firmar un DPA. El cumplimiento se construye en torno a las estrategias habilitadas. OAuth con Google, Facebook, GitHub o Microsoft implica compartir datos con esos proveedores en EE. UU., lo que exige documentar el mecanismo de transferencia. SAML con un IdP corporativo interno mantiene todo dentro de la infraestructura del responsable. El login local con usuario y contraseña requiere controles de seguridad estándar (hashes con bcrypt o argon2, rate limiting, MFA cuando proceda).

Consentimiento y base jurídica

La autenticación se basa normalmente en la ejecución del contrato (art. 6(1)(b) RGPD), pues el usuario solicita acceso al servicio. La cookie de sesión es estrictamente necesaria para el servicio solicitado y no requiere opt-in según la Directiva ePrivacy. Solo se necesita consentimiento si recoge datos opcionales (boletín, preferencias de marketing) durante el alta, o si utiliza otras cookies no estrictamente necesarias en el mismo flujo.

Evaluación estrategia por estrategia

Local: sin terceros; asegure hashes fuertes y defensas ante brechas. OAuth Google: datos compartidos con Google LLC (EE. UU.), aplican las CCT, documentar en el registro. OAuth GitHub: GitHub Inc. (EE. UU., propiedad de Microsoft), mismas consideraciones. OAuth Apple: orientada a la privacidad, Apple actúa como relé. SAML: depende de la ubicación del IdP, normalmente interno. OpenID Connect: depende del IdP. JWT: tokens sin estado, el editor controla los datos del token.

Pasos prácticos de cumplimiento

Minimice el scope OAuth a lo necesario (sin foto de perfil ni cumpleaños si no se usan), use hashes con bcrypt o argon2 en la estrategia local, configure cookies seguras HttpOnly SameSite, documente cada estrategia en el registro de tratamiento (datos compartidos y mecanismo de transferencia), realice una EIT para cualquier proveedor OAuth fuera de la UE y desactive las estrategias que no utilice para reducir la superficie de ataque y la huella de privacidad.