Was ist Authentifizierung? Logins, Sessions und OAuth erklärt

Authentifizierung ist die Art, wie eine App bestätigt, wer ein Nutzer ist – meist durch Prüfung von etwas, das er weiß (ein Passwort), von etwas, das er besitzt (einen Code, der an Handy oder E-Mail geschickt wird), oder einer Identität von einem vertrauenswürdigen Dienst (etwa „Mit Google anmelden“). Sobald ein Nutzer authentifiziert ist, merkt sich die App ihn mit einer Session oder einem Token, damit er sich nicht auf jeder Seite neu anmelden muss. Festzulegen, was dieser bekannte Nutzer tun darf, ist ein separater Schritt und heißt Autorisierung.

Warum das wichtig ist, wenn Sie mit KI bauen

Ein Login hinzuzufügen gehört zu den häufigsten Wünschen an einen KI-App-Builder – und zu den Dingen, die sich leicht unterschwellig falsch umsetzen lassen. Eine Login-Seite lässt sich einfach erzeugen. Schwer ist alles drumherum:

• Werden Passwörter sicher gespeichert?
• Prüft jede private Seite und jeder API-Endpunkt wirklich, wer anfragt?
• Kann ein angemeldeter Kunde die Daten eines anderen sehen, indem er eine Zahl in der URL ändert?
• Was passiert, wenn jemand sein Passwort vergisst?

Eine App kann völlig sicher wirken und trotzdem alle diese Punkte nicht erfüllen. Wer die Bausteine versteht, stellt die richtigen Fragen und testet die richtigen Dinge.

Ein Alltagsvergleich

Denken Sie an den Check-in in einem Hotel.

An der Rezeption zeigen Sie Ihren Ausweis. Das ist Authentifizierung: Sie beweisen, wer Sie sind. Die Rezeptionistin gibt Ihnen dann eine Schlüsselkarte. Diese Karte ist Ihre Session: Für den restlichen Aufenthalt zeigen Sie keinen Ausweis mehr vor, sondern halten nur die Karte an das Schloss.

Die Karte öffnet Ihr Zimmer, das Fitnessstudio und den Aufzug zu Ihrer Etage – aber nicht die Zimmer anderer Gäste oder das Büro des Personals. Das ist Autorisierung: worauf Ihre Identität zugreifen darf. Verlieren Sie die Karte, kann das Hotel sie an der Rezeption deaktivieren (eine Session widerrufen). Beim Auschecken funktioniert sie nicht mehr (Abmelden oder Ablauf).

„Mit Google anmelden“ ist wie ein Hotel, das einen Brief eines vertrauenswürdigen Partners akzeptiert, in dem steht: „Das ist diese Person.“ Der Ausweis wird nicht selbst geprüft.

Die wichtigsten Login-Methoden

Wie Passwörter gespeichert werden sollten

Eine sichere App speichert Ihr eigentliches Passwort nie. Stattdessen speichert sie einen Hash: das Ergebnis einer Einweg-Funktion, die das Passwort in eine feste Zeichenfolge verwandelt. Beim Login hasht die App das Eingegebene und vergleicht das Ergebnis mit dem gespeicherten Hash.

Zwei Details machen das sicher:

• Ein Salt – ein zufälliger Wert, der jedem Passwort vor dem Hashen hinzugefügt wird. So erhalten zwei Menschen mit demselben Passwort unterschiedliche Hashes, und vorberechnete Nachschlagetabellen sind nutzlos.
• Ein langsamer, für Passwörter gemachter Algorithmus – etwa Argon2, bcrypt oder scrypt. Allzweck-Hashes wie MD5 oder SHA-256 sind allein viel zu schnell; Angreifer könnten Milliarden Versuche pro Sekunde machen.

Hashing ist nicht dasselbe wie Verschlüsselung. Verschlüsselte Daten lassen sich mit einem Schlüssel entschlüsseln; ein Passwort-Hash ist so gebaut, dass er gar nicht umkehrbar ist.

Sessions vs. Tokens

Nach dem Login muss die App Sie bei jeder Anfrage wiedererkennen. Dafür gibt es zwei gängige Ansätze.

Bei Cookies sind drei Einstellungen wichtig: HttpOnly (JavaScript auf der Seite kann das Cookie nicht lesen), Secure (wird nur über HTTPS gesendet) und SameSite (begrenzt das Mitsenden bei Anfragen von anderen Seiten). Tokens im localStorage des Browsers abzulegen ist verbreitet, setzt sie aber jedem Skript aus, das auf der Seite läuft.

OAuth und „Mit Google anmelden“

OAuth 2.0 ist ein Standard für delegierte Autorisierung: Er erlaubt einer App eingeschränkten Zugriff auf Ihr Konto bei einem anderen Dienst – etwa zum Lesen Ihres Google-Kalenders –, ohne dass sie jemals Ihr Google-Passwort sieht. Sie werden zu Google geschickt, bestätigen bestimmte Berechtigungen (sogenannte Scopes), und Google gibt der App ein Token nur für diese Berechtigungen.

OAuth allein ist dafür gedacht, Zugriff zu gewähren, nicht zu sagen, wer Sie sind. OpenID Connect (OIDC) ist eine Schicht über OAuth 2.0, die Identität hinzufügt – das nutzt „Mit Google anmelden“ oder „Mit Apple anmelden“. Zur Einrichtung registrieren Sie Ihre App beim Anbieter und erhalten eine Client-ID und ein Client-Secret; das Secret bleibt auf Ihrem Server.

Ein praktisches Beispiel: Login für ein Kundenportal

Angenommen, Sie bauen ein Portal, in dem die Kunden einer Designagentur ihre Projekte und Rechnungen sehen.

• Authentifizierung: Kunden melden sich mit E-Mail und Magic-Link an, sodass keine Passwörter verwaltet werden müssen. Mitarbeitende der Agentur melden sich mit Google-Workspace-Konten an.
• Rollen: Jeder Nutzer hat eine Rolle – client oder staff.
• Autorisierungsregeln:

• Wo es durchgesetzt wird: auf dem Server, bei jeder Anfrage. Der Server schlägt den angemeldeten Nutzer nach und liefert nur Projekte, bei denen project.company_id zur Firma des Nutzers passt. Den Button „Als bezahlt markieren“ auszublenden reicht nicht – der Endpunkt selbst muss die Anfrage ablehnen.

Wichtige Begriffe

Häufige Fehler und Missverständnisse

• Berechtigungen nur auf der Seite prüfen. Blendet der Browser einen Button aus, die API prüft aber nicht, kann jeder die API direkt aufrufen.
• IDs aus der URL vertrauen. /invoices/1042 muss prüfen, ob Rechnung 1042 dem angemeldeten Nutzer gehört.
• Eigene Kryptografie bauen. Nutzen Sie bekannte Bibliotheken oder Anbieter; lassen Sie die KI kein eigenes Hash-Verfahren erfinden.
• Schwaches Passwort-Zurücksetzen. Zurücksetzungslinks sollten nur einmal gelten, schnell ablaufen und nicht verraten, ob eine E-Mail ein Konto hat.
• Den Login Ihrer App mit dem Ihres Builders verwechseln. Die Nutzer Ihrer App sind getrennt von Ihrem Konto beim Tool, mit dem Sie bauen.
• Kein Rate-Limit beim Login. Ohne Begrenzung können Angreifer endlos Passwörter ausprobieren.

Was Sie Ihren KI-App-Builder fragen sollten

• „Füge Registrierung und Login mit [einer bekannten Bibliothek oder einem bekannten Anbieter] hinzu. Schreibe kein eigenes Passwort-Hashing.“
• „Speichere Passwörter mit bcrypt oder Argon2 gehasht.“
• „Verwende für die Session HttpOnly- und Secure-Cookies.“
• „Füge Rollen hinzu: admin und member. Liste jeden Endpunkt auf und welche Rollen ihn aufrufen dürfen.“
• „Stelle auf dem Server sicher, dass Nutzer nur ihre eigenen Datensätze lesen und bearbeiten können. Zeige mir dann, wie du das geprüft hast.“
• „Füge das Zurücksetzen des Passworts mit einmaligen Links hinzu, die nach einer Stunde ablaufen.“
• „Begrenze die Login-Versuche pro Zeitraum.“

Testen Sie es dann selbst: Legen Sie zwei Konten an und versuchen Sie, bei Angemeldetsein mit dem einen auf die Daten des anderen zuzugreifen. Unser Leitfaden zum Hinzufügen eines Logins und die Sicherheits-Checkliste gehen weiter.

Authentifizierung in Mythex

Mythex stellt kein eingebautes Auth-Produkt für die Nutzer Ihrer App bereit. Sie wählen einen Ansatz – E-Mail und Passwort, gespeichert in der Datenbank Ihres Projekts, oder das SDK eines gehosteten Anbieters – und bitten den Agenten, ihn hinzuzufügen. Anbieter-Schlüssel gehören in die Projekt-Geheimnisse, nicht in den Chat. Das ist getrennt davon, wie Sie sich bei Mythex selbst anmelden. Das Rezept in der Dokumentation zu Login in Ihre App einbauen enthält einen Startprompt, den Sie anpassen können, und was eine API ist erklärt, wo diese serverseitigen Prüfungen liegen.

Fragen