Auth0 et RGPD : conformité, droit à l'oubli et export des données
Comment gérer la conformité RGPD avec Auth0 ? Droit à l'effacement, portabilité des données, consentement et gestion des sous-traitants.
Par Auth0.Expert · 2025-04-25 · 11 min de lecture
Auth0 et RGPD : guide de conformité
TL;DR
Auth0 est un sous-traitant de données au sens du RGPD. Vous restez responsable du traitement. Ce guide couvre le droit à l'effacement, la portabilité, la minimisation des données et les DPA.
---
Auth0 comme sous-traitant
Ce tableau définit les rôles entre votre entreprise et Auth0 en termes de gestion des données personnelles.
Responsable de traitement : Votre entreprise
Sous-traitant : Auth0 (Okta Inc.)
Finalité : Authentification et gestion des identités
Données traitées : Email, nom, IP, logs d'authentification
DPA (Data Processing Agreement) : disponible dans le Auth0 dashboard → Organization Settings → Data Privacy → Download DPA
---
Minimisation des données
Voici un exemple mettant en avant l'importance de ne stocker que les informations nécessaires dans Auth0, et d'utiliser votre base de données pour les données sensibles.
// Ne stocker que ce qui est strictement nécessaire
// ❌ Mauvaise pratique : stocker tout dans Auth0
api.user.setUserMetadata({
address: "42 Rue de Rivoli, Paris",
birth_date: "1985-06-15",
passport_number: "P1234567", // PII sensible !
medical_data: {...},
});
// ✅ Bonne pratique : stocker les PII dans votre DB, Auth0 = identifiant uniquement
api.user.setAppMetadata({
db_profile_id: "123456", // Référence à votre DB
plan: "pro",
verified_at: "2025-01-15",
});
// Les vraies données PII sont dans votre DB, avec chiffrement au repos
Ce code illustre la bonne pratique de séparer l'identité et les données personnelles dans le respect de la minimisation RGPD.
---
Droit à l'effacement (Article 17 RGPD)
Ce code présente comment répondre à une demande d'effacement des données d’un utilisateur sur Auth0 conformément à l’article 17 du RGPD.
# Procédure complète d'effacement Auth0
async def handle_deletion_request(user_email: str, requestor_email: str):
"""Traiter une demande d'effacement RGPD."""
# 1. Trouver l'utilisateur
users = await auth0_search(f'email:"{user_email}"')
if not users:
return {"status": "not_found"}
user = users[0]
user_id = user['user_id']
# 2. Logger la demande (pour audit)
await log_deletion_request({
"user_id": user_id,
"email": user_email,
"requestor": requestor_email,
"requested_at": datetime.utcnow().isoformat(),
})
# 3. Révoquer tous les tokens actifs
await auth0_delete_user_grants(user_id)
# 4. Supprimer le compte Auth0
await auth0_delete_user(user_id)
# 5. Supprimer les données dans vos systèmes
await anonymize_user_in_database(user_email)
await delete_from_crm(user_email)
await delete_from_analytics(user_email)
# 6. Anonymiser les logs (ne pas les supprimer — obligations légales)
await anonymize_logs(user_id)
# 7. Envoyer la confirmation
await send_deletion_confirmation(requestor_email, user_email)
return {"status": "deleted", "user_id": user_id}
Ce script gère étape par étape la suppression des données d'un utilisateur dans Auth0 et dans vos systèmes métiers.
---
Portabilité des données (Article 20 RGPD)
Cette section explique comment extraire toutes les données liées à un utilisateur pour répondre à une demande de portabilité.
# Export des données d'un utilisateur en format JSON
async def export_user_data(user_id: str) -> dict:
"""Exporter toutes les données d'un utilisateur pour portabilité RGPD."""
# 1. Profil Auth0
user = await auth0_get_user(user_id)
# 2. Logs d'authentification
logs = await auth0_get_user_logs(user_id, limit=1000)
# 3. Données dans votre DB
db_data = await get_user_data_from_db(user_id)
export = {
"export_date": datetime.utcnow().isoformat(),
"export_format": "RGPD Article 20 - Portabilité",
"profile": {
"id": user["user_id"],
"email": user.get("email"),
"name": user.get("name"),
"given_name": user.get("given_name"),
"family_name": user.get("family_name"),
"created_at": user.get("created_at"),
"last_login": user.get("last_login"),
"logins_count": user.get("logins_count"),
},
"authentication_history": [
{
"date": log.get("date"),
"type": log.get("type"),
"ip": log.get("ip"),
"location": log.get("location_info", {}).get("country_name"),
}
for log in logs
],
"application_data": db_data,
}
return export
Cette fonction regroupe toutes les informations Auth0 et applicatives pour les remettre à l’utilisateur.
---
Gestion du consentement
En utilisant les Actions Auth0, voici comment capturer et vérifier le consentement utilisateur lors de l'inscription et de la connexion.
// Action Post Registration : enregistrer le consentement
exports.onExecutePostUserRegistration = async (event, api) => {
const consentTimestamp = new Date().toISOString();
api.user.setUserMetadata({
consents: {
terms_of_service: {
accepted: true,
version: event.secrets.CURRENT_TOS_VERSION,
accepted_at: consentTimestamp,
ip: event.request.ip,
},
marketing: {
accepted: event.user.user_metadata?.marketing_consent === true,
accepted_at: consentTimestamp,
},
analytics: {
accepted: true, // Inclus dans les CGU
accepted_at: consentTimestamp,
}
}
});
};
// Action Post Login : vérifier si les CGU ont été mises à jour
exports.onExecutePostLogin = async (event, api) => {
const currentTosVersion = event.secrets.CURRENT_TOS_VERSION;
const userTosVersion = event.user.user_metadata?.consents?.terms_of_service?.version;
if (userTosVersion !== currentTosVersion) {
// Rediriger vers la page d'acceptation des nouvelles CGU
api.redirect.sendUserTo(`${event.secrets.APP_URL}/accept-new-tos`, {
query: {
version: currentTosVersion,
return_to: event.transaction?.redirect_uri,
}
});
}
};
Ce code automatise l’enregistrement du consentement et gère les mises à jour de conditions d’utilisation côté Auth0.
---
Données Auth0 et leur localisation
Ce tableau récapitule les lieux de stockage, la durée de conservation et les mécanismes de transfert des données traitées par Auth0.
| Donnée | Stockage | Durée | |--------|---------|-------| | Profil utilisateur | Région EU (eu.auth0.com) | Vie du compte | | Logs d'authentification | Région EU | 30 jours (Enterprise) | | Emails de vérification | SendGrid (USA) | À la livraison | | Sessions actives | Région EU | Durée de la session |
Pour garantir la localisation EU : utiliser le tenant EU (eu.auth0.com) + DPA Auth0 pour les transferts hors EU.
---
Registre des traitements (Article 30)
Voici un exemple d’entrée à insérer dans votre registre des traitements pour décrire l’usage d’Auth0.
// Entrée registre RGPD pour Auth0
{
"nom_traitement": "Authentification et gestion des identités",
"responsable": "YourCo SAS",
"sous_traitant_principal": "Auth0 Inc. (Okta) — DPA signé le 2025-01-01",
"finalites": ["Authentification", "Contrôle d'accès", "Sécurité"],
"categories_personnes": ["Utilisateurs", "Clients", "Employés"],
"categories_donnees": ["Email", "Nom", "IP", "Logs de connexion"],
"duree_conservation": "3 ans après désinscription",
"transferts_hors_ue": "Oui — Auth0 EU region + SCC via DPA",
"mesures_securite": ["Chiffrement TLS 1.3", "MFA", "SOC2 Type II"],
"base_legale": "Exécution d'un contrat (Art. 6.1.b)"
}
Ce JSON présente tous les éléments obligatoires du registre des traitements selon l’article 30.
---
> ⚖️ Conformité RGPD Auth0 : nos experts RGPD et IAM vous accompagnent dans la mise en conformité complète de votre implémentation Auth0 (DPA, DPIA, registre des traitements).
📞 +33 1 23 45 67 89 · 📧 [email protected]
Autres articles
- Auth0 et OAuth 2.0 : architecture complète pour comprendre les flux d'autorisation
- OpenID Connect sur Auth0 : ID Token, UserInfo et discovery endpoint expliqués
- Configurer SAML 2.0 avec Auth0 : guide complet pour l'entreprise
- Migrer des Rules vers les Auth0 Actions : guide pas à pas
- Architecture multi-tenant avec Auth0 : organisations, isolation et bonnes pratiques
- Validation des JWT Auth0 : RS256 vs HS256, JWKS et pièges communs
- Concevoir son architecture de tenants Auth0 : dev, staging, prod
- Configurer un domaine personnalisé Auth0 : login.votredomaine.com étape par étape