¿Tu sitio web utiliza servicios de terceros? Cumple con el RGPD en minutos.
Probar FlowConsentmobileCta.note
Passport.js es un middleware de autenticación open source para Node.js, utilizado en decenas de miles de aplicaciones para gestionar el flujo de inicio de sesión. Soporta más de 500 estrategias (local con usuario y contraseña, OAuth con Google, Facebook, GitHub, Microsoft, SAML, OpenID Connect, JWT, etc.). Passport.js es solo una biblioteca que se ejecuta en el servidor del editor: no transfiere datos a ningún proveedor, no establece cookies por sí misma (lo hace express-session) y no es encargado del tratamiento bajo el RGPD. El cumplimiento depende de las estrategias elegidas.
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.
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.
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).
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
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.
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.
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.
Websites using Passport.js must obtain user consent under GDPR regulations.
DPIA considerations
Passport.js trata solo los datos que el editor le pasa. El panorama de cumplimiento depende de las estrategias usadas: el login local procesa credenciales en el servidor del editor (bajo riesgo); las estrategias OAuth (Google, Facebook, GitHub, Microsoft, Apple) transfieren identificadores y tokens al proveedor de identidad correspondiente; las estrategias SAML dependen de la ubicación del IdP SAML. Consideraciones clave: (1) para OAuth con proveedores estadounidenses, documente el mecanismo de transferencia (CCT, Marco de Privacidad de Datos) en su registro; (2) el alcance solicitado al proveedor OAuth debe minimizarse a lo necesario; (3) las cookies de sesión depositadas por express-session están sujetas a la ePrivacy fuera de la estricta necesidad; (4) algunas estrategias obtienen el perfil completo (teléfono, dirección, foto), lo cual puede ser excesivo.
Sample consent text
Utilizamos Passport.js, una biblioteca open source de autenticación, para gestionar el inicio de sesión. No compartimos datos con los mantenedores de Passport.js. Cuando inicia sesión con un proveedor externo (Google, GitHub, etc.), sus datos se comparten con ese proveedor según sus condiciones. Las cookies de sesión son necesarias para mantenerle conectado y se establecen tras iniciar sesión.
Third-party domains contacted
publisher domain (Passport.js is a library, not a third party host)depends on OAuth strategies enabled (e.g. accounts.google.com, github.com, facebook.com)Cookies placed
| Name | Type | Duration | Purpose |
|---|---|---|---|
| connect.sid | Strictly Necessary | Session or configured | Default session cookie set by express-session (the typical companion of Passport.js). Contains a signed session identifier and is used to maintain authenticated state across requests. Lifetime is configured by the publisher. |
Passport.js es un servicio esencial, pero la transparencia es importante. Gestiona todo tu consentimiento con FlowConsent.
Passport.js no establece cookies por sí mismo. Las cookies de sesión las gestiona el middleware de sesiones (normalmente express-session en apps Express), que almacena un identificador de sesión firmado en el cliente o la sesión completa en el servidor. La cookie depositada es la del editor, en su propio dominio.
Para la autenticación en sí, no. La autenticación se basa en la ejecución del contrato (art. 6(1)(b) RGPD) y la cookie de sesión es estrictamente necesaria. El consentimiento solo entra en juego si recoge datos opcionales en el registro, usa cookies de marketing en el mismo flujo o utiliza proveedores OAuth que exijan su propio consentimiento (p. ej., Iniciar sesión con Facebook).
La ejecución del contrato (art. 6(1)(b) RGPD) es la base estándar para la autenticación. El interés legítimo (art. 6(1)(f)) puede aplicar a la telemetría de seguridad (intentos fallidos de login, seguimiento de IPs sospechosas). El consentimiento es necesario para proveedores OAuth que actúan como corresponsables con fines publicitarios.
Passport.js por sí solo no transfiere datos a ningún sitio; es una biblioteca open source que se ejecuta en su servidor. Las transferencias dependen de las estrategias habilitadas: OAuth con Google, Facebook, GitHub o Microsoft transfiere datos a esos proveedores en EE. UU., con CCT y documentación del Marco de Privacidad de Datos.
Passport.js por sí solo no activa una EIPD. Puede ser necesaria si el tratamiento global es de alto riesgo (autenticación a gran escala, sector sensible, supervisión de empleados). Para la mayoría de flujos de consumo, basta con una evaluación documentada.
Use la estrategia local con hashes fuertes (bcrypt o argon2), configure cookies HttpOnly Secure SameSite, minimice los scopes OAuth a lo necesario, desactive las estrategias no usadas, documente cada estrategia en su registro, realice una EIT para proveedores OAuth fuera de la UE y ofrezca a los usuarios una forma clara de eliminar su cuenta.
Otras bibliotecas de autenticación de Node.js: NextAuth.js (ahora Auth.js, muy popular en Next.js), Lucia Auth, Better-Auth, Iron Session y el SDK de Clerk (alojado). En PHP, Symfony Security y Laravel Sanctum/Passport. En Python, django-allauth o FastAPI Users. La elección depende del framework y de si prefiere un servicio alojado o una biblioteca.
Passport.js en sí no necesita nombrarse en un banner de cookies (sin seguimiento de primera o tercera parte). Sin embargo, su política debería describir las estrategias de autenticación que ofrece, los datos compartidos con cada proveedor OAuth (con nombre, enlace a su política y mecanismo de transferencia si está fuera de la UE) y cómo funcionan las cookies de sesión.