Le questionnaire de sécurité, et où trouver les réponses
Les questions de connexion d'un questionnaire de sécurité d'entreprise, avec la réponse d'EAuth et la clause ou la page qui l'étaye, y compris notre non.
Le premier gros client envoie un tableur : une colonne pour votre réponse, une colonne pour la preuve, et une bonne part des lignes porte sur la manière dont les gens se connectent. Si vous avez développé la connexion vous-même, c'est là que vous découvrez ce que vous n'avez pas développé. Si vous utilisez EAuth, la plupart des lignes ont déjà une réponse. Voici la liste, avec, pour chaque réponse, la clause des conditions d'EAuth ou la page de la documentation qui l'étaye. Les conditions sont versionnées et chaque version reste publiée (14.3) : la clause que vous citez ne change pas sous vos pieds.
Où les données sont-elles stockées, et par qui ?
En Suisse et dans l'Espace économique européen uniquement ; le contrat de sous-traitance le dit (annexe B.14). Depuis le 3 octobre 2026, EAuth tourne sur notre propre cluster : huit serveurs chez cinq hébergeurs dans quatre pays. Les trois nœuds de base de données sont à Francfort, Nuremberg et Paris, l'application tourne à Genève et Amsterdam, les deux points d'entrée où se termine TLS sont à Falkenstein et Amsterdam, et un observateur tourne à Genève. Aucun proxy tiers n'est placé devant eux. Les mails, c'est-à-dire les confirmations d'adresse, les réinitialisations de mot de passe et les invitations, partent via un service d'envoi de mails, qui voit l'adresse du destinataire et le texte du mail.
Preuve : l'annexe B, le contrat de sous-traitance, qui ne demande pas de signature séparée. Les conditions nous engagent à annoncer un nouveau sous-traitant 30 jours avant qu'il ne commence, et vous pouvez résilier si vous vous y opposez (8.5, B.8).
Comment les mots de passe sont-ils stockés ?
Argon2id, 64 MiB de mémoire, trois itérations, deux voies, un sel aléatoire de 16 octets par mot de passe, avec les paramètres dans chaque hash stocké pour pouvoir les relever plus tard sans réinitialisation. Les refresh tokens, codes d'autorisation, clés d'API, invitations et codes de récupération ne sont stockés que sous forme de condensés SHA-256, tout comme les liens qui confirment une adresse ou réinitialisent un mot de passe. Les clés de signature des tokens sont chiffrées en AES-256-GCM sous une clé qui ne se trouve jamais dans la base de données. Preuve : l'annexe C.1, et le tableau de la page sécurité qui décrit le stockage des identifiants.
Les adresses e-mail sont-elles vérifiées ?
Oui, avant qu'une application ne voie le compte. Depuis le 3 octobre 2026, aucune application ne reçoit de compte dont l'adresse n'a pas été confirmée. Une personne qui s'inscrit est arrêtée sur le chemin du retour par une page qui envoie un nouveau lien, et le lien ramène à la connexion ; une application qui demande en silence, avec prompt=none, reçoit interaction_required. email_verified vaut donc true dans chaque ID token issu d'une connexion. Une adresse compte comme confirmée par le lien, par une réinitialisation de mot de passe envoyée à cette adresse, ou quand le fournisseur d'identité d'une organisation s'en porte garant. Preuve : le quickstart de la documentation.
L'authentification multifacteur est-elle disponible ? Est-elle obligatoire pour les administrateurs ?
Disponible pour chaque utilisateur final : une application d'authentification avec codes de récupération, et les passkeys. Exiger un second facteur de vos utilisateurs est un réglage de votre application, et une organisation peut l'exiger de ses membres. De notre côté, chaque rôle qui peut modifier du contenu ou des identifiants doit utiliser un second facteur, et le tableau de bord le vérifie à chaque requête, pas seulement à la connexion. Preuve : l'annexe C.2.
Comment les sessions sont-elles protégées ?
Les refresh tokens sont renouvelés à chaque utilisation, et un token déjà renouvelé présenté à nouveau révoque toute la chaîne, puisque le client légitime et un voleur ne peuvent pas détenir tous deux le plus récent. Les codes d'autorisation vivent soixante secondes, fonctionnent une fois et sont liés au client, à la redirect URI et au challenge PKCE ; PKCE avec S256 est exigé sur chaque requête. Les access tokens vivent 15 minutes par défaut. Les sessions d'administration sont vérifiées auprès de la base de données à chaque requête : en révoquer une prend effet immédiatement. Preuve : l'annexe C.3, et la section « What is enforced » de la page sécurité.
Comment vous protégez-vous contre la force brute ?
Chaque tentative est comptée avant d'être vérifiée, par adresse et par compte, et les compteurs échouent en position fermée : si le stockage qui les porte est injoignable, la page de connexion refuse plutôt que de laisser passer les requêtes. Cinq mauvais mots de passe pour un compte depuis une adresse, ou vingt d'où que ce soit, le bloquent jusqu'à quinze minutes. Les codes de second facteur autorisent cinq erreurs en quinze minutes et vingt par jour. Un navigateur qui s'est déjà connecté au compte garde un quota à lui, si bien qu'un attaquant ne peut pas bloquer le propriétaire en devinant. Preuve : la page sécurité, avec les chiffres, et l'annexe C.4.
Y a-t-il une piste d'audit ?
Chaque modification des identifiants et des réglages d'une application va dans un journal d'audit avec le compte et l'adresse e-mail de son auteur : création d'une application, renouvellement de son secret, modification de ses réglages, des webhooks, de l'équipe, des organisations et de leur single sign-on, imports et exports de comptes, comptes supprimés, et compte repris par single sign-on. Un trigger de la base de données refuse toute modification d'une entrée, et refuse de supprimer une entrée de moins de douze mois. Preuve : l'annexe C.5.
Combien de temps conservez-vous quoi ?
Les sessions et les refresh tokens jusqu'à leur expiration, et un token révoqué jusqu'au moment où il aurait expiré, pour qu'une copie volée présentée plus tard soit encore reconnue. Les codes d'autorisation une heure après leurs soixante secondes. Les liens de confirmation et de réinitialisation une semaine après leur utilisation ou leur expiration, les invitations 30 jours. Le journal des requêtes de token et le journal d'audit douze mois, les livraisons de webhooks 30 jours. Un compte est supprimé 30 jours après la demande de son propriétaire ; un compte sans connexion depuis 24 mois reçoit deux mails à 30 jours d'intervalle, puis est supprimé 30 jours après le second, sauf s'il se connecte. Un nettoyage retire chaque heure ce qui est arrivé à échéance. Preuve : la section « How long things are kept » de la page sécurité, et les clauses 7.4 et 7.5 des conditions.
Pouvons-nous partir ?
Oui, avec les hashes des mots de passe. La console exporte une application avec ses comptes, organisations, rôles, webhooks et réglages en JSON, à tout moment, sans nous demander. Les hashes sont sous leur forme d'origine, Argon2id ou le format dans lequel ils ont été importés, et vos utilisateurs gardent donc leur mot de passe chez le fournisseur suivant. Les passkeys sont liées au domaine de connexion et ne peuvent pas partir, et ni les secrets de second facteur ni les secrets propres au service ne sont exportés : les personnes les configurent à nouveau. Preuve : les clauses 7.2 et 7.3 des conditions.
Que se passe-t-il quand EAuth est en panne ?
Les access tokens déjà émis restent valables jusqu'à leur expiration, 15 minutes par défaut, puisque votre application les vérifie avec nos clés publiques sans nous interroger. Ensuite, les refresh échouent, et les nouvelles connexions échouent jusqu'au retour d'EAuth. Les conditions le disent en toutes lettres (4.7), tout comme le fait qu'il n'y a ni contrat de niveau de service ni engagement de disponibilité (4.1). Si quelques minutes de blocage ne sont pas acceptables, nous pouvons allonger la durée de vie de vos access tokens, ou vous faites tourner EAuth sur vos propres serveurs (4.8, section 11).
Ce qui rend une panne moins probable : deux nœuds applicatifs et deux points d'entrée dans des pays différents, et trois nœuds de base de données en réplication synchrone, si bien qu'une écriture n'est confirmée qu'une fois que les deux réplicas l'ont. La page de statut status.elchi.dev montre l'état actuel ; la disponibilité mesurée y sera publiée une fois qu'un mois complet aura été mesuré, pas avant. Une panne de plus de 30 minutes donne lieu à une note sur sa cause dans ce journal (4.9).
Prenez-vous en charge le single sign-on avec notre fournisseur d'identité ?
SAML 2.0 par organisation, avec des requêtes par redirection HTTP, comme le font Entra ID, Okta et Google Workspace. Les signatures sont vérifiées par une bibliothèque maintenue avec le certificat que vous avez configuré, chaque réponse doit correspondre à une requête venue du même navigateur et n'est acceptée qu'une fois, et l'adresse affirmée doit appartenir au domaine vérifié de l'organisation. Les réponses qu'un fournisseur envoie sans qu'on les lui demande sont refusées. Il n'y a pas de SCIM : les comptes apparaissent à la première connexion. Preuve : docs.elchi.dev/enterprise-sso.
Y a-t-il eu un audit de sécurité indépendant ?
Non. Les conditions le disent (9.2, annexe C.6), et quand un audit aura lieu, le résultat sera publié, quel qu'il soit. Il n'y a pas non plus de rapport SOC 2 ni de certificat ISO 27001. Si un questionnaire exige un oui ici, nous ne pouvons pas le donner aujourd'hui, et je préfère que vous l'appreniez de nous plutôt que de l'auditeur que vous mandatez.
Comment sommes-nous informés des changements ?
Une modification importante des conditions est annoncée 30 jours à l'avance par mail et dans le changelog (14.1), un nouveau sous-traitant 30 jours à l'avance (8.5), et un changement qui casse les intégrations 90 jours à l'avance, sauf si un problème de sécurité impose un délai plus court (2.3). Chaque mail d'annonce est enregistré, si bien que l'on peut prouver que le préavis a été donné. Le passage de l'issuer d'auth.elchi.dev à eauth.me le 3 octobre 2026 n'a demandé aucun préavis : ce jour-là, chaque application enregistrée auprès d'EAuth appartenait à Elchi Studios (2.4). Preuve : ces clauses, et docs.elchi.dev/changelog.
Ce qui va dans la colonne des preuves
La clause avec la version : « EAuth terms 1.7, Annex C.1 ». Une équipe de sécurité peut comparer une clause versionnée au texte publié, et la réponse reste vraie pour la version que vous avez citée. Un lien vers une page de fonctionnalités prouve seulement que quelqu'un l'a écrite.
Sources
- EAuth Terms of Service, Elchi Studios, consulté le
- Security, EAuth documentation, Elchi Studios, consulté le
- RFC 9700: Best Current Practice for OAuth 2.0 Security, IETF, consulté le
- RFC 7636: Proof Key for Code Exchange by OAuth Public Clients, IETF, consulté le
- RFC 9207: OAuth 2.0 Authorization Server Issuer Identification, IETF, consulté le
Écrit par Samuel Krauss, Founder. Classé sous eauth, security, enterprise, gdpr.
Traduit de l’anglais. Lire l’original anglais