Nutzt Ihre Website Drittanbieter-Dienste? Werden Sie in wenigen Minuten DSGVO-konform.
FlowConsent testenmobileCta.note
Passport.js ist eine Open-Source-Authentifizierungs-Middleware für Node.js, eingesetzt in zehntausenden Anwendungen für Login-Flows. Sie unterstützt über 500 Strategien (Local, OAuth Google, Facebook, GitHub, Microsoft, SAML, OpenID Connect, JWT u. a.). Passport.js ist eine reine Bibliothek auf dem Betreiberserver: es findet kein Datentransfer an einen Anbieter statt, Cookies setzt Passport selbst nicht (express-session übernimmt das), und es ist kein Auftragsverarbeiter im Sinne der DSGVO. Die Compliance richtet sich nach den gewählten Strategien.
Passport.js ist eine Open-Source-Authentifizierungs-Middleware für Node.js, ursprünglich von Jared Hanson und heute von einer kleinen Community gepflegt. Sie ist in oder neben den meisten großen Node.js-Frameworks verfügbar (Express, Fastify-Wrapper, NestJS-Passport-Modul). Ihre Stärke ist das Strategy-Pattern: jede Authentifizierungsart ist ein Plugin (passport-local, passport-google-oauth20, passport-saml, passport-jwt usw.), und der Anwendungscode bleibt unabhängig vom Anbieter gleich.
Passport.js setzt keine eigenen Cookies. Session-Cookies werden vom Session-Middleware (express-session, fastify-session o. ä.) gemanagt, clientseitig (signiertes Cookie) oder serverseitig (Redis, Memcached, DB). Passport verarbeitet, was die Strategie zurückgibt: OAuth-Tokens, Profil (Name, E-Mail, ggf. Telefon, Avatar-URL), Anbieter-User-ID und angeforderte Scopes. Die Bibliothek phone-homed nicht und teilt keine Daten mit Dritten.
Da Passport.js eine Bibliothek auf Ihrer Infrastruktur ist, ist der Betreiber alleiniger Verantwortlicher für die Authentifizierung. Es gibt keine Passport.js Inc., mit der ein AVV zu schließen wäre. Die Compliance baut sich um die aktivierten Strategien auf. OAuth mit Google, Facebook, GitHub oder Microsoft bedeutet Datenaustausch mit diesen Anbietern in den USA, was Transferdokumentation erfordert. SAML mit internem Corporate IdP bleibt innerhalb der Verantwortlichen-Infrastruktur. Local-Login benötigt Standard-Sicherheitsmaßnahmen (bcrypt/argon2, Rate-Limiting, ggf. MFA).
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
Authentifizierung erfolgt regelmäßig auf Vertragserfüllung (Art. 6(1)(b) DSGVO), da der Nutzer Zugang zum Dienst wünscht. Das Session-Cookie ist für den angeforderten Dienst strikt erforderlich und benötigt nach ePrivacy keine Opt-in-Einwilligung. Einwilligung wird nur nötig, wenn Sie optionale Profildaten (Newsletter, Marketingpräferenzen) bei der Registrierung erheben oder nicht zwingend erforderliche Cookies im gleichen Flow nutzen.
Local: kein Dritter; starke Passworthashes und Breach-Defense sicherstellen. OAuth Google: Datenaustausch mit Google LLC (US), SCC, im Verzeichnis dokumentieren. OAuth GitHub: GitHub Inc. (US, Microsoft), gleiche Überlegungen. OAuth Apple: datenschutzorientiert, Apple als Relay. SAML: standortabhängig vom IdP, meist intern. OpenID Connect: hängt vom IdP ab. JWT: zustandslose Tokens; Betreiber steuert Tokeninhalt.
Minimieren Sie OAuth-Scopes (kein Profilfoto oder Geburtstag, sofern nicht genutzt), nutzen Sie bcrypt oder argon2 für Local, setzen Sie sichere HttpOnly-SameSite-Cookies, dokumentieren Sie jede Strategie im Verzeichnis (geteilte Daten, Transfer-Mechanismus), führen Sie für Nicht-EU-OAuth-Anbieter eine TIA durch und deaktivieren Sie nicht genutzte Strategien, um Angriffsfläche und Datenschutz-Footprint zu reduzieren.
Websites using Passport.js must obtain user consent under GDPR regulations.
DPIA considerations
Passport.js verarbeitet nur, was der Betreiber übergibt. Die Compliance hängt von den Strategien ab: Local verarbeitet Anmeldedaten auf dem Betreiberserver (niedriges Risiko); OAuth (Google, Facebook, GitHub, Microsoft, Apple) überträgt Identifier und Tokens an den Identity Provider; SAML hängt vom IdP-Standort ab. Schlüsselpunkte: (1) bei US-OAuth-Anbietern Transfer-Mechanismus (SCC, Data Privacy Framework) im Verzeichnis dokumentieren; (2) OAuth-Scopes minimieren; (3) Session-Cookies via express-session unterliegen außerhalb strikter Erforderlichkeit der ePrivacy; (4) manche Strategien holen ganze Profile (Telefon, Adresse, Foto), oft übermäßig.
Sample consent text
Wir nutzen Passport.js, eine Open-Source-Authentifizierungsbibliothek, für den Login. Wir teilen keine Daten mit den Passport.js-Maintainern. Wenn Sie sich über einen Drittanbieter anmelden (Google, GitHub usw.), werden Ihre Daten unter dessen Bedingungen mit diesem geteilt. Session-Cookies sind erforderlich, um Sie eingeloggt zu halten, und werden nach dem Login gesetzt.
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 ist ein essenzieller Dienst, aber Transparenz ist wichtig. Verwalten Sie Ihre gesamte Einwilligung mit FlowConsent.
Passport.js setzt selbst keine Cookies. Session-Cookies verwaltet die Session-Middleware (typischerweise express-session in Express-Apps), die entweder eine signierte Session-ID clientseitig oder die vollständige Session serverseitig speichert. Das gesetzte Cookie ist das Session-Cookie des Betreibers auf dessen eigener Domain.
Für die reine Authentifizierung nein. Authentifizierung erfolgt auf Vertragserfüllung (Art. 6(1)(b) DSGVO) und das Session-Cookie ist strikt erforderlich. Eine Einwilligung wird relevant bei optionalen Profildaten bei der Registrierung, Marketing-Cookies im selben Flow oder OAuth-Providern mit eigener Einwilligungspflicht (z. B. Anmeldung mit Facebook).
Vertragserfüllung (Art. 6(1)(b) DSGVO) ist die Standardgrundlage für die Authentifizierung. Berechtigtes Interesse (Art. 6(1)(f)) kann für Sicherheits-Telemetrie greifen (Fehlversuche, IP-Tracking). Einwilligung wird für OAuth-Provider erforderlich, die als Joint Controller zu Werbezwecken auftreten.
Passport.js selbst überträgt keine Daten irgendwohin; es ist eine Open-Source-Bibliothek auf Ihrem Server. Transfers hängen von den aktivierten Strategien ab: OAuth mit Google, Facebook, GitHub oder Microsoft überträgt Nutzerdaten an diese Anbieter in den USA, mit SCC-, und Data-Privacy-Framework-Dokumentation.
Passport.js allein löst keine DSFA aus. Eine DSFA kann erforderlich sein, wenn die Gesamtverarbeitung Hochrisiko ist (großskalige Authentifizierung, sensibler Sektor, Beschäftigtenüberwachung). Für die meisten Consumer-Logins genügt eine dokumentierte Bewertung.
Nutzen Sie die Local-Strategie mit bcrypt oder argon2, setzen Sie HttpOnly-Secure-SameSite-Session-Cookies, minimieren Sie OAuth-Scopes, deaktivieren Sie ungenutzte Strategien, dokumentieren Sie jede Strategie im Verzeichnis, führen Sie für Nicht-EU-OAuth-Anbieter eine TIA durch und bieten Sie Nutzern einen klaren Weg, ihr Konto zu löschen.
Weitere Node.js-Auth-Bibliotheken: NextAuth.js (heute Auth.js, beliebt in Next.js), Lucia Auth, Better-Auth, Iron Session und das Clerk-SDK (gehostet). In PHP: Symfony Security und Laravel Sanctum/Passport. In Python: django-allauth oder FastAPI Users. Die Wahl hängt vom Framework und der Präferenz Service vs. Bibliothek ab.
Passport.js selbst muss nicht im Cookie-Banner stehen (kein First-Party-Tracking). Ihre Datenschutzerklärung sollte aber die angebotenen Authentifizierungsstrategien beschreiben, die mit jedem OAuth-Anbieter geteilten Daten (Name, Link zur Datenschutzerklärung, Transfer-Mechanismus bei Standorten außerhalb der EU) und die Funktionsweise der Session-Cookies.