Sicherheit selbst in der Hand: Profil-Hub und 2FA

Foto: Fabian Irsara · StockSnap (CC0 1.0), via Openverse

Es gibt einen Moment in jedem Produkt, in dem man merkt, dass die Kontoverwaltung heimlich zu einem Flickenteppich geworden ist. Bei uns kam er, als ich einem Nutzer erklären wollte, wo er sein Passwort ändert — und feststellte, dass die Einstellung an einer ganz anderen Stelle lag als seine Benachrichtigungen, die Abo-Übersicht wieder woanders, und die Sicherheitsfunktionen praktisch gar nicht auffindbar waren. Jede dieser Seiten war für sich sinnvoll. Zusammen ergaben sie kein Bild.

Diese Woche geht es deshalb um etwas, das nach außen unspektakulär wirkt und intern eine Menge Aufräumarbeit war: Wir haben die Kontoverwaltung an einer Stelle gebündelt und den Nutzern Werkzeuge gegeben, mit denen sie ihre eigene Sicherheit in die Hand nehmen können — ohne den Umweg über unseren Support.

Ein Hub statt verstreuter Seiten

Der neue Ausgangspunkt ist ein Profil-Hub unter /profile. Statt die Kontoverwaltung über das ganze Produkt zu verteilen, führt diese eine Seite acht Bereiche zusammen: von den persönlichen Stammdaten über Sicherheit und Zwei-Faktor-Authentifizierung bis hin zu Abonnements, Benachrichtigungen und der Zugehörigkeit zu Organisationen. Jeder Bereich ist eine eigene Kachel, und jede Kachel ist eine klar umrissene Aufgabe.

Die Entscheidung, es als Hub und nicht als eine einzige lange Einstellungsseite zu bauen, war bewusst. Eine endlose Formularwüste hätte dasselbe Problem in neuer Verpackung geschaffen — man scrollt, verliert den Überblick und findet trotzdem nichts. Acht Kacheln geben dagegen sofort eine mentale Landkarte: Man sieht auf einen Blick, was es alles gibt, und wählt gezielt aus. Der Hub beantwortet die Frage „Wo stelle ich das ein?“, bevor sie überhaupt entsteht.

Zwei-Faktor-Authentifizierung ohne Umweg

Der Bereich, an dem am meisten Arbeit hing, ist die Sicherheit — und dort insbesondere die Zwei-Faktor-Authentifizierung. Bisher war so etwas bei uns eher ein Fall für ein Support-Ticket: Man schrieb uns, wir schalteten etwas frei, es dauerte. Das ist genau die Art von Reibung, die dazu führt, dass Sicherheitsfunktionen ungenutzt bleiben. Eine 2FA, die man erst beantragen muss, aktiviert kaum jemand.

Deshalb ist die Zwei-Faktor-Authentifizierung jetzt vollständig Self-Service. Nutzer aktivieren sie selbst, direkt im Profil-Hub, ohne dass ein Mensch bei uns eingreifen muss. Der Ablauf ist der erwartbare: Man richtet einen Authenticator ein, verifiziert einmal einen Code, und ab dann ist der zweite Faktor scharf. Was technisch simpel klingt, verschiebt die Verantwortung an die richtige Stelle — zum Nutzer, der seine Sicherheitsstufe selbst bestimmt, statt darauf zu warten, dass wir sie ihm freischalten.

Dass wir das über Auth0 als Identity-Layer abbilden, hilft an dieser Stelle: Die eigentliche Faktor-Verwaltung liegt bei einem gehärteten Anbieter, und wir konzentrieren uns auf die Oberfläche und den Zustand im eigenen Modell. Der Self-Service-Charakter ist dabei kein Nebeneffekt, sondern das eigentliche Ziel.

Warum Self-Service das Leitprinzip ist

Hinter beiden Bausteinen steckt derselbe Gedanke, und er ist mir wichtig genug, ihn auszuformulieren: Sicherheit und Kontrolle gehören in die Hand der Nutzer. Jede Funktion, die nur über uns läuft, ist eine Funktion, die langsamer ist, als sie sein müsste, und die eine Abhängigkeit schafft, die niemand will — weder wir noch die Nutzer.

Self-Service bedeutet nicht, Verantwortung abzuschieben. Es bedeutet, die Werkzeuge so zu bauen, dass die naheliegende Handlung auch die sichere ist. Ein Profil-Hub, der die Sicherheitsoptionen sichtbar macht, und eine 2FA, die man in einer Minute selbst aktiviert, tun genau das. Sie machen den sicheren Weg zum bequemen Weg.

Foto: Negative Space · StockSnap (CC0 1.0), via Openverse

Der schwierige Fall: Austreten, wenn ein Abo läuft

Der interessanteste Teil dieser Woche war nicht die 2FA, sondern eine Frage, die harmlos klingt und es nicht ist: Was passiert, wenn jemand eine Organisation verlassen will, für die noch ein Abonnement läuft?

Die naive Antwort — sofort austreten, Abo weg — ist falsch. Der Nutzer hat für den laufenden Zeitraum bezahlt. Ihn sofort hinauszuwerfen, würde bedeuten, ihm etwas wegzunehmen, das er bereits erworben hat. Umgekehrt darf ein angekündigter Austritt aber auch nicht einfach folgenlos bleiben, denn dann würde niemand je wirklich gehen. Zwischen diesen beiden Fehlern liegt die eigentliche Aufgabe.

Wir lösen das, indem der Austritt nicht als sofortige Aktion, sondern als geplantes Ereignis modelliert wird. Das Membership-Modell hat dafür zwei neue Felder bekommen: LeaveScheduledAt hält fest, wann ein Nutzer den Austritt angestoßen hat, und EffectiveAt, wann er tatsächlich wirksam wird. Zwischen diesen beiden Zeitpunkten bleibt die Mitgliedschaft aktiv — der Nutzer behält seinen Zugang für genau die Zeit, für die er bezahlt hat.

Zwei Systeme, die im Takt bleiben müssen

Der Kern der Sache ist, dass hier zwei Wahrheiten zusammenpassen müssen: der Zustand der Mitgliedschaft in unserer Datenbank und der Zustand des Abonnements bei Stripe. Wenn die beiden auseinanderlaufen, entsteht genau das, was man nie will — jemand bezahlt weiter, obwohl er gegangen ist, oder verliert Zugang, den er noch hätte.

Der Ablauf ist deshalb bewusst zweistufig. Wird ein Austritt geplant, kündigen wir das Abonnement nicht sofort, sondern setzen es über SetCancelAtPeriodEnd auf „endet zum Periodenende“. Stripe führt die Leistung bis zum Ablauf der bezahlten Periode fort und stellt dann von selbst keine neue Rechnung. Erst wenn diese Periode ausläuft, wird der Austritt final — und zwar nur dann, wenn er auch tatsächlich geplant war. Diese letzte Bedingung klingt pedantisch, ist aber entscheidend: Sie verhindert, dass ein Periodenende, das aus einem ganz anderen Grund eintritt, versehentlich jemanden aus einer Organisation entfernt, der gar nicht gehen wollte. Der Übergang zum Status „ausgetreten“ passiert ausschließlich auf Grundlage eines vorher gesetzten Plans.

Das ist eine dieser Stellen, an denen die richtige Lösung deutlich mehr Code kostet als die falsche. Ein sofortiges Löschen wären zwei Zeilen. Ein geplanter Austritt mit sauberer Abo-Kopplung ist ein Zustandsmodell mit zwei Zeitstempeln, ein bedingter Finalisierungsschritt und die Disziplin, den Stripe-Zustand und den eigenen Zustand nie unabhängig voneinander anzufassen. Es ist die Mühe wert, weil hier echtes Geld und echtes Vertrauen im Spiel sind.

Wie sich das für Nutzer anfühlt

Aus der Vogelperspektive ergibt das ein stimmiges Bild. Der Profil-Hub ist die Landkarte, über die man alles findet. Die Self-Service-2FA ist das erste konkrete Versprechen dieser Landkarte: Sie bestimmen Ihre Sicherheit selbst. Und der geplante Austritt ist derselbe Gedanke, angewendet auf einen unbequemen Moment — selbst das Gehen bleibt in der Hand des Nutzers, fair abgewickelt und ohne dass er etwas verliert, wofür er bezahlt hat.

Kein Teil davon ist besonders vorzeigbar. Es sind keine Funktionen, mit denen man auf einer Startseite wirbt. Aber es sind genau die Dinge, die entscheiden, ob ein Produkt sich vertrauenswürdig anfühlt oder nicht — und die man am ehesten dann vermisst, wenn sie fehlen.

Was kommt als Nächstes?

Nächste Woche: Motivation, die zurückbringt — ein gestuftes Achievement- und Badge-System.