Authentifizierung und Autorisierung

Zwei Fragen stellt jedes System bei jeder Anfrage: Wer bist du? Und was darfst du? Die erste Frage beantwortet die Authentifizierung, die zweite die Autorisierung. Beide werden oft verwechselt oder in einen Topf geworfen, doch sie sind unterschiedliche Aufgaben mit unterschiedlichen Fehlern. Fehler in diesem Bereich gehören zu den folgenreichsten überhaupt: Wer sich als jemand anderes ausgeben oder fremde Daten sehen kann, gefährdet Nutzer und Unternehmen gleichermaßen. Diese Lektion zeigt die gängigen Verfahren und die wichtigsten Regeln für einen sicheren Entwurf.

1. Zwei verschiedene Fragen

Die Unterscheidung ist wichtig, weil die häufigsten Sicherheitslücken in Webanwendungen nicht bei der Anmeldung entstehen, sondern bei der Autorisierung. Ein angemeldeter Nutzer ändert in der Adresse die Buchungsnummer von 901 auf 902 – und sieht die Buchung eines Fremden, weil der Server nur geprüft hat, ob jemand angemeldet ist, nicht aber, ob ihm diese Buchung gehört. Diese Lücke steht seit Jahren an erster Stelle der OWASP-Liste der größten Risiken für APIs.

2. Sitzungen und Tokens

Nach der Anmeldung muss sich das System merken, wer der Nutzer ist. Klassisch geschieht das über eine Sitzung: Der Server speichert die Anmeldung, der Browser erhält ein Cookie mit einer zufälligen Kennung. Das ist einfach, sicher und lässt sich jederzeit widerrufen, verlangt aber einen gemeinsamen Sitzungsspeicher, wenn mehrere Server beteiligt sind. Alternativ erhält der Client ein Token, oft ein signiertes JSON Web Token, das Identität und Ablaufzeit enthält und von jedem Server ohne Rückfrage geprüft werden kann. Tokens eignen sich gut für APIs und Apps, lassen sich aber schwer vorzeitig widerrufen. Deshalb sind Access Tokens kurzlebig, und ein langlebigeres Refresh Token holt bei Bedarf neue.

Abb. 2.1Anmeldung mit Access und Refresh Token

3. OAuth 2.0 und OpenID Connect

Viele Anwendungen bauen die Anmeldung nicht selbst, sondern nutzen einen Identitätsanbieter – einen eigenen wie Keycloak, einen Dienst wie Auth0, Clerk oder Supabase Auth, oder die Anmeldung über Google, Apple oder Microsoft. Die Standards dahinter sind OAuth 2.0 für die Vergabe von Zugriffsrechten und OpenID Connect für die Anmeldung. Klicken Sie sich durch den typischen Ablauf „Mit Google anmelden“:

Ein Identitätsanbieter übernimmt viel schwierige Arbeit: sichere Passwortspeicherung, Mehr-Faktor-Anmeldung, Passkeys, Schutz vor automatisierten Anmeldeversuchen, Passwort-Zurücksetzen. Für die meisten Projekte ist es sicherer und günstiger, auf einen etablierten Anbieter zu setzen, statt all das selbst zu bauen.

4. Moderne Anmeldeverfahren

Passwörter sind die Schwachstelle vieler Systeme, weil sie wiederverwendet, erraten oder abgefischt werden. Mehr-Faktor-Anmeldung ergänzt das Passwort um einen zweiten Nachweis, etwa einen Code aus einer App. Passkeys gehen weiter: Sie ersetzen das Passwort durch ein Schlüsselpaar, das auf dem Gerät liegt und per Fingerabdruck oder Gesichtserkennung freigegeben wird. Passkeys sind gegen Phishing immun, weil sie nur für die echte Domain funktionieren. Wer heute eine Anmeldung entwirft, sollte Passkeys anbieten und für Konten mit weitreichenden Rechten Mehr-Faktor-Anmeldung verpflichtend machen.

5. Autorisierung entwerfen

Für die Autorisierung ist das rollenbasierte Modell am verbreitetsten: Nutzer haben Rollen, Rollen haben Rechte. Probieren Sie es aus:

Rollen allein reichen oft nicht. „Trainer dürfen Teilnehmerlisten sehen“ ist zu grob – gemeint ist: nur für die eigenen Kurse. Solche Regeln, die Eigenschaften von Nutzer und Objekt verbinden, nennt man attributbasierte Autorisierung. In der Praxis kombiniert man beides: Rollen für grobe Rechte, Prüfungen auf Eigentum und Zugehörigkeit für jedes einzelne Objekt. Diese Prüfungen gehören an eine zentrale Stelle im Code, damit sie nicht in einzelnen Endpunkten vergessen werden.

6. Regeln für den Entwurf

Einige Grundsätze haben sich bewährt. Autorisierung passiert immer auf dem Server; was die Oberfläche ausblendet, ist Komfort, kein Schutz. Rechte werden nach dem Prinzip der geringsten Berechtigung vergeben: so viel wie nötig, so wenig wie möglich. Tokens haben kurze Laufzeiten und werden nie in Adressen übertragen. Cookies für Sitzungen tragen die Attribute HttpOnly, Secure und SameSite. Anmeldeversuche werden begrenzt und protokolliert. Und Änderungen an Rechten – etwa wenn jemand zur Studioleitung befördert wird – werden nachvollziehbar festgehalten. Wer diese Regeln befolgt, schließt die meisten Lücken, die in der Praxis ausgenutzt werden, und schafft eine Grundlage, auf der auch spätere Funktionen sicher aufbauen können.

7. Typische Fehler vermeiden

Einige Fehler tauchen bei der Umsetzung immer wieder auf. Tokens werden im lokalen Speicher des Browsers abgelegt, wo jedes eingeschleuste Skript sie auslesen kann; sicherer sind HttpOnly-Cookies, auf die Skripte keinen Zugriff haben. JSON Web Tokens werden ohne Prüfung der Signatur oder mit dem Algorithmus „none“ akzeptiert. Passwort-Zurücksetzen-Links sind unbegrenzt gültig oder verraten, ob eine E-Mail-Adresse registriert ist. Die Abmeldung löscht nur das Cookie im Browser, während die Sitzung auf dem Server weiter gültig bleibt. Und Administratorrechte werden über ein Feld im Token vergeben, das der Client selbst verändern könnte, wenn die Signatur nicht geprüft wird.

Die meisten dieser Fehler lassen sich vermeiden, indem man auf bewährte Bibliotheken und Identitätsanbieter setzt, statt Kryptografie und Anmeldeabläufe selbst zu programmieren. Eigene Arbeit fließt dann in das, was nur das eigene System wissen kann: die Regeln, wer welche Objekte sehen und ändern darf. Diese Regeln sollten schriftlich festgehalten, in Tests abgedeckt und bei jedem neuen Endpunkt geprüft werden. Ein einfacher, wirksamer Test ist, jede Anfrage einmal mit dem Konto eines anderen Nutzers auszuführen: Liefert der Server dann die fremden Daten, ist eine Lücke gefunden, bevor ein Angreifer sie findet.

Auch die Nutzerfreundlichkeit gehört zur Sicherheit. Wenn die Anmeldung zu umständlich ist, suchen Nutzer Umwege, etwa geteilte Konten oder notierte Passwörter. Passkeys verbinden hier Sicherheit und Komfort: Die Anmeldung dauert eine Sekunde und ist trotzdem sicherer als jedes Passwort. Sitzungen dürfen auf vertrauenswürdigen Geräten länger dauern, während sensible Aktionen wie das Ändern der E-Mail-Adresse oder der Zahlungsdaten eine erneute Bestätigung verlangen.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.