Login für eine Schweizer Web-App ohne US-Cloud
Was Sie prüfen sollten, bevor Sie das Login Ihrer Nutzer einem Provider übergeben, und wie EAuth antwortet: Standort, Export, Vertrag, die Ausnahme.
Bauen Sie in der Schweiz eine Webanwendung und überlassen das Login einem Provider, liegen die E-Mail-Adressen und Passwort-Hashes Ihrer Nutzer dort, wo dieser Provider liegt. Bei den meisten bekannten ist das eine US-Firma, unter US-Recht, auf Servern, die Sie nicht auswählen. Das ist nicht automatisch ein Problem. Es ist eine Frage, die Ihre Datenschutzerklärung beantworten muss und die ein Firmenkunde vor der Unterschrift im Sicherheitsfragebogen stellt.
Wir betreiben EAuth, einen OpenID-Connect-Provider, aus der Schweiz, unter eauth.me. Dieser Beitrag ist die Checkliste, mit der ich jeden Login-Provider beurteilen würde, unseren eingeschlossen, jeweils mit dem, was EAuth bei jedem Punkt tut. Dazu gehört auch der eine Punkt, bei dem unsere Antwort nicht „nur Europa“ lautet.
Wo die Server stehen und wer sie betreibt
Fragen Sie nach den Servern und den Firmen dahinter, nicht nach einem Siegel. Seit dem 3. Oktober 2026 läuft EAuth auf unserem eigenen Cluster: acht Server bei fünf Providern in vier Ländern.
- Zwei Eingänge, an denen die verschlüsselte Verbindung von einem Browser endet: Hetzner in Falkenstein und UpCloud in Amsterdam. Fällt einer aus, übernimmt der andere den Verkehr.
- Zwei Anwendungsknoten, die beide gleichzeitig Logins bedienen: Infomaniak in Genf und Scaleway in Amsterdam.
- Drei PostgreSQL-Knoten: Tavuru in Frankfurt, Hetzner in Nürnberg und Scaleway in Paris. Die Replikation auf beide Replikate ist synchron, eine Änderung gilt also erst als geschrieben, wenn alle drei sie haben.
- Ein Wächter bei Infomaniak in Genf, der die anderen von aussen prüft.
Profilbilder und Logos liegen im Object Storage bei Infomaniak, mit einer nächtlichen Kopie bei Scaleway. Vor nichts davon sitzt der Proxy eines Dritten: Die Verbindung von einem Browser endet an einem Eingang, den wir betreiben, und läuft von dort über unser eigenes verschlüsseltes Netz zwischen den Knoten. Jede Verbindung nutzt TLS 1.3 und nichts Älteres, und die Domains senden HSTS mit Preload.
Zwei DNS-Dienste sehen Namensauflösungen und sonst nichts: Cloudflare hält unsere Zonen, und ClouDNS beantwortet den einen Namen, der auf die jeweils gesunden Eingänge zeigt. Keiner von beiden sieht eine Anfrage oder ein Login.
Die Ausnahme: Mail
EAuth verschickt Mail: den Link, der eine Adresse bestätigt, das Zurücksetzen des Passworts, Einladungen, die Meldung, dass ein Passkey hinzugefügt wurde. Diese Mail geht über Resend hinaus, eine US-Firma. Unser Versand ist auf deren EU-Region eingestellt, die Resend in Irland betreibt, aber die eigene Dokumentation von Resend sagt, dass Kontodaten unabhängig von der Region in den USA bleiben. Die Adresse des Empfängers und der Text jeder Mail laufen also durch eine US-Firma.
Seit dem 3. Oktober ist das kein Randfall mehr. Keine Anwendung bekommt ein Konto, dessen Adresse nicht bestätigt ist, also erhält jedes neue Konto mindestens eine Mail über Resend. Das sollen Sie lieber hier lesen, als es in einer Antwort auf einen Fragebogen zu finden.
Was gespeichert wird, und wie
Fragen Sie, was die Datenbank enthält und in welcher Form. EAuth speichert Passwort-Hashes mit Argon2id (64 MiB Speicher, drei Iterationen), Refresh Tokens, Codes und Wiederherstellungscodes nur als SHA-256-Digests und Signaturschlüssel sowie Zugangsdaten von Dritten verschlüsselt mit AES-256-GCM, unter einem Schlüssel, der nicht in der Datenbank liegt. Ein Dump davon liefert Chiffretext und Digests.
Sessions halten Browser und Plattform fest, „Firefox on Windows“, nie den rohen User-Agent-Header, und das Land als zwei Buchstaben, nie eine IP-Adresse. Die Rate Limits halten eine Adresse nur so lange, wie ihr Zeitfenster dauert. Die vollständige Liste dessen, was wie lange verarbeitet wird, ist Anhang A der AGB: sieben Zeilen in einer Tabelle.
Was Sie mitnehmen können
Hier sind die meisten Provider am schwächsten. Fragen Sie: Wenn ich gehe, müssen meine Nutzer dann ihre Passwörter zurücksetzen?
Bei EAuth lautet die Antwort Nein. Die Konsole exportiert eine Anwendung mit ihren Nutzern, Organisationen und Einstellungen als JSON, jederzeit und ohne uns zu fragen, und der Export enthält die Passwort-Hashes in ihrer ursprünglichen Form: Argon2id für alle, die sich bei uns angemeldet haben, oder den Hash, mit dem sie importiert wurden, falls nicht. Ein Provider, der Argon2id annimmt, kann sie importieren, und Ihre Nutzer melden sich an wie bisher. Dasselbe funktioniert in die andere Richtung: EAuth importiert Argon2id, bcrypt, scrypt und PBKDF2-SHA256 und ersetzt jeden davon beim nächsten Login der Person durch Argon2id.
Gehen zu können, halte ich für ein Feature. Ein Provider, der die Hashes Ihrer Nutzer als Geiseln hält, bietet keinen Dienst an, sondern eine Pacht.
Was der Vertrag sagt
Ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO und dem Schweizer DSG ist kein zusätzliches Dokument, über das verhandelt werden muss. Er ist Anhang B der AGB von EAuth und gilt, sobald Sie ein Konto haben. Die AGB sagen, dass Daten nur in der Schweiz und im Europäischen Wirtschaftsraum verarbeitet werden, was wie lange aufbewahrt wird, dass jede Version mit Datum veröffentlicht bleibt, dass eine wesentliche Änderung 30 Tage vorher angekündigt wird, dass auch ein neuer Unterauftragsverarbeiter 30 Tage vorher angekündigt wird und dass noch kein unabhängiges Sicherheitsaudit durchgeführt wurde. Dieser letzte Satz steht dort, weil Sie sonst das Gegenteil annehmen könnten.
Lesen Sie die Klausel zur Datenübermittlung neben dem Abschnitt über Mail oben. Die Versandregion der Mail liegt in der EU; die Firma, die sie betreibt, nicht, und das ist die Lücke, die ich genannt habe.
Was die Technik ohnehin leisten muss
Der Datenstandort ersetzt die Grundlagen nicht. Welchen Provider Sie auch wählen, er sollte PKCE bei jeder Authorization-Anfrage verlangen, Redirect-URIs exakt abgleichen, Refresh Tokens bei jeder Nutzung rotieren und die ganze Kette beenden, wenn ein rotiertes Token erneut vorgelegt wird, Passkeys und einen zweiten Faktor anbieten und jeden Passwortversuch pro Adresse und pro Konto zählen, bevor er geprüft wird. Er sollte sich auch weigern, Ihrer Anwendung ein Konto zu geben, dessen E-Mail-Adresse niemand bestätigt hat: Eine unbestätigte Adresse ist ein Name, den jeder eintippen könnte. EAuth tut all das, und email_verified ist in seinen ID-Tokens immer true. Anhang C der AGB listet die Massnahmen so auf, wie sie umgesetzt sind, mit ihren Zahlen.
Die Limits
Die Limits sind für jede Anwendung gleich: 25 Anwendungen pro Konto, 20 Redirect-URIs pro Anwendung und 120 Token-Anfragen pro Minute und Anwendung, die ein Entwickler in der Konsole auf 600 erhöht. Brauchen Sie mehr, fragen Sie, und wir erhöhen. Ein Service Level Agreement gibt es nicht: Ziffer 4.1 der AGB sagt das in einem Satz, denn eine Zahl, für die wir nicht einstehen können, ist schlechter als keine.
Was noch nicht fertig ist
EAuth wurde nicht von einer unabhängigen Stelle auditiert. Die Statusseite unter status.elchi.dev ist online, und die gemessene Verfügbarkeit des Clusters kommt darauf, sobald ein ganzer Monat gemessen ist; bis dahin gibt es keine Zahl zum Zitieren, und ich werde keine nennen. Beides wird hier berichtet, sobald es so weit ist, egal mit welchem Ergebnis.
Quellen
- Federal Act on Data Protection (FADP), Swiss Confederation, gelesen am
- Art. 28 GDPR, Processor, gdpr-info.eu, gelesen am
- Password Storage Cheat Sheet, OWASP, gelesen am
- Choosing a Region, Resend, gelesen am
- RFC 9700: Best Current Practice for OAuth 2.0 Security, IETF, gelesen am
- HSTS Preload List Submission, hstspreload.org, gelesen am
Geschrieben von Samuel Krauss, Founder. Abgelegt unter eauth, hosting, data-protection, switzerland.
Übersetzt aus dem Englischen. Zum englischen Original