Does your website use third-party services? Get GDPR compliant in minutes.
Try FlowConsentFree plan · 10-min setup
Passport.js is an open source authentication middleware for Node.js, used in tens of thousands of applications to handle login flows. It supports over 500 authentication strategies including local username/password, OAuth (Google, Facebook, GitHub, Microsoft), SAML, OpenID Connect, JWT and many more. Passport itself is just a library running on the publisher server: it does not transfer data to any vendor, does not set cookies on its own (session cookies come from express-session) and is not a processor under GDPR. Compliance considerations focus on the strategies the publisher chooses.
Passport.js is an open source authentication middleware for Node.js, originally created by Jared Hanson and now maintained by a small community. It is bundled in or referenced by most major Node.js web frameworks (Express, Fastify wrappers, NestJS Passport module). Its strength is the strategy pattern: each authentication mechanism is implemented as a plugin (passport-local, passport-google-oauth20, passport-saml, passport-jwt and so on), and the application code stays the same regardless of which providers are enabled.
Passport.js does not set cookies on its own. Session cookies are managed by the session middleware (express-session, fastify-session or similar) and stored either client side (signed cookie sessions) or server side (Redis, Memcached, database). Passport processes the data that the chosen strategy hands back, which can include OAuth tokens, the user profile (name, email, sometimes phone, avatar URL), the provider user ID and any custom scopes requested. The library does not phone home or share data with any third party.
Because Passport.js is a library running on the publisher infrastructure, the publisher is the sole controller for the authentication processing. There is no Passport.js Inc. to sign a DPA with. The compliance picture is built around the strategies you enable. OAuth with Google, Facebook, GitHub or Microsoft means user data is shared with those providers in the US, requiring documentation of the transfer mechanism. SAML with an internal corporate IdP keeps everything within the controller infrastructure. Local username/password sessions need standard security controls (hashed passwords with bcrypt or argon2, rate limiting, MFA where appropriate).
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
Authentication is normally based on contract performance (Art. 6(1)(b) GDPR) since the user is requesting access to the service. The session cookie itself is strictly necessary for the requested service and does not need an opt in under the ePrivacy Directive. Consent is only needed if you collect optional profile data (newsletter subscription, marketing preferences) during signup, or if you use non strictly necessary cookies in the same flow.
Local: no third party; ensure strong password hashing and breach defences. OAuth Google: user data shared with Google LLC (US), Standard Contractual Clauses apply, document in record of processing activities. OAuth GitHub: data shared with GitHub Inc. (US, owned by Microsoft), same considerations. OAuth Apple: privacy oriented, Apple acts as relay. SAML: depends on the IdP location, normally enterprise internal. OpenID Connect: depends on the IdP. JWT: stateless tokens; the publisher controls the data inside the token.
Minimise the OAuth scope to what you really need (no profile photo or birthday unless used), hash passwords with bcrypt or argon2 in the local strategy, set secure HttpOnly SameSite cookies for sessions, document each strategy in your record of processing activities including the data shared and the transfer mechanism, run a Transfer Impact Assessment for any non EU OAuth provider, and disable strategies you do not use to reduce the attack surface and the privacy footprint.
Websites using Passport.js must obtain user consent under GDPR regulations.
DPIA considerations
Passport.js itself processes only the data the publisher passes to it. The compliance picture depends on the strategies used: local username/password processes credentials on the publisher server (low transfer risk); OAuth strategies (Google, Facebook, GitHub, Microsoft, Apple) transfer user identifiers and tokens to the relevant identity provider; SAML strategies depend on the SAML IdP location. Key considerations: (1) for OAuth with US providers, document the transfer mechanism (SCCs, Data Privacy Framework) in your record of processing activities; (2) the scope of data requested from OAuth providers should be minimised to what is necessary; (3) session cookies set by express-session are subject to ePrivacy if used outside strict necessity; (4) some strategies fetch the entire user profile including phone, address, photo, which may be excessive.
Sample consent text
We use Passport.js, an open source authentication library, to handle login. We do not share data with the Passport.js maintainers. When you sign in with a third party provider (Google, GitHub, etc.), your data is shared with that provider under their terms. Session cookies are required to keep you logged in and are set after you sign in.
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 is an essential service, but transparency matters. Manage all your consent with FlowConsent.
Passport.js does not set cookies on its own. Session cookies are managed by the session middleware (typically express-session in Express apps), which stores either a signed session ID client side or the full session server side. The cookie set is the publisher's session cookie, on the publisher's own domain.
For the authentication itself, no. Authentication is based on contract performance (Art. 6(1)(b) GDPR) and the session cookie is strictly necessary. Consent only enters the picture if you collect optional profile data during signup, use marketing cookies in the same flow, or use OAuth providers that require their own consent (e.g. Sign in with Facebook).
Contract performance (Art. 6(1)(b) GDPR) is the standard basis for authentication. Legitimate interest (Art. 6(1)(f)) can apply for security telemetry (failed login attempts, suspicious IP tracking). Consent is needed for OAuth providers that act as joint controllers for advertising purposes.
Passport.js itself does not transfer data anywhere; it is an open source library that runs on your server. Transfers depend on the strategies you enable: OAuth with Google, Facebook, GitHub or Microsoft transfers user data to those providers in the US, requiring SCCs and Data Privacy Framework documentation.
Passport.js alone does not trigger a DPIA. A DPIA may be needed if the broader processing it enables is high risk (large scale authentication, sensitive sector, employee monitoring). For most consumer login flows, a documented assessment is sufficient.
Use the local strategy with strong password hashing (bcrypt or argon2), set HttpOnly Secure SameSite session cookies, minimise OAuth scopes to what you really need, disable unused strategies, document each strategy in your record of processing activities, run a Transfer Impact Assessment for non EU OAuth providers, and offer users a clear way to delete their account.
Other Node.js auth libraries: NextAuth.js (now Auth.js, very popular in Next.js), Lucia Auth, Better-Auth, Iron Session and Clerk SDK (hosted). For PHP, Symfony Security and Laravel Sanctum/Passport. For Python, django-allauth or FastAPI Users. The choice depends on framework and on whether you want a hosted service or a library.
Passport.js itself does not need to be named in a cookie banner (no first party tracking). However, your privacy notice should describe the authentication strategies you offer, the data shared with each OAuth provider (with name, link to their privacy policy, transfer mechanism if outside EU), and how session cookies work.