IndieAuth für eine persönliche Website — Die eigene URL als Login Geschrieben von Adam Muiz 09 Aug 2026 Aktualisiert: 09 Aug 2026 7 Min. gelesen Eine Anmeldung bedeutet meistens, dass wir unsere Identität von einer großen Plattform leihen. Eine Schaltfläche mit der Aufschrift „Continue with Google“ ist bequem, macht aber unauffällig die Domain eines anderen zum Eingang unseres digitalen Lebens. Wer eine persönliche Website betreibt, empfindet diese Anordnung irgendwann als verkehrt: Warum sollte ein gemietetes Profil beweisen, wem das eigene Zuhause gehört? IndieAuth bietet eine andere Antwort. Das Protokoll lässt eine persönliche Website als Identität auftreten, während im Hintergrund weiterhin ein vertrauenswürdiger Authorization Service genutzt werden kann. Die Idee klingt abstrakt, ist aber praktisch: Die eigene URL wird zum Namen gegenüber kompatiblen Anwendungen, und man entscheidet selbst, welche Dienste sich damit verbinden dürfen. Was IndieAuth tatsächlich leistet IndieAuth ist eine auf OAuth 2.0 aufgebaute Identity Layer. Statt eine E-Mail-Adresse einzugeben oder ein soziales Netzwerk auszuwählen, trägt eine Person eine Website-URL wie https://example.com/ ein. Die Anwendung entdeckt die von dieser Website angegebenen Authorization Endpoints, leitet den Browser dorthin und erhält schließlich einen Nachweis darüber, dass die Person die URL kontrolliert. Man kann es sich so vorstellen, als würde man die eigene Wohnadresse als Identität verwenden und einen bestimmten Schlüsseldienst zur Prüfung des Schlüssels auswählen. Das Haus bleibt das eigene, selbst wenn der Schlüsseldienst gewechselt wird. Ebenso sind Identity URL und Authorization Server getrennte Bestandteile. Ein Provider-Wechsel oder späteres Self-Hosting ist möglich, ohne dass jede kompatible Anwendung eine neue Identität kennenlernen muss. IndieAuth ist kein Password Manager, kein universeller Ersatz für jedes Login-System und keine Erlaubnis für eine Anwendung, die gesamte Website auszulesen. Es ist ein Protokoll für Authentication und Delegated Authorization. Der angeforderte Scope bestimmt, was eine Anwendung tun darf; ein Access Token repräsentiert diese Erlaubnis. Die Discovery Links auf der Homepage Ein Client muss wissen, wo der Ablauf beginnt. Die Homepage liefert diese Information über HTML-Elemente vom Typ <link>. Eine minimale Einrichtung verweist auf einen Authorization Endpoint und einen Token Endpoint. Diese Endpoints können auf der eigenen Domain liegen oder von einem vertrauenswürdigen Provider betrieben werden. <link rel="authorization_endpoint" href="https://auth.example.net/auth"> <link rel="token_endpoint" href="https://auth.example.net/token"> Diese Links gehören in den <head> des Dokuments. Manche Deployments liefern zusätzlich entsprechende HTTP-Link-Header aus, doch sichtbare HTML Discovery lässt sich beim Einstieg einfacher prüfen. Überall sollte HTTPS verwendet werden; Redirects müssen deterministisch sein und die Canonical URL sollte mit oder ohne abschließenden Schrägstrich konsistent aufgelöst werden. Die genaue Konfiguration hängt vom Authorization Server ab. Ein Hosted Service kann eine Bestätigung der Domain über einen Link oder Provider-spezifische Metadaten verlangen. Ein selbst betriebener Server kann explizite Regeln für Redirect URI und Client benötigen. Die aktuelle Spezifikation steht unter https://indieauth.spec.indieweb.org/; maßgeblich sind sie und die Dokumentation des Providers, nicht die wörtliche Übernahme beispielhafter Endpoints. Ein Login von Anfang bis Ende Angenommen, man möchte sich bei einem IndieAuth-kompatiblen Reader anmelden. Zuerst wird die persönliche URL eingegeben. Der Reader ruft die Homepage ab und entdeckt den Authorization Endpoint. Er erstellt einen Authorization Request mit seiner Client-Kennung, einer exakt festgelegten Redirect URI, einem zufälligen State-Wert, einer Code Challenge und dem gewünschten Scope. response_type=code client_id=https://reader.example/app redirect_uri=https://reader.example/callback state=random-per-request-value code_challenge=derived-pkce-value code_challenge_method=S256 scope=profile Der Browser wechselt zum Authorization Server. Nach der Authentication und Zustimmung leitet der Server mit einem kurzlebigen Authorization Code zurück. Der Reader prüft state und tauscht den Code anschließend mit seinem PKCE Verifier aus. Stimmen alle Werte überein, bestätigt das Ergebnis die authentifizierte URL und kann einen Access Token für den genehmigten Scope enthalten. Der Ablauf ähnelt der Abholung eines Einschreibens. Nur den Ausweis am Schalter zu zeigen reicht nicht; auch Sendungsnummer, Empfänger und Abholnachweis müssen zusammenpassen. OAuth-Parameter führen diese Gegenprüfungen digital durch. Einen davon wegzulassen, weil „die Website klein ist“, entfernt eine Schutzschicht gegen reale Angriffe. Sicherheitsdetails sind nicht optional Der zurückgegebene Wert von state muss immer mit dem vor dem Redirect gespeicherten Wert verglichen werden. Dadurch wird der Callback an die Browser Session gebunden und Login CSRF erschwert. PKCE mit S256 verhindert, dass ein abgefangener Authorization Code ohne Verifier eingelöst werden kann. Redirect URIs müssen exakt übereinstimmen; großzügige Wildcards machen aus einer sicheren Übergabe eine offene Seitentür. Clients müssen außerdem die vom Authorization Server zurückgegebene Identität validieren, statt anzunehmen, sie entspreche der ursprünglich eingegebenen URL. Server sollten kurzlebige Codes ausstellen, Wiederverwendung verhindern, gespeicherte Tokens schützen und verständliche Consent Screens zeigen. Der angeforderte Scope sollte so klein wie möglich sein. Ein Reader, der nur einen User identifizieren muss, benötigt keine Publishing-Berechtigung. Ebenso wichtig ist die Kontrolle über die Domain. Läuft sie ab, wird DNS kompromittiert oder kann ein Angreifer die Website verändern, ist auch die Identität gefährdet. MFA beim Registrar, zuverlässige Verlängerung, ein geschützter Hosting Account und Backups der Discovery-Konfiguration gehören deshalb dazu. Wer die Haustür besitzt, muss weiterhin ihre Scharniere pflegen. Ein vernünftiger Weg zur Einführung Am besten beginnt man als User und baut nicht sofort einen eigenen Authorization Server. Zunächst wählt man einen gepflegten Provider, ergänzt die Discovery Links und testet eine kompatible Anwendung. Auf dem Authorization Screen sollten URL, Client, Redirect-Ziel und Scope kontrolliert werden. Auch eine Ablehnung gehört zum Test. Ein vertrauenswürdiger Flow muss sauber scheitern können und nicht nur erfolgreich sein. Danach sollte die Einrichtung dort dokumentiert werden, wo auch DNS- und Hosting-Notizen liegen. Wichtig sind der aktive Provider, die Methode zur Prüfung der Domain Ownership und der Weg zum Widerruf von Sessions oder Tokens. Eine Recovery Route darf nicht davon abhängen, dass die persönliche Website online ist. Sperrt ein Ausfall den Zugang zu genau dem Dashboard, das für seine Reparatur benötigt wird, ist eine Circular Dependency entstanden. Self-Hosting kann später folgen, wenn sein Nutzen den Aufwand für Patching, Monitoring, Backups und Security Reviews rechtfertigt. Die Kontrolle über das Protokoll verlangt nicht, jede Komponente zu Hause zu betreiben. Bei E-Mail gilt dasselbe: Eine Adresse unter der eigenen Domain bleibt wertvoll, auch wenn ein Spezialist den Mailserver betreibt. Testen statt raten Für den Anfang genügen die gewöhnlichen Browser Developer Tools. Die Homepage muss 200 zurückgeben, die Discovery Links müssen im endgültigen HTML erscheinen und kein Cache darf eine alte Version liefern. Jeder Endpoint sollte über HTTPS geprüft werden. Bei einem Test-Login lohnt sich ein genauer Blick auf Redirect URI und Scope, statt automatisch auf Approve zu klicken. curl -sL https://example.com/ | grep -E \ 'authorization_endpoint|token_endpoint' Dieser Befehl ist nur eine schnelle Discovery-Prüfung und kein Protocol Conformance Test. Sinnvoll sind außerdem Tests mit Abbruch, einem zweiten Browser, abgelaufenen Sessions und widerrufenem Zugriff. Wer den Authorization Server betreibt, sollte fehlgeschlagene Exchanges überwachen, ohne Authorization Codes, Tokens oder andere Secrets zu protokollieren. Gute Logs erklären einen Fehler, ohne Credentials aufzunehmen. Eine Identität, die einen Provider überdauern kann IndieAuth ist nicht deshalb bedeutsam, weil es einen weiteren Login-Button ergänzt, sondern weil es den Schwerpunkt verschiebt. Der dauerhafte Identifier ist eine selbst kontrollierte URL; Provider und Anwendungen werden zu austauschbaren Werkzeugen darum herum. Diese kleine Architekturentscheidung hat ein überraschend menschliches Ergebnis: Eine Online-Identität kann eine eigene Adresse besitzen. Das ist nicht vollkommen reibungslos und keine Magie. Sichere Domain-Verwaltung, sorgfältige OAuth-Validierung, begrenzte Scopes und ein Recovery Plan bleiben unverzichtbar. Wer bereits eine persönliche Website pflegt, findet in IndieAuth dennoch ein sinnvolles nächstes Experiment. Teste es mit einer Anwendung, beobachte jeden Redirect und teile in den Kommentaren, was funktioniert hat oder gescheitert ist, damit andere aus den Details lernen können.
