Auswahl einer Authentifizierungsmethode \/ eines Anbieters<\/h2>\n
Es gibt praktisch 1.000 M\u00f6glichkeiten, die Authentifizierung in deine Anwendung einzubauen. Anstatt uns hier auf bestimmte Anbieter zu konzentrieren (ein Thema f\u00fcr einen anderen Blog-Beitrag), wollen wir uns die Arten von Authentifizierungsl\u00f6sungen<\/strong> und ein paar Beispiele daf\u00fcr ansehen. Was die Implementierung angeht, so wird next-auth<\/a> schnell zu einer beliebten Option, um deine Next.js-Anwendung mit mehreren Anbietern zu integrieren, SSO hinzuzuf\u00fcgen usw.<\/p>\n Diese Variante ist so einfach wie nur m\u00f6glich: Du speicherst Benutzernamen und Passw\u00f6rter in einer relationalen Datenbank. Wenn sich ein Nutzer zum ersten Mal anmeldet, f\u00fcgst du eine neue Zeile in die Tabelle „Nutzer“ mit den angegebenen Informationen ein. Wenn er sich anmeldet, vergleichst du die Anmeldedaten mit denen, die du in der Tabelle gespeichert hast. Wenn ein Benutzer sein Passwort \u00e4ndern m\u00f6chte, aktualisierst du den Wert in der Tabelle.<\/p>\n Die traditionelle Datenbankauthentifizierung ist sicherlich das beliebteste Authentifizierungsverfahren, wenn man sich die Gesamtheit der bestehenden Anwendungen ansieht. Es ist sehr flexibel, billig und bindet dich nicht an einen bestimmten Anbieter. Aber du musst es selbst entwickeln und dich vor allem um die Verschl\u00fcsselung k\u00fcmmern und sicherstellen, dass die Passw\u00f6rter nicht in die falschen H\u00e4nde geraten.<\/p>\n In den letzten Jahren (und, dank Firebase, schon seit einigen Jahren) ist es f\u00fcr Anbieter von verwalteten Datenbanken relativ normal geworden, eine Art verwaltete Authentifizierungsl\u00f6sung anzubieten. Firebase<\/a>, Supabase<\/a> und AWS<\/a> bieten sowohl verwaltete Datenbanken als auch verwaltete Authentifizierung als Service \u00fcber eine Reihe von APIs an, die die Benutzererstellung und Sitzungsverwaltung einfach abstrahieren (mehr dazu sp\u00e4ter).<\/p>\n Die Anmeldung eines Benutzers mit der Supabase-Authentifizierung ist so einfach wie hier dargestellt<\/a>:<\/p>\n Vielleicht noch verbreiteter als die Authentifizierung als Dienst deines DBaaS ist die Authentifizierung als Dienst eines ganzen Unternehmens oder Produkts. Auth0<\/a> gibt es seit 2013 (jetzt im Besitz von Okta), und die j\u00fcngsten Erg\u00e4nzungen wie Stytch<\/a> haben die Erfahrung der Entwickler in den Vordergrund gestellt und sich dadurch einen Namen gemacht.<\/p>\n Mit SSO kannst du deine Identit\u00e4t an einen externen Anbieter „auslagern“. Das kann ein unternehmensorientierter, sicherheitsorientierter Anbieter wie Okta<\/a> sein, aber auch ein weit verbreiteter Anbieter wie Google<\/a> oder GitHub. Google SSO ist in der SaaS-Welt allgegenw\u00e4rtig, und einige auf Entwickler ausgerichtete Tools authentifizieren sich nur<\/em> \u00fcber GitHub.<\/p>\n Welchen Anbieter du auch immer w\u00e4hlst, SSO ist in der Regel ein Zusatz zu den anderen oben genannten Authentifizierungsarten und hat seine eigenen Eigenheiten<\/a>, wenn es um die Integration mit externen Plattformen geht (sei gewarnt: SAML verwendet XML).<\/p>\n Es gibt hier keine „richtige“ Wahl – was f\u00fcr dein Projekt das Richtige ist, h\u00e4ngt von deinen Priorit\u00e4ten ab. Wenn du schnell und ohne gro\u00dfen Konfigurationsaufwand loslegen willst, macht es Sinn, die Authentifizierung auszulagern (oder sie sogar komplett, einschlie\u00dflich der Benutzeroberfl\u00e4che, an jemanden wie Auth0 zu \u00fcbertragen). Wenn du mit einer komplexeren Einrichtung rechnest, ist es sinnvoll, dein eigenes Autorisierungs-Backend zu bauen. Und wenn du vorhast, gr\u00f6\u00dfere Kunden zu unterst\u00fctzen, wirst du irgendwann SSO einf\u00fchren m\u00fcssen.<\/p>\n Next.js ist inzwischen so popul\u00e4r, dass die meisten dieser Authentifizierungsanbieter \u00fcber Next.js-spezifische Dokumente und Integrationsanleitungen verf\u00fcgen.<\/p>\n Einige Authentifizierungsanbieter wie Auth0 bieten sogar ganze gehostete Webseiten f\u00fcr die Anmeldung und den Sign-In an. Wenn du diese jedoch von Grund auf neu erstellst, ist es sinnvoll, sie schon fr\u00fch im Prozess zu erstellen, da du sie als Weiterleitungen brauchst, wenn du deine Authentifizierung tats\u00e4chlich implementierst.<\/p>\n Es ist also sinnvoll, die Struktur f\u00fcr diese Seiten zu erstellen und dann die Anfragen im Backend hinzuzuf\u00fcgen. Die einfachste Art, die Autorisierung zu implementieren, ist, zwei dieser Routen zu haben:<\/p>\n Neben den Grundlagen musst du auch Sonderf\u00e4lle abdecken, z. B. wenn ein Nutzer sein Passwort vergisst. Manche Teams bevorzugen es, den Passwort-R\u00fccksetzungsprozess auf einer separaten Route durchzuf\u00fchren, w\u00e4hrend andere dynamische UI-Elemente zur regul\u00e4ren Anmeldeseite hinzuf\u00fcgen.<\/p>\n Eine sch\u00f6ne Anmeldeseite entscheidet vielleicht nicht \u00fcber Erfolg oder Misserfolg, aber kleine Details k\u00f6nnen einen guten Eindruck hinterlassen und insgesamt f\u00fcr eine bessere UX sorgen. Hier sind ein paar Beispiele von Websites aus dem Internet, die ihre Authentifizierungsprozesse mit ein bisschen mehr Liebe gestaltet haben.<\/p>\n Der Aufruf zum Handeln in der Navigationsleiste von Stripe \u00e4ndert sich, je nachdem, ob du eine authentifizierte Sitzung hast oder nicht. So sieht die Marketingseite aus, wenn du nicht authentifiziert bist. Beachte die Handlungsaufforderung, dich anzumelden:<\/p>\n Und so sieht es aus, wenn du authentifiziert bist. Beachte, dass sich die Handlungsaufforderung so \u00e4ndert, dass der Nutzer zu seinem Dashboard geleitet wird, anstatt sich anzumelden:<\/p>\n Das \u00e4ndert mein Stripe-Erlebnis zwar nicht grundlegend, aber es ist durchdacht.Ein interessanter technischer Nebenaspekt: Es gibt einen guten Grund, warum die meisten Unternehmen die Navigationsleiste auf ihrer Marketingseite nicht von der Authentifizierung „abh\u00e4ngig“ machen – es w\u00fcrde eine zus\u00e4tzliche API-Anfrage bedeuten, um bei jedem einzelnen Seitenaufruf zu pr\u00fcfen, ob die Besucher authentifiziert sind, und die meisten davon sind es wahrscheinlich nicht.<\/p>\n In den letzten Jahren haben Unternehmen, vor allem im SaaS-Bereich, damit begonnen, der Anmeldeseite Inhalte hinzuzuf\u00fcgen, die den Nutzer dazu „ermutigen“, die Anmeldung tats\u00e4chlich abzuschlie\u00dfen. Das kann dazu beitragen, die Konversion auf der Seite zu verbessern, zumindest schrittweise.<\/p>\n Hier ist eine Anmeldeseite von Retool, mit einer Animation und einigen Logos an der Seite:<\/p>\n Wir machen das auch bei Kinsta f\u00fcr unsere Anmeldeseite:<\/p>\n Der kleine zus\u00e4tzliche Inhalt kann helfen, den Nutzer daran zu erinnern, wof\u00fcr er sich anmeldet und warum er es braucht.<\/p>\n Unter Entwicklern ist es allgemein bekannt, dass Passw\u00f6rter von Natur aus unsicher sind, aber nicht<\/em> bei allen Menschen, die sich f\u00fcr dein Produkt anmelden werden. Wenn du deine Nutzer\/innen dazu ermutigst, sichere Passw\u00f6rter zu erstellen, ist das gut f\u00fcr dich und gut f\u00fcr sie.<\/p>\n Coinbase ist bei der Anmeldung ziemlich streng und verlangt von dir ein sicheres Passwort, das komplizierter ist als dein Vorname:<\/p>\n Nachdem ich stattdessen eines mit meinem Passwortmanager erstellt hatte, konnte ich loslegen:<\/p>\n Die Benutzeroberfl\u00e4che sagte mir allerdings nicht, warum<\/em> das Passwort nicht sicher genug war, und auch nicht, dass es nicht nur eine Zahl sein musste. Wenn du das in deinen Produkttext aufnimmst, wird es f\u00fcr deine Nutzer einfacher und du vermeidest frustrierende Passwortwiederholungen.<\/p>\n Jeder dritte Amerikaner nutzt einen Passwortmanager wie 1Password<\/a>, und trotzdem ignorieren viele Formulare im Internet weiterhin das „type=“ in HTML-Eingaben. Sorge daf\u00fcr, dass deine Formulare mit Passwortmanagern zusammenarbeiten<\/a>:<\/p>\n Das kann den Unterschied zwischen einer 10-sek\u00fcndigen, reibungslosen Anmeldung und einer nervigen manuellen Anmeldung ausmachen, vor allem auf dem Handy.<\/p>\n Sobald sich dein\/e Nutzer\/in authentifiziert hat, musst du dich f\u00fcr eine Strategie entscheiden, wie du diesen Status bei nachfolgenden Anfragen beibehalten willst. HTTP ist zustandslos und wir wollen unseren Nutzer sicher nicht bei jeder einzelnen Anfrage nach seinem Passwort fragen. Es gibt zwei g\u00e4ngige Methoden, um dies zu bewerkstelligen<\/a> – Sessions<\/strong> (oder Cookies) und JWTs<\/strong> (JSON Web Tokens) – und sie unterscheiden sich darin, ob der Server oder der Client die Arbeit \u00fcbernimmt.<\/p>\n Bei der sitzungsbasierten Authentifizierung werden die Logik und die Arbeit zur Aufrechterhaltung der Authentifizierung vom Server<\/strong> \u00fcbernommen. Hier ist der grundlegende Ablauf:<\/p>\n Es ist ziemlich einfach und kann angepasst werden, wenn es darum geht, wie lange Sitzungen dauern, wann sie widerrufen werden sollen usw. Der Nachteil ist die Latenz, die durch die vielen Schreib- und Lesevorg\u00e4nge in der Datenbank entsteht, aber das d\u00fcrfte f\u00fcr die meisten Leser keine gro\u00dfe Rolle spielen.<\/p>\n Anstatt die Authentifizierung f\u00fcr nachfolgende Anfragen auf dem Server zu erledigen, kannst du sie mit JWTs<\/a> (gr\u00f6\u00dftenteils) auf der Client-Seite<\/strong> erledigen. So funktioniert es:<\/p>\n Da die gesamte Arbeit nach der anf\u00e4nglichen Authentifizierung auf den Client verlagert wird, kann deine Anwendung viel schneller laden und arbeiten. Es gibt jedoch ein Hauptproblem: Es gibt keine M\u00f6glichkeit, ein JWT vom Server aus ung\u00fcltig zu machen. Wenn sich der Nutzer von einem Ger\u00e4t abmelden m\u00f6chte oder sich der Umfang seiner Berechtigung \u00e4ndert, musst du warten, bis das JWT abl\u00e4uft.<\/p>\n Was Next.js so gro\u00dfartig macht, ist das eingebaute statische Rendering – wenn deine Seite statisch ist, d.h. keine externen API-Aufrufe t\u00e4tigen muss, wird sie von Next.js automatisch zwischengespeichert und kann \u00fcber ein CDN extrem schnell ausgeliefert werden. Vor Next.js 13 erkennt Next.js, ob eine Seite statisch ist, wenn du keine `getServerSideProps` oder `getInitialProps` in die Datei einf\u00fcgst. Alle Versionen nach Next.js 13 verwenden stattdessen React Server Components<\/a>, um dies zu tun.<\/p>\n Bei der Authentifizierung hast du die Wahl<\/a>: Entweder du renderst eine statische „Lade“-Seite und erledigst die Abfrage clientseitig oder du machst alles serverseitig. F\u00fcr Seiten, die eine Authentifizierung erfordern [1]<\/a>, kannst du ein statisches „Skelett“ rendern und dann Authentifizierungsanfragen auf der Client-Seite stellen. Theoretisch bedeutet das, dass die Seite schneller geladen wird, auch wenn der urspr\u00fcngliche Inhalt noch nicht vollst\u00e4ndig fertig ist.<\/p>\n Hier ist ein vereinfachtes Beispiel aus den Dokumenten, das einen Ladezustand rendert, solange das Benutzerobjekt noch nicht fertig ist:<\/p>\n Beachte, dass du hier eine Art Lade-UI bauen musst, um Platz zu schaffen, w\u00e4hrend der Client nach dem Laden Anfragen stellt.<\/p>\n Wenn du die Dinge vereinfachen und die Authentifizierung serverseitig ausf\u00fchren m\u00f6chtest, kannst du deine Authentifizierungsanfrage in die Funktion „getServerSideProps“ einf\u00fcgen. Anstelle der bedingten Logik im obigen Snippet k\u00f6nntest du etwas Einfacheres wie diese vereinfachte Version aus den Next-Dokumenten verwenden:<\/p>\n Hier gibt es immer noch eine Logik f\u00fcr den Fall, dass die Authentifizierung fehlschl\u00e4gt, aber es wird zur Anmeldung weitergeleitet, anstatt einen Ladezustand zu rendern.<\/p>\nTraditionelle Datenbank<\/h3>\n
Authentifizierungsl\u00f6sungen deines Datenbankanbieters<\/h3>\n
async function signInWithEmail() {\n const { data, error } = await supabase.auth.signInWithPassword({\n email: 'example@email.com',\n password: 'example-password',\n })\n}<\/code><\/pre>\nAuthentifizierungsl\u00f6sungen, die nicht von deinem Datenbankanbieter stammen<\/h3>\n
![\"Die](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/11\/Auth0-authentication.png\")
Single Sign On<\/h3>\n
Okay, welche ist die richtige f\u00fcr mich?<\/h3>\n
Erstellen von Routen f\u00fcr die Anmeldung und den Sign-In und Tipps f\u00fcr die zus\u00e4tzliche Authentifizierungsmeile<\/h2>\n
\n
1. Aktualisiere deine Navigationsleiste, wenn es eine aktive Sitzung gibt<\/h3>\n
![\"Stripe](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage.png\")
![\"\u00c4nderungen](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage-changes.png\")
2. F\u00fcge hilfreiche Inhalte neben dem Anmeldeformular hinzu<\/h3>\n
![\"Retool](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/11\/retool-signup-page.png\")
![\"MyKinsta](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/11\/mykinsta-sign-in.png\")
3. Wenn du ein Passwort verwendest: Schlage ein starkes Passwort vor oder erzwinge es<\/h3>\n
![\"Coinbase](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/11\/coinbase-create-account.png\")
![\"Coinbase](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/11\/coinbase-password-strength.png\")
4. Kennzeichne deine Eingaben so, dass sie mit einem Passwortmanager gut zusammenspielen<\/h3>\n
\n
Die Wahl zwischen Sessions und JWT<\/h2>\n
Sitzungen, auch bekannt als Cookies<\/h3>\n
\n
JSON Web Token (JWT)<\/h3>\n
\n
Die Wahl zwischen serverseitiger und clientseitiger Autorisierung<\/h2>\n
import useUser from '..\/lib\/useUser'\n \nconst Profile = () => {\n \/\/ Fetch the user client-side\n const { user } = useUser({ redirectTo: '\/login' })\n \n \/\/ Server-render loading state\n if (!user || user.isLoggedIn === false) {\n \/\/ Build some sort of loading page here\n return <div>Loading...<\/div>\n }\n \n \/\/ Once the user request finishes, show the user\n return (\n <div>\n <h1>Your Account<\/h1>\n <p>Username: {JSON.stringify(user.username,null)}<\/p>\n <p>Email: {JSON.stringify(user.email,null)}<\/p>\n <p>Address: {JSON.stringify(user.address,null)}<\/p>\n <\/div>\n )\n}\n \nexport default Profile<\/code><\/pre>\nimport withSession from '..\/lib\/session'\n \nexport const getServerSideProps = withSession(async function ({ req, res }) {\n const { user } = req.session\n \n if (!user) {\n return {\n redirect: {\n destination: '\/login',\n permanent: false,\n },\n }\n }\n \n return {\n props: { user },\n }\n})\n \nconst Profile = ({ user }) => {\n \/\/ Show the user. No loading state is required\n return (\n <div>\n <h1>Your Account<\/h1>\n <p>Username: {JSON.stringify(user.username,null)}<\/p>\n <p>Email: {JSON.stringify(user.email,null)}<\/p>\n <p>Address: {JSON.stringify(user.address,null)}<\/p>\n <\/div>\n )\n}\n \nexport default Profile<\/code><\/pre>\nZusammenfassung<\/h2>\n