Votre site utilise des services tiers ? Soyez conforme au RGPD en quelques minutes.
Essayer FlowConsentPlan gratuit · Installation 10 min
Passport.js est un middleware d'authentification open source pour Node.js, utilisé dans des dizaines de milliers d'applications pour gérer les flux de connexion. Il prend en charge plus de 500 stratégies (login local, OAuth Google, Facebook, GitHub, Microsoft, SAML, OpenID Connect, JWT, etc.). Passport.js est simplement une bibliothèque sur le serveur éditeur : aucune donnée n'est transférée à un fournisseur, aucun cookie n'est posé par Passport lui-même (express-session s'en charge) et il n'est pas sous-traitant au sens du RGPD. La conformité dépend des stratégies choisies.
Passport.js est un middleware d'authentification open source pour Node.js, créé par Jared Hanson et désormais maintenu par une petite communauté. Il est intégré ou référencé par la plupart des frameworks Node.js (Express, wrappers Fastify, module Passport NestJS). Sa force est le pattern stratégie : chaque mécanisme est un plugin (passport-local, passport-google-oauth20, passport-saml, passport-jwt, etc.) et le code applicatif reste identique quel que soit le fournisseur activé.
Passport.js ne dépose pas de cookies en propre. Les cookies de session sont gérés par le middleware de session (express-session, fastify-session ou autre), stockés côté client (cookie signé) ou côté serveur (Redis, Memcached, base de données). Passport traite les données que la stratégie lui rend : tokens OAuth, profil utilisateur (nom, email, parfois téléphone, avatar), ID utilisateur fournisseur et scopes demandés. La bibliothèque ne communique avec aucun tiers.
Passport.js étant une bibliothèque s''exécutant sur votre infrastructure, l''éditeur est seul responsable du traitement d''authentification. Il n''y a pas de société Passport.js Inc. avec laquelle signer un DPA. La conformité se construit autour des stratégies activées. OAuth avec Google, Facebook, GitHub ou Microsoft implique un partage de données avec ces fournisseurs aux États-Unis, à documenter. SAML avec un IdP corporate interne maintient tout dans l''infrastructure du responsable. Le login local nécessite des contrôles de sécurité standard (hachage bcrypt ou argon2, rate limiting, MFA).
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
L''authentification est généralement basée sur l''exécution du contrat (art. 6(1)(b) RGPD) puisque l''utilisateur demande l''accès au service. Le cookie de session est strictement nécessaire au service demandé et ne nécessite pas d''opt-in au titre de l''ePrivacy. Un consentement n''est requis que si vous collectez des données optionnelles (newsletter, préférences marketing) pendant l''inscription, ou si vous utilisez d''autres cookies non strictement nécessaires.
Local : pas de tiers ; assurez un hachage fort et des défenses anti-brèche. OAuth Google : partage avec Google LLC (US), CCT, documenter dans le registre. OAuth GitHub : partage avec GitHub Inc. (US, Microsoft), mêmes considérations. OAuth Apple : orienté vie privée, Apple agit en relais. SAML : dépend de l''IdP, généralement enterprise interne. OpenID Connect : dépend de l''IdP. JWT : tokens sans état, l''éditeur contrôle les données du token.
Minimisez le scope OAuth (pas de photo ni anniversaire sans usage), hachez les mots de passe avec bcrypt ou argon2, configurez des cookies sécurisés HttpOnly SameSite, documentez chaque stratégie dans le registre (données partagées, mécanisme de transfert), menez une AIT pour tout fournisseur OAuth hors UE et désactivez les stratégies non utilisées pour réduire la surface d''attaque et l''empreinte vie privée.
Les sites web utilisant Passport.js doivent obtenir le consentement des utilisateurs conformement au RGPD.
Considerations AIPD
Passport.js ne traite que les données que l'éditeur lui passe. La photo de conformité dépend des stratégies : login local traite les credentials sur le serveur éditeur (faible risque) ; OAuth (Google, Facebook, GitHub, Microsoft, Apple) transfère identifiants et tokens au fournisseur d'identité concerné ; SAML dépend de la localisation de l'IdP. Points clés : (1) pour OAuth avec des fournisseurs US, documentez le mécanisme de transfert (CCT, Data Privacy Framework) dans le registre ; (2) minimisez le scope demandé aux fournisseurs OAuth ; (3) les cookies de session via express-session relèvent de l'ePrivacy hors stricte nécessité ; (4) certaines stratégies récupèrent profil complet (téléphone, adresse, photo), souvent excessif.
Exemple de texte de consentement
Nous utilisons Passport.js, une bibliothèque d'authentification open source, pour gérer la connexion. Nous ne partageons aucune donnée avec les mainteneurs de Passport.js. Lorsque vous vous connectez avec un fournisseur tiers (Google, GitHub, etc.), vos données sont partagées avec ce fournisseur selon ses conditions. Des cookies de session sont nécessaires pour vous maintenir connecté et sont déposés après votre connexion.
Domaines tiers contactes
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 deposes
| Nom | Type | Duree | Finalite |
|---|---|---|---|
| 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 est un service essentiel, mais la transparence compte. Gerez tous vos consentements avec FlowConsent.
Passport.js ne dépose pas de cookies en propre. Les cookies de session sont gérés par le middleware (généralement express-session en Express), qui stocke un identifiant signé côté client ou la session complète côté serveur. Le cookie déposé est celui de l'éditeur, sur son propre domaine.
Pour l'authentification elle-même, non. L'authentification repose sur l'exécution du contrat (art. 6(1)(b) RGPD) et le cookie de session est strictement nécessaire. Le consentement n'est requis que pour des données optionnelles à l'inscription, des cookies marketing dans le même flux ou des fournisseurs OAuth nécessitant leur propre consentement (par ex. Connexion via Facebook).
L'exécution du contrat (art. 6(1)(b) RGPD) est la base standard. L'intérêt légitime (art. 6(1)(f)) peut s'appliquer à la télémétrie sécurité (échecs de connexion, suivi d'IP suspectes). Le consentement est nécessaire pour les fournisseurs OAuth agissant comme co-responsables à des fins publicitaires.
Passport.js en lui-même ne transfère rien ; c'est une bibliothèque open source exécutée sur votre serveur. Les transferts dépendent des stratégies activées : OAuth avec Google, Facebook, GitHub ou Microsoft transfère des données vers ces fournisseurs aux États-Unis, à documenter via CCT et Data Privacy Framework.
Passport.js seul ne déclenche pas d'AIPD. Une AIPD peut être nécessaire si le traitement global qu'il permet est à risque élevé (authentification à grande échelle, secteur sensible, supervision salariés). Pour la plupart des flux consommateur, une évaluation documentée suffit.
Utilisez la stratégie locale avec hachage fort (bcrypt ou argon2), configurez des cookies HttpOnly Secure SameSite, minimisez les scopes OAuth, désactivez les stratégies inutilisées, documentez chaque stratégie dans votre registre, menez une AIT pour les fournisseurs OAuth hors UE et offrez aux utilisateurs un moyen clair de supprimer leur compte.
Autres bibliothèques Node.js : NextAuth.js (devenu Auth.js, très populaire en Next.js), Lucia Auth, Better-Auth, Iron Session et le SDK Clerk (hébergé). En PHP, Symfony Security et Laravel Sanctum/Passport. En Python, django-allauth ou FastAPI Users. Le choix dépend du framework et de la préférence service hébergé ou bibliothèque.
Passport.js en lui-même n'a pas besoin d'être nommé dans une bannière cookies (pas de tracking tiers). En revanche, votre politique doit décrire les stratégies d'authentification proposées, les données partagées avec chaque fournisseur OAuth (nom, lien vers leur politique, mécanisme de transfert hors UE le cas échéant) et le fonctionnement des cookies de session.