Passport.js

Was Passport.js ist und wie es funktioniert

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.

Welche Daten und Cookies Passport.js verarbeitet

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.

DSGVO-Implikationen

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).

Einwilligung und Rechtsgrundlage

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.

Bewertung Strategie für Strategie

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.

Praktische Compliance-Schritte

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.