Stoppen Sie, Passworte als Standard-Authentifizierung zu erstellen_
Warum die meisten Produktteams die Authentifizierung einem Identitätsanbieter delegieren und stattdessen OpenID Connect verwenden sollten, anstatt Passwörter selbst zu verwalten.
Die meisten Teams unterschätzen, was es bedeutet, "Auth zu besitzen".
Es geht nicht nur um ein Login-Formular und eine gehashte Passwort-Spalte. Es umfasst die Kontowiederherstellung, Bot-Schutz, MFA-Registrierung, E-Mail-Verifizierung, Umgang mit kompromittierten Passwörtern, Gerätevertrauen, Erkennung verdächtiger Anmeldungen, Sperrpolitik, Sitzungsmanagement und Incident-Response, wenn schließlich etwas schiefgeht.
Wenn Authentifizierung nicht Ihr Produkt ist, sollten Sie misstrauisch gegenüber jedem Plan sein, der mit "Wir werden einfach `bcrypt`-Hashes selbst speichern" beginnt.
## Das Problem ist nicht das Hashing
Passwort-Hashing ist notwendig. Es ist nicht das ganze Problem.
Ein ernsthaftes Authentifizierungssystem benötigt auch:
- einen sicheren Rücksetzfluss
- Widerstand gegen Credential Stuffing
- Schutz vor Phishing und Session-Fixierung
- Auditierbarkeit im Zusammenhang mit Anmeldeereignissen
- Unterstützung für MFA oder Passkeys
- operationale Prozesse für Support und Wiederherstellung
Teams setzen oft die ersten 20 Prozent um und übernehmen die Verantwortung für die anderen 80 Prozent, ohne es zu bemerken.
## Was OIDC Ihnen tatsächlich bietet
OpenID Connect fügt eine Identitätsschicht über OAuth 2.0 hinzu. In der Praxis ermöglicht es Ihrer Anwendung, sich auf einen Identitätsanbieter wie Google, Microsoft Entra ID, Okta, Auth0, WorkOS oder Clerk zu verlassen, um den Nutzer zu authentifizieren und standardisierte Tokens auszustellen.
Das verändert Ihre Anwendung von:
- Passwörter direkt zu sammeln
- Anmeldeinformationen zu validieren
- Wiederherstellungsflüsse auszuführen
zu:
- den Benutzer zu einem Identitätsanbieter weiterzuleiten
- die zurückgegebenen Tokens zu validieren
- eine Anwendungssitzung zu erstellen
Das ist ein viel besserer Platz für die meisten SaaS-Teams.
## Der Flow, den Sie normalerweise wollen
Für Web-Apps sollte der Standard normalerweise der Authorization Code Flow sein. Wenn der Client eine browserbasierte App ist, verwenden Sie auch PKCE.
Auf einer hohen Ebene:
1. Der Benutzer klickt auf "Anmelden".
2. Ihre App leitet ihn zum Identitätsanbieter weiter.
3. Der Identitätsanbieter authentifiziert den Benutzer.
4. Ihr Backend tauscht den Autorisierungscode gegen Tokens aus.
5. Ihre Anwendung validiert die Tokenansprüche und erstellt ihre eigene Sitzung.
Das wichtige Detail ist, dass Ihr Produkt das Passwort nicht direkt behandeln muss.
## Was Sie weiterhin implementieren müssen
Die Delegation der Authentifizierung beseitigt nicht die gesamte Verantwortung. Sie schränkt sie ein.
Sie müssen weiterhin:
- den Aussteller, die Zielgruppe, das Ablaufdatum und die Signatur korrekt validieren
- `state` und `nonce` dort verwenden, wo es erforderlich ist
- Ihre eigene Anwendungssitzung sicher erstellen und rotieren
- Authentifizierung von Autorisierung trennen
- Benutzer in Ihrer Datenbank mit stabilen Identifikatoren modellieren
Ein häufiger Fehler ist, nur die E-Mail-Adresse als Identität zu speichern. Das ist an sich nicht stabil genug. In OIDC-Systemen ist der langlebige Identifikator normalerweise der Anbieter plus der `sub`-Anspruch.
```ts
type Identity = {
provider: "google" | "microsoft" | "okta";
subject: string;
email: string;
emailVerified: boolean;
};
function getIdentityKey(identity: Identity) {
return `${identity.provider}:${identity.subject}`;
}
Das vermeidet später subtile Fehler beim Verknüpfen von Konten.
Ein besseres mentales Modell
Betrachten Sie OIDC nicht als "soziale Anmeldung".
Betrachten Sie es als Verlagerung einer hochriskanten Funktionalität zu Software, die speziell für Identität entwickelt, geprüft und mit entsprechendem Personal ausgestattet ist.
Das bedeutet nicht, dass jeder Anbieter automatisch gut konfiguriert ist. Es bedeutet, dass die Standardbausteine materiell stärker sind als das, was die meisten Produktteams unter Zeitdruck schaffen.
Wann es sinnvoll ist, es selbst zu bauen
Es gibt Fälle, in denen die eigene Authentifizierung gerechtfertigt ist:
- Sie bauen ein Identitätsprodukt
- Sie haben strenge regulatorische Einschränkungen, die externe Anbieter ausschließen
- Sie benötigen Offline- oder luftdicht isolierte Authentifizierungsmodelle
- Sie haben die interne Sicherheitsreife, um es richtig zu betreiben
Diese Fälle existieren. Sie sind nur seltener, als Ingenieure gerne denken.
Für ein typisches SaaS-Produkt ist die eigentliche Frage nicht "können wir die Authentifizierung selbst bauen?" sondern "warum sollten wir uns entscheiden, diese Haftung zu übernehmen?"
Weitere Lesenswertes
Verwandte Artikel.
Weiterlesen mit eng verwandten Artikeln zu Software Engineering, Architektur und Implementierungs-Trade-offs.
KI-Codegenerierung verändert die Arbeit mehr, als sie den Ingenieur entfernt
LLMs sind am stärksten in der Beschleunigung und im Gerüstbau. Sie sind in der Beurteilung, Architektur und Verantwortung für die Produktionsfolgen schwächer.
Vitest gewinnt in vielen Frontend-Projekten, weil es mit Vite übereinstimmt
Vitest ist in Vite-basierten Anwendungen überzeugend, da es die gleichen Modulannahmen und die Struktur der Toolchain wiederverwendet, was die Reibung bei lokalen Tests verringert.