Aber, aber, aber Auth ist haaRrRrrrrRrd

Nein, ist es nicht. Es ist langweilig, bürokratisch, ein gelöstes Problem... aber nennen Sie es nicht pauschal schwierig.

Ich bin „Ich habe MD5 verwendet, um Passwörter in PHP zu hashen“ Jahre alt. Sicher, es war eine schreckliche Idee, sogar damals im Jahr 2012. Aber ich kann mich nicht erinnern, dass ich damals Authentifizierung als „schwierig“ betrachtet habe. Es war an sich eine ziemlich einfache Angelegenheit – eine E-Mail-Adresse oder einen Benutzernamen besorgen, ein Passwort besorgen, es hashen (mit MD5, wie „Gott es vorgesehen hat“), und wenn Sie besonders sicherheitsbewusst sind, [ salzen ] Sie das Passwort. Speichern Sie das alles irgendwo, normalerweise in einer Datenbank. Tada, Anmeldung erledigt.

Heutzutage hat sich die Erzählung geändert. „Authentifizierung ist schwer“ scheint eine allgegenwärtige Erzählung zu sein, die nur einen Klick bei HackerNews oder Reddit entfernt liegt. Aber ist sie das wirklich? Meiner Meinung nach ist die Wahrheit, dass Authentifizierung nicht schwer zu erstellen ist – jeder kann es lernen (und jeder in dieser Branche sollte die Grundlagen lernen). Die wahre Herausforderung liegt in den Extras: MFA, Benutzerverwaltung, Kennwortzurücksetzungen, jeder der Hunderten von OAuth-Anbietern und Kontozusammenführungen von verschiedenen Anbietern. Es ist der Tod durch tausend Schnitte. Da Authentifizierung ein gelöstes Problem ist, ist es nicht die beste Nutzung Ihrer Zeit, das Rad neu zu erfinden. Aber das bedeutet nicht, dass „Authentifizierung ist schwer“ als pauschale Aussage richtig oder auch nur annähernd richtig ist. Sie sollten experimentieren, die Grundlagen verstehen und von dort aus aufbauen. Die Komplexität wächst nur mit dem Umfang (oder potenziellen Umfang) dessen, was Sie erstellen.

Wie schwierig kann Authentifizierung also wirklich sein? Lassen Sie uns tiefer eintauchen.

In den Tagen von einst ...

Um dort weiterzumachen, wo ich die Geschichte über PHP und MD5 aufgehört habe. Das Erstellen einer Anmeldefunktionalität folgte einer ähnlichen Reihe von Schritten: Besorgen Sie sich eine E-Mail-Adresse und ein Kennwort, prüfen Sie, ob die E-Mail-Adresse in Ihrem Speicher vorhanden ist, hashen Sie das Kennwort zusammen mit dem für diese E-Mail-Adresse gespeicherten Salt, vergleichen Sie den resultierenden Hash mit dem in der Datenbank gespeicherten und setzen Sie, wenn alles gut geht, über setcookie ein Cookie (wir sind hier immer noch im PHP-Land – nicht, dass die Gesamtlogik in anderen Ökosystemen allzu anders wäre).

Das Abmelden war sogar noch einfacher – machen Sie einfach das Cookie auf dem Server ungültig und fertig. Wenn der Server bei der nächsten Anfrage kein Cookie sieht, sind Sie nicht angemeldet. Auch das Erstellen authentifizierter Routen war also insgesamt eine einfache Angelegenheit. Bei den Berechtigungen konnte es brenzlig werden, aber bei den Apps, die ich erstellen musste, hatten wir meistens nur Administratoren und Benutzer. Das war etwas, das Sie einfach zusammen mit dem Benutzerdatensatz oder in einer Berechtigungstabelle speichern konnten, falls Sie jemals die Anzahl der Rollen für Ihre App erweitern mussten.

Vollständige Offenlegung: Ich arbeite für SuperTokens . Dieser Artikel ist jedoch aus persönlicher Frustration über die allgegenwärtige Erzählung entstanden, wie schwierig die Authentifizierung als pauschale Aussage ist. Mit anderen Worten: Ich versuche nicht, Ihnen „mein Ding zu verkaufen“. Verwenden Sie, was Sie wollen.

Selbst drehen - eine „moderne“ Variante

E-Mail/Passwort und Social Auth

Um dahin zu gelangen, wo wir heute sind, beginnen wir am Anfang... Überraschend, ich weiß. Wir können uns wahrscheinlich darauf einigen, dass diese Komponenten ausreichen, um einen PoC für E-Mail/Passwort + Social Login zu erstellen:

1. Ein Server, der Routen verwaltet – Anmeldung, Anmeldung, Abmeldung …
2. Eine Art Speicher zum Aufbewahren der Benutzerdatensätze (ein In-Memory-Array funktioniert auch)
3. Ansichten – Anmelde-, Registrierungs- und authentifizierte „Dashboard“-Bildschirme.
4. Handler für Social Auth

Da wir das Rad nicht neu erfinden wollen, kommen wir mit Express und Passport auf genau 150 Zeilen sehr, sehr langweiligen und sich wiederholenden Code: https://github.com/supertokens/auth-express/blob/master/index.mjs . Der nächste Abschnitt wird eine oberflächliche Erklärung dessen sein, was im Code vor sich geht. Sie können also ruhig weiterspringen , wenn Sie mit den Konzepten bereits vertraut sind. Die Express-App ist ohnehin ein PoC.

Lassen Sie es uns kurz analysieren:

Inhalte auf dem Bildschirm rendern

So wie ich das sehe, gibt es zwei Möglichkeiten, das anzugehen: mit dem Rendering beginnen und dann zur Authentifizierung übergehen oder umgekehrt. Größtenteils durch Zufall bin ich zu einem FE-lastigen Pöbel geworden (ich kann immer noch SQL, falls Sie sich das fragen), also werde ich mit dem Ansatz „Dinge auf dem Bildschirm rendern“ beginnen.

Da dies ein PoC ist, werden wir nicht alles auf React-Fancy setzen. Einfaches SSR mit EJS reicht völlig aus: https://github.com/supertokens/auth-express/tree/master/views

Routen hinzufügen

Basierend auf einigen Beispielen von passport.js , aber weiter vereinfacht, benötigen wir Folgendes:

1. Einige Abhängigkeiten: npm i passport passport-local express-session . Lassen Sie uns kurz alle durchgehen:

   1. Passport.js – die OG-Authentifizierungs-Middleware für Express und Node.
   2. passport-local – eine Authentifizierungsstrategie für Passport; Eine Authentifizierungsstrategie in einem Modul, das den Authentifizierungsprozess für eine bestimmte Authentifizierungsmethode handhabt – in diesem Fall eine lokale Anmeldung mit einem Benutzernamen (E-Mail) und einem Passwort.
   3. express-session – eine Middleware, die Sitzungsdaten verwaltet und es Ihnen ermöglicht, Benutzersitzungen zwischen HTTP-Anfragen zu speichern und beizubehalten. Dies funktioniert, indem jedem Client eine eindeutige Sitzungs-ID zugewiesen wird, die in einem Cookie auf der Clientseite gespeichert und zum Abrufen von Sitzungsdaten auf dem Server verwendet wird.

2. Ein Ort zum Speichern unserer Benutzer (das oben verlinkte Beispiel verwendet ein In-Memory-Array): https://github.com/supertokens/auth-express/blob/master/index.mjs#L13

3. Konfiguration für unsere Passport-Instanz und unsere LocalStrategy-Instanz zur Verarbeitung eingehender Anfragen zur Benutzersuche: https://github.com/supertokens/auth-express/blob/master/index.mjs#L18

4. Initialisieren Sie Passport ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L60 ) und Express-Session ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L69 ).

Ausführlich, klar. Schwer? Das glaube ich nicht, zumindest nicht im Sinne von „als Spielzeug implementieren“. Aber wir haben uns schon vor einiger Zeit von der Verwendung von E-Mail/Passwort-Kombinationen verabschiedet. Sehen wir uns an, wie schwer es ist, zusätzlich zu dem, was wir bereits haben, einen sozialen Anbieter hinzuzufügen.

Ich habe mich aus einem einfachen Grund für GitHub als Beispielanbieter entschieden: Wenn Sie sich dazu entschließen, den ganzen Prozess zu verfolgen, ist es einer der Anbieter, bei dem der Einstieg am einfachsten ist (ich schaue auf Sie, Google).

Wenn Sie sich dazu entschließen, dem Vorgang vollständig zu folgen, finden Sie hier einen Link mit einer Beschreibung, wie Sie diese GitHub-Schlüssel erhalten: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app . Oh, und übrigens, falls Sie sich Sorgen machen: Die Schlüssel im Repo sind nicht gültig ;)

Integration von GitHub OAuth2 in unseren PoC

Zunächst benötigen wir noch eine weitere Abhängigkeit: npm i passport-github2 . passport-github2 ist eine Authentifizierungsstrategie für Passport, die uns die Integration mit der OAuth2-API von GitHub ermöglicht.

Einige Handler ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L122-L133 ) und Konfigurationen ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L29-L45 ) später, nun, das war’s. Kompliziert? Wahrscheinlich nicht. Bürokratisch? Aber sicher. Langweilig? Absolut. Vor allem, wenn Sie es immer wieder tun müssen. Es ist ein gelöstes Problem; das Rad neu zu erfinden ist oft nicht die beste Nutzung der Zeit, wie wir festgestellt haben.

Die große Idee

Mittlerweile sind wir uns wahrscheinlich einig, dass Auth nicht schwer zu erstellen ist. Es handelt sich also nicht um ein magisches Ding, das nur weißbärtige Zauberer verstehen und implementieren können, die die mystische Sprache der JWTs sprechen.

Nein, ich würde sogar argumentieren, dass man als Entwickler die grundlegenden Grundlagen der Authentifizierung verstehen sollte. Und ich höre oft eine Erzählung, die das Gegenteil behauptet – so etwas wie „Vertrau mir, Bruder, wir können das für dich erledigen“. Und natürlich stimme ich zu, dass es größtenteils Zeitverschwendung ist, eine eigene Authentifizierung zu erstellen. Aber es ist nicht so schwer zu erstellen und sicherlich keine mystische Sache. Wirklich haarig wird es bei allem, was mit der Authentifizierung und der Benutzererfahrung zusammenhängt.

Bedenken Sie Folgendes: Im obigen Beispiel haben wir eine funktionierende Authentifizierungsfunktion. Mehr oder weniger. Aber Folgendes kann sie nicht (wird auch im Artikelanfang erwähnt):

• 2FA, MFA
• Passwort zurücksetzen
• Jeder einzelne der Hunderten von OAuth-Anbietern mit seinen Besonderheiten
• Benutzerverwaltung
• Kontozusammenführungen verschiedener Anbieter
• Decken Sie alle möglichen Randfälle und potenziellen Sicherheitslücken ab
• ...und ich könnte weitermachen

Wir können wahrscheinlich jeden dieser Schritte umsetzen. Und für sich genommen mag jeder Schritt einfach erscheinen. Aber es summiert sich. Es geht also nicht unbedingt um die Umsetzung – es geht darum, sie zu warten, dafür verantwortlich zu sein, auf dem Laufenden zu bleiben, was Standards, Sicherheitsverletzungen usw. angeht. Und Hand hoch – wie viele von Ihnen lesen gerne RfCs? Ich kann mir nicht vorstellen, dass ich viele erhobene Hände sehen würde, wenn wir bei einem Meetup wären.

Mein Punkt ist, dass Authentifizierung insgesamt nicht einfach ist. Sicher, wir können leicht etwas für einen PoC zusammenschustern, wie wir es oben getan haben. Aber es ist keine Zauberei, es ist nicht unmöglich zu verstehen, und bitte, bitte sagen Sie nicht, dass es das ist. Diese Denkweise (und Marketing) ist meiner Meinung nach schädlich für die gesamte Branche.

Die natürliche Folgefrage wäre also: Wann sollten Sie Ihre eigene Mischung herstellen?

Spielzeugprojekt, Indie und pädagogische Aktivitäten

... auf jeden Fall. Ich würde es sogar empfehlen. Man lernt viel durchs Tun, also warum nicht? Wenn Ihr Indie-/Spielzeugprojekt oder Blog eine beträchtliche Benutzerbasis oder Anhängerschaft hat, wechseln Sie zu einem Dienst, einer selbst gehosteten Lösung oder etwas anderem. Schließlich haben Sie zu diesem Zeitpunkt ein Produkt und Sie werden Ihre Zeit zweifellos besser damit verbringen, dieses Produkt zu erstellen, anstatt die Authentifizierung aufrechtzuerhalten.

Start-ups

Wenn Sie Produkte erstellen, sollten Sie grundsätzlich nicht Ihre eigene Authentifizierung verwenden. Das wäre, als würden Sie das Rad neu erfinden, was sehr langweilig und bürokratisch ist. Sie haben viele Optionen zur Auswahl. Außerdem erstellen Sie ja etwas, oder? Warum führen wir dieses Gespräch überhaupt, wenn Ihr Produkt keine Authentifizierung bietet?

Scaleups und höher (wie auch immer wir sie definieren)

Tun Sie es nicht. Derselbe Grund wie bei Startups – aber hier trifft er sicherlich noch mehr zu.

Sie können wahrscheinlich erkennen, worauf ich hinaus will. „Authentifizierung ist schwierig“ ist meiner Meinung nach ein Marketing-Slogan, wenn man ihn als pauschale Aussage verwendet. Sie können Authentifizierung verstehen, Sie können sie erstellen, aber sie ist langweilig, ihre Wartung macht keinen Spaß und sie ist ein Problem, das gelöst ist. Daher kann sie als eine Ware betrachtet werden – eine, die Sie in jeder gewünschten Variante von der Stange nehmen können (einige Optionen unten).

Die selbstgehostete und FOSS-Landschaft

Für diejenigen, denen der Besitz ihres Stacks am Herzen liegt (wie bei mir), gibt es ebenfalls zahlreiche Optionen zur Auswahl:

Auth-Bibliotheken

• Passport.js, oben ausführlich behandelt
• Lucia – Eine einfache und flexible Authentifizierungsbibliothek für moderne Webanwendungen, mit Schwerpunkt auf Entwicklererfahrung und Benutzerfreundlichkeit.
• Auth.js – Eine leichte und anpassbare Authentifizierungsbibliothek für Node.js, die für die einfache Integration in verschiedene Frameworks und Anwendungen konzipiert ist. Begann als Bibliothek für Next.

Authentifizierungsserver

• Keycloak – Ein Open-Source-Identitäts- und Zugriffsverwaltungsserver, der Funktionen wie Single Sign-On (SSO), Identitätsvermittlung und Benutzerföderation bietet.
• SuperTokens (siehe Haftungsausschluss oben) – Eine Open-Source-Authentifizierungslösung, die vorgefertigte Funktionen wie Sitzungsverwaltung, soziale Anmeldung und E-Mail-/Passwort-Authentifizierung mit Schwerpunkt auf Sicherheit und Einfachheit bietet.
• FusionAuth – Eine flexible Authentifizierungsplattform für Entwickler, die Funktionen wie Benutzerverwaltung, Multifaktor-Authentifizierung (MFA) und Single Sign-On (SSO) bietet.
• Authelia – Ein Open-Source-Authentifizierungsserver, der Multifaktor-Authentifizierung (MFA) und SSO bietet und zum Sichern von Anwendungen mithilfe von Reverse-Proxys entwickelt wurde.

Speicher + Authentifizierung

• Supabase – Eine Open-Source-Backend-as-a-Service-Plattform (BaaS), die Datenbank-, Authentifizierungs- und Echtzeitfunktionen bietet und als Alternative zu Firebase konzipiert ist.
• Pocketbase – Eine Open-Source-Backend-Lösung, die Datenbank, Authentifizierung und Dateispeicher kombiniert und die Entwicklung moderner Web- und mobiler Anwendungen vereinfachen soll.

Auch wenn Sie keine Software von Drittanbietern für die Authentifizierung verwenden möchten, können Sie je nach Ihren Anforderungen und Vorlieben einfach eine Open-Source-Software von der Stange auswählen und damit weiterarbeiten.

Fazit: Authentifizierung ist der „Bürokratismus“ der Entwicklung

Meine „große“ Erkenntnis ist, das Rad nicht neu zu erfinden, insbesondere wenn es sich um ein bereits gelöstes Problem handelt, wie es bei Auth der Fall ist. Informieren Sie sich über die besagten Räder, experimentieren Sie damit, bauen Sie ein Spielzeugrad und verstehen Sie es. Aber bitte, bitte, verkaufen Sie es nicht als etwas, das unmöglich zu verstehen und zu bauen ist. Informieren Sie, seien Sie kein Torwächter.