Authentifizierung und Autorisierung: Mehr-Faktor, Passwort-Reset, Single Sign-on und OAuth2

Authentifizierung und Autorisierung: Mehr-Faktor, Passwort-Reset, Single Sign-on und OAuth2

https://bildung.social/@oerinformatik/

https://oer-informatik.de/authentifizierung

Authentifizierung, Autorisierung, Mehr-Faktor-Authentifizierung, Passkeys, Passwort-Reset, Single Sign-on, OAuth2, OpenID Connect, PKCE, Least Privilege

tl/dr; (ca. 29 min Lesezeit): Bevor eine Anwendung Daten herausgibt, muss sie zwei Fragen klären: Wer bist Du (Authentifizierung)? Und was darfst Du (Autorisierung)? Der Artikel erklärt Authentifizierungsfaktoren und Mehr-Faktor-Anmeldung, Passkeys, ein sicheres „Passwort vergessen“, Single Sign-on mit seinen Vor- und Nachteilen sowie OAuth2 und OpenID Connect mit dem Ablauf des Authorization Code Flow. Zum Schluss geht es um Rollen und Rechte und um typische Denkfehler [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Dieser Artikel baut auf der Kann-Liste des Artikels Kryptografie: symmetrisch, asymmetrisch, hybrid – mit Hash, Signatur und Zertifikat auf. Passend dazu gibt es Übungsaufgaben zu Authentifizierung und Autorisierung.

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Als Authentifizierungs-Grundlagen kann ich nach Durchlesen des Artikels…

• … Identifizierung, Authentifizierung und Autorisierung unterscheiden und an einem Beispiel erklären.

• … Authentifizierungsmerkmale den Faktoren Wissen, Besitz und Inhärenz zuordnen und je Faktor einen Vorteil und ein Sicherheitsrisiko nennen.

• … das Prinzip der Zwei- bzw. Mehr-Faktor-Authentifizierung erklären, den Ablauf mit einem Einmalpasswort beschreiben und Quellen für den zweiten Faktor nennen.

• … Schwachstellen eines Passwort-Resets per E-Mail-Link erläutern und ein sichereres Vorgehen beschreiben (zufälliges, befristetes, einmaliges Token, zweiter Kanal, keine Kontoauskunft).

• … Vor- und Nachteile von Single Sign-on unter Sicherheitsaspekten erläutern.

• … die vier Rollen von OAuth2 benennen und den Begriffen Authorization Code, Access Token und Protected Resource ihre Stelle im Ablauf zuordnen.

• … begründen, warum Rechte immer serverseitig nach dem Prinzip der minimalen Rechte geprüft werden.

Darüber hinaus kann ich als Authentifizierungs-Expertenwissen…

• … erläutern, wie Passkeys mit asymmetrischer Kryptografie funktionieren und warum sie gegen Phishing schützen.

• … OAuth2 (Autorisierung) von OpenID Connect (Authentifizierung, ID-Token) abgrenzen und Scopes nach dem Prinzip der Datenminimierung auswählen.

• … die Schutzmechanismen state und PKCE erklären und begründen, warum Implicit Flow und Password Grant nicht mehr verwendet werden sollen.

Fast jede Anwendung hat eine Anmeldung. Und fast jede Sicherheitslücke, über die in den Nachrichten berichtet wird, hat mit ihr zu tun: erbeutete Passwörter, gefälschte Anmeldeseiten, Konten, die sich über „Passwort vergessen“ übernehmen lassen, oder Nutzende, die Daten anderer sehen, weil die Anwendung nicht prüft, wer was darf. In den OWASP Top 10:2025, der bekanntesten Liste der häufigsten Schwachstellen von Webanwendungen, stehen fehlerhafte Zugriffskontrolle (Broken Access Control) auf Platz 1 und Fehler bei der Authentifizierung (Authentication Failures) auf Platz 7. Wer Software entwickelt, sollte deshalb die Bausteine kennen, mit denen Anmeldung und Rechteprüfung sicher werden. Die Mindmap zeigt, welche das sind und wie dieser Artikel sie ordnet.

Wer bist Du, und was darfst Du?

Bei einer Anmeldung laufen drei Schritte nacheinander ab, die man sauber trennen sollte:

Die Authentifizierung prüft also die Identität, die Autorisierung vergibt Rechte an eine bereits geprüfte Identität. Die Reihenfolge ist zwingend: Ohne geprüfte Identität kann es keine sinnvolle Rechtevergabe geben. Umgekehrt ist eine erfolgreiche Anmeldung noch keine Erlaubnis für alles – diese Verwechslung steckt hinter vielen Sicherheitslücken.

Im Deutschen wird manchmal noch feiner unterschieden: Die Person authentisiert sich (sie legt einen Nachweis vor), das System authentifiziert sie (es prüft den Nachweis). Im Englischen heißt beides authentication. Oft kommt als vierter Schritt noch die Protokollierung (Accounting) dazu: Wer hat wann was getan? Sie macht Handlungen nachweisbar und unterstützt das Schutzziel Verbindlichkeit.

Authentifizierung gibt es nicht nur für Menschen. Auch Programme, Geräte und Server weisen sich aus: ein Webserver mit seinem TLS-Zertifikat, ein Sensor mit einem API-Schlüssel, ein Dienst mit einem Client-Geheimnis. Die Schutzziele und das Thema Zertifikate behandeln die Artikel Schutzziele und Sicherheitsrisiken und Kryptografie.

Womit sich Menschen ausweisen: Wissen, Besitz, Inhärenz

Ein Nachweis der Identität beruht auf einem von drei Faktoren:

Manchmal werden noch Ort (Anmeldung nur aus dem Firmennetz) oder Verhalten (Tippmuster) genannt. Sie dienen meist als zusätzliches Signal, nicht als eigener Nachweis.

Beim Passwort hängt viel von der Umsetzung ab: Die Anwendung speichert nie das Passwort selbst, sondern nur einen gesalzenen Hashwert mit einem langsamen Verfahren wie Argon2id oder bcrypt (siehe Kryptografie). Für Nutzende gilt heute: lieber lang als kompliziert (z. B. eine Passphrase aus mehreren Wörtern), für jeden Dienst ein eigenes Passwort, am besten mit einem Passwortmanager. Einen regelmäßigen Zwangswechsel empfehlen weder das BSI noch das US-amerikanische NIST mehr; gewechselt wird, wenn der Verdacht besteht, dass ein Passwort bekannt geworden ist.

Zwei Faktoren sind besser als einer: Mehr-Faktor-Authentifizierung

Bei der Zwei-Faktor-Authentifizierung (2FA) bzw. allgemein Mehr-Faktor-Authentifizierung (MFA) weist Du Dich mit mindestens zwei Merkmalen aus unterschiedlichen Faktoren nach, die voneinander unabhängig sind. Das bekannteste Beispiel ist die Girocard am Geldautomaten: Karte (Besitz) plus PIN (Wissen). Wer nur die PIN ausgespäht hat, kommt ohne Karte nicht weiter – und umgekehrt.

Wichtig: Zwei Merkmale desselben Faktors sind keine 2FA. Passwort plus Sicherheitsfrage sind zweimal Wissen und werden mit derselben Phishing-Seite abgefragt.

Typischer Ablauf einer Anmeldung mit Einmalpasswort (One-Time Password, OTP):

1. Du gibst Benutzername und Passwort ein. Sind sie falsch, erscheint eine allgemeine Meldung („Anmeldung fehlgeschlagen“) – ohne Hinweis, ob der Benutzername existiert.

2. Sind sie richtig, fordert die Anwendung den zweiten Faktor an: „Gib den sechsstelligen Code aus Deiner Authenticator-App ein.“

3. Du liest den Code vom Smartphone ab und gibst ihn ein.

4. Ist der Code richtig und noch gültig, wirst Du angemeldet; sonst wird der Zugang verweigert. Nach mehreren Fehlversuchen wird gebremst (Wartezeit, Captcha).

Quellen für den zweiten Faktor (vom schwächeren zum stärkeren):

• Code per SMS oder Sprachanruf: einfach, aber anfällig. SMS sind nicht Ende-zu-Ende-verschlüsselt, Telefonnummern lassen sich durch einen erschlichenen Ersatz der SIM-Karte (SIM-Swapping) übernehmen, und eine Phishing-Seite kann den Code genauso abfragen wie das Passwort. NIST führt SMS deshalb nur noch als „eingeschränkt“ (restricted) zulässigen Faktor. Für Menschen ohne Mobiltelefon ist das Verfahren gar nicht nutzbar.

• Authenticator-App mit zeitbasiertem Einmalpasswort (TOTP nach RFC 6238): Smartphone und Server teilen bei der Einrichtung ein Geheimnis (meist per QR-Code); daraus und aus der Uhrzeit berechnen beide alle 30 Sekunden denselben sechsstelligen Code. Funktioniert ohne Mobilfunknetz, ist aber ebenfalls nicht phishingresistent.

• Push-Bestätigung in einer App: bequem, aber anfällig für „MFA-Müdigkeit“, wenn Angreifende so lange Anfragen schicken, bis jemand genervt auf „Bestätigen“ tippt. Abhilfe: Zahl aus der Anmeldeseite in der App eingeben lassen (Number Matching).

• Chipkarte oder Hardware-Sicherheitsschlüssel (FIDO2): Der private Schlüssel verlässt das Gerät nie; die Anmeldung ist an die echte Webadresse gebunden und damit phishingresistent.

• Biometrie dient meist dazu, ein Gerät zu entsperren, das dann den eigentlichen Nachweis führt (z. B. Fingerabdruck am Smartphone für einen Passkey).

Mehr-Faktor-Authentifizierung ist eine der wirksamsten Einzelmaßnahmen überhaupt. Sie ist Pflicht für alle Zugänge mit erhöhten Rechten (Administration, Moderation, Zugriff auf viele personenbezogene Daten) und gehört zu den technischen Maßnahmen, die Art. 32 DSGVO für die Sicherheit der Verarbeitung verlangt. Damit Nutzende sich nicht aussperren, braucht es einen geregelten Weg für den Fall, dass der zweite Faktor verloren geht (z. B. einmalig nutzbare Wiederherstellungscodes, die bei der Einrichtung ausgedruckt werden).

Ganz ohne Passwort: Passkeys

Passkeys ersetzen das Passwort durch ein Schlüsselpaar der asymmetrischen Kryptografie. Sie beruhen auf den Standards FIDO2 der FIDO Alliance und Web Authentication (WebAuthn) des W3C:

1. Registrierung: Dein Gerät (Smartphone, Laptop, Sicherheitsschlüssel) erzeugt für genau diesen Dienst ein neues Schlüsselpaar. Der öffentliche Schlüssel wird beim Dienst gespeichert, der private bleibt geschützt auf dem Gerät bzw. im Passwortmanager.

2. Anmeldung: Der Dienst schickt eine zufällige Herausforderung (Challenge). Du entsperrst Dein Gerät per Fingerabdruck, Gesicht oder Geräte-PIN, und das Gerät signiert die Challenge mit dem privaten Schlüssel. Der Dienst prüft die Signatur mit dem gespeicherten öffentlichen Schlüssel.

Das Sequenzdiagramm fasst beide Abläufe zusammen:

Das hat mehrere Vorteile: Es gibt kein Geheimnis auf dem Server, das bei einem Datendiebstahl erbeutet werden könnte – ein öffentlicher Schlüssel nützt Angreifenden nichts. Der Browser bindet den Passkey an die Domain, für die er erzeugt wurde; auf einer gefälschten Seite mit ähnlicher Adresse wird er gar nicht angeboten. Passkeys sind also phishingresistent. Und weil Besitz (Gerät) und Wissen oder Inhärenz (Entsperren) zusammenwirken, erfüllt ein Passkey bereits die Idee der Zwei-Faktor-Authentifizierung. Nachteile: Ohne Gerät oder Synchronisation über einen Passwortmanager kommst Du nicht an Dein Konto, und nicht jede Anwendung unterstützt Passkeys schon. Den genauen Nachrichtenablauf übst Du in der Aufgabe Authentifizierung mit Passkeys (Sequenzdiagramm).

„Passwort vergessen?“ – der Reset als Hintertür

Jede Anmeldung mit Passwort braucht einen Weg für vergessene Passwörter. Weil dieser Weg ohne das Passwort auskommen muss, ist er für Angreifende ein bequemer Seiteneingang: Wer den Reset übernehmen kann, übernimmt das Konto.

Schwachstellen beim Reset per E-Mail-Link

Das übliche Verfahren schickt einen Link zum Zurücksetzen an die gespeicherte E-Mail-Adresse. Das ist besser, als ein neues Passwort im Klartext zu verschicken, hat aber typische Schwachstellen:

• Der Link kann in falsche Hände geraten. Wer Zugriff auf das Postfach hat – weil dessen Passwort erbeutet wurde, weil ein Familienmitglied mitliest oder weil die E-Mail-Adresse nach Jahren an jemand anderen vergeben wurde –, kann das Passwort neu setzen. Die ganze Sicherheit des Kontos hängt dann an der Sicherheit des Postfachs.

• Ein schwach gebautes Token lässt sich erraten. Besteht der Link aus Benutzernummer und Uhrzeit oder aus einem fortlaufenden Zähler, können Angreifende gültige Links für fremde Konten selbst berechnen.

• Der Link ist zu lange oder mehrfach gültig. Bleibt er tagelang gültig oder kann mehrfach benutzt werden, reicht ein alter Fund im Postfach, im Browserverlauf oder in Server-Logs.

• Die Anwendung verrät, ob es ein Konto gibt. Antwortet sie „Zu dieser Adresse gibt es kein Konto“, können Angreifende testen, wer registriert ist (User Enumeration) – ein Datenschutzproblem und die Vorbereitung gezielter Phishing-Mails.

• Gefälschte Reset-Mails sind ein beliebtes Phishing-Muster. Wer echte Reset-Mails gewohnt ist, klickt auch auf gefälschte.

• Missbrauch als Störung: Lassen sich unbegrenzt Reset-Mails oder -SMS auslösen, können Angreifende Postfächer fluten oder Kosten verursachen.

Ein sichereres Vorgehen

Ein sicherer Reset kombiniert mehrere Maßnahmen:

• Zufälliges, einmaliges und befristetes Token: mit einem kryptografisch sicheren Zufallsgenerator erzeugt (mindestens 128 Bit), nur einmal verwendbar und kurz gültig (z. B. 15 bis 60 Minuten). In der Datenbank wird nur ein Hashwert des Tokens gespeichert, damit ein Datenbankdiebstahl keine gültigen Links liefert.

• Zweiter Kanal: Zusätzlich zum Link wird ein Code über einen anderen Weg geschickt, z. B. per SMS an die hinterlegte Mobilnummer, oder der Reset muss mit einem bereits eingerichteten zweiten Faktor (Authenticator-App, Passkey) bestätigt werden. Wer nur das Postfach kontrolliert, kommt dann nicht weiter. Für Nutzende ohne Mobiltelefon braucht es eine Alternative (z. B. Wiederherstellungscode, Identitätsprüfung durch den Support).

• Immer dieselbe Antwort: „Falls ein Konto zu dieser Adresse existiert, haben wir Dir eine E-Mail geschickt.“ – gleichgültig, ob es das Konto gibt, und möglichst in gleicher Antwortzeit.

• Link nicht aus Anfragedaten bauen: Die Adresse im Link wird fest konfiguriert und nicht aus dem Host-Header der Anfrage übernommen, sonst können Angreifende Links auf ihre eigene Domain erzeugen lassen. Der Link führt immer per HTTPS auf die eigene Domain.

• Nach dem Reset: keine automatische Anmeldung, sondern normale Anmeldung mit dem neuen Passwort; alle bestehenden Sitzungen beenden; eine Benachrichtigung an die Person schicken („Dein Passwort wurde geändert. Warst Du das nicht? Dann …“).

• Begrenzen: Anzahl der Reset-Anfragen je Konto und Zeitraum beschränken, bei Bedarf mit Captcha. Das Konto wird dabei nicht gesperrt, sonst können Angreifende Menschen aussperren.

Nicht geeignet sind dagegen: das alte Passwort zurückschicken (dann wurde es nicht als Hashwert gespeichert), ein neues Passwort im Klartext per E-Mail, Sicherheitsfragen als einzige Prüfung („Name Deines ersten Haustiers“ steht oft in sozialen Netzwerken).

Einmal anmelden, viele Dienste: Single Sign-on

Beim Single Sign-on (SSO) meldest Du Dich einmal bei einem zentralen Identity Provider (IdP) an, z. B. dem Schul- oder Firmenkonto. Alle angeschlossenen Anwendungen (Service Provider bzw. Relying Parties) vertrauen dieser Anmeldung und fragen kein eigenes Passwort mehr ab. Technisch wird SSO im Web heute meist mit OpenID Connect umgesetzt (siehe unten), in Unternehmen auch mit SAML 2.0 oder im Windows-Netz mit Kerberos.

Die Nachteile lassen sich verringern: Der IdP bekommt eine Mehr-Faktor-Anmeldung (damit reicht ein erbeutetes Passwort nicht mehr), wird redundant betrieben und überwacht ungewöhnliche Anmeldungen. Besonders kritische Funktionen können zusätzlich eine erneute Anmeldung verlangen.

OAuth2: Zugriff erlauben, ohne das Passwort weiterzugeben

Stell Dir eine Fotodruck-App vor, die Deine Fotos aus einem Cloudspeicher holen soll. Früher hätte die App nach Benutzername und Passwort des Cloudspeichers gefragt – und damit vollen Zugriff auf alles gehabt, auf unbestimmte Zeit. OAuth 2.0 (RFC 6749) löst das anders: Du erlaubst der App beim Cloudspeicher einen begrenzten Zugriff (nur Fotos lesen), die App bekommt dafür ein Zugangstoken, aber nie Dein Passwort. OAuth2 ist damit ein Standard zur Autorisierung, genauer zur delegierten Autorisierung.

Vier Rollen

Authorization Server und Resource Server gehören oft zum selben Anbieter, sind aber verschiedene Aufgaben. Der Client ist in OAuth2 immer die Anwendung, nicht der Mensch.

Der Authorization Code Flow Schritt für Schritt

Für Webanwendungen und Apps wird der Authorization Code Flow verwendet:

1. Autorisierungsanfrage: Die App leitet Deinen Browser zum Authorization Server weiter. In der Adresse stehen, welche App anfragt (client_id), wohin danach zurückgeleitet wird (redirect_uri), welche Rechte gewünscht sind (scope) sowie die Schutzwerte state und code_challenge.

2. Anmeldung und Zustimmung: Du meldest Dich beim Authorization Server an – nicht bei der App – und bestätigst, welche Daten die App erhalten darf.

3. Authorization Code: Der Authorization Server leitet den Browser zur App zurück und hängt einen Authorization Code an. Der Code ist kurzlebig (wenige Minuten), nur einmal verwendbar und allein wertlos.

4. Code gegen Token tauschen: Die App schickt den Code über eine direkte Server-zu-Server-Verbindung an den Authorization Server und weist sich dabei aus: mit dem Client-Geheimnis und bzw. oder mit dem PKCE-Nachweis (code_verifier, siehe unten). Zurück kommt das Access Token, oft zusätzlich ein Refresh Token.

5. Zugriff auf die Ressource: Die App ruft die API des Resource Servers auf und schickt das Access Token im Header mit: Authorization: Bearer <Access Token>. Der Resource Server prüft das Token (gültig, nicht abgelaufen, passender Scope) und liefert die Protected Resource – hier die Fotos.

Warum der Umweg über den Code? Die Weiterleitung läuft über den Browser, und alles, was durch den Browser geht, kann in Verlauf, Logs oder fremden Skripten landen. Das wertvolle Access Token wird deshalb nicht über den Browser übergeben, sondern direkt zwischen App-Server und Authorization Server, und nur gegen den Nachweis, dass wirklich die registrierte App anfragt.

Tokens und Scopes

• Das Access Token ist ein Inhaber-Token (Bearer Token, RFC 6750): Wer es besitzt, darf damit zugreifen. Es wird deshalb nur per HTTPS übertragen, nicht in die URL geschrieben und ist kurz gültig (typisch 5 bis 60 Minuten). Oft ist es ein signiertes JSON Web Token (JWT, RFC 7519), dessen Echtheit der Resource Server mit dem öffentlichen Schlüssel des Authorization Servers prüft.

• Mit dem Refresh Token holt sich die App ein neues Access Token, ohne dass Du Dich erneut anmeldest. Es ist länger gültig und muss besonders geschützt gespeichert werden.

• Der Scope legt fest, welche Rechte das Token umfasst (z. B. fotos.lesen, aber nicht fotos.loeschen). Eine App fordert nur die Scopes an, die sie wirklich braucht – das entspricht der Datenminimierung nach Art. 5 DSGVO und begrenzt den Schaden, wenn ein Token gestohlen wird.

Schutzmechanismen und veraltete Varianten

• state: Ein Zufallswert, den die App in der Anfrage mitschickt und bei der Rückleitung wiedererwartet. So erkennt sie, dass die Antwort zu ihrer eigenen Anfrage gehört, und Angreifende können ihr keinen fremden Code unterschieben (Schutz vor Cross-Site Request Forgery).

• PKCE (Proof Key for Code Exchange, RFC 7636, gesprochen „Pixie“): Die App erzeugt ein Geheimnis (code_verifier) und schickt zuerst nur dessen Hashwert (code_challenge) mit. Beim Tausch des Codes muss sie das Geheimnis selbst vorlegen. Ein abgefangener Code ist so für andere nutzlos. PKCE ist besonders für Apps ohne sicheres Client-Geheimnis (Mobil-Apps, Single-Page-Anwendungen im Browser) wichtig und wird heute für alle Clients empfohlen.

• Veraltet: Der Implicit Flow (Token direkt in der Browser-Adresse) und der Resource Owner Password Credentials Grant (die App fragt Benutzername und Passwort selbst ab und reicht sie weiter) gelten nach der Sicherheitsempfehlung RFC 9700 (2025) als unsicher. Der Entwurf für OAuth 2.1, der die bewährten Teile zusammenfasst, enthält beide nicht mehr und schreibt PKCE vor (Stand Herbst 2026 noch ein Internet-Draft).

• Für die Kommunikation zwischen zwei Programmen ohne beteiligten Menschen gibt es den Client Credentials Grant: Der Dienst weist sich mit seiner eigenen Kennung und seinem Geheimnis aus.

OpenID Connect: Anmeldung auf Basis von OAuth2

OAuth2 sagt der App, dass sie auf bestimmte Daten zugreifen darf – aber nicht verlässlich, wer sich angemeldet hat. Ein Access Token ist für den Resource Server bestimmt, nicht für die App. Für „Mit Schulkonto anmelden“ oder „Mit Firmenkonto anmelden“ wird deshalb OpenID Connect (OIDC) verwendet, eine Erweiterung von OAuth2 der OpenID Foundation.

Die Grafik zeigt am Beispiel der Fotodruck-App, für wen welches Token bestimmt ist:

Im Einzelnen:

• Die App fordert zusätzlich den Scope openid an.

• Beim Tausch des Codes erhält sie neben dem Access Token ein ID-Token. Das ist ein signiertes JWT mit Angaben zur angemeldeten Person (z. B. eindeutige Kennung sub, Name, E-Mail-Adresse), zum Aussteller (iss), zur Empfänger-App (aud) und zum Zeitpunkt der Anmeldung.

• Die App prüft Signatur, Aussteller, Empfänger und Ablaufzeit und weiß dann, wer sich angemeldet hat. Sie legt eine eigene Sitzung an.

Kurz gesagt: OAuth2 = Autorisierung (Zugriff erlauben), OpenID Connect = Authentifizierung (Anmeldung) auf Basis von OAuth2. Ein Identity Provider, der OIDC spricht, ist die Grundlage für Single Sign-on im Web. In Aufgaben ist oft nur von „Login mit OAuth2“ die Rede; gemeint ist dann in der Regel genau diese Kombination.

Autorisierung umsetzen: Rollen und Rechte

Nach der Anmeldung entscheidet die Anwendung bei jeder Anfrage, ob die Person die gewünschte Aktion ausführen darf. Bewährt haben sich:

• Rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC): Rechte werden nicht einzelnen Personen, sondern Rollen zugeordnet (z. B. Mitglied, Moderation, Administration); Personen erhalten Rollen. Das macht Rechte übersichtlich und leicht zu entziehen.

• Prüfung auf Datensatzebene: Neben der Rolle zählt oft der Bezug zum Datensatz: Ein Mitglied darf seine eigene Aktivität ändern, nicht jede. Dafür wird geprüft, ob die angemeldete Person Eigentümerin des Datensatzes ist. Die Kennung der Person kommt aus der Sitzung bzw. dem Token, nie aus einem Formularfeld oder einem URL-Parameter, den Nutzende ändern könnten.

• Prinzip der minimalen Rechte (Least Privilege): Jede Person, jede Rolle und jeder Dienst bekommt nur die Rechte, die für die Aufgabe nötig sind; standardmäßig ist alles verboten, was nicht ausdrücklich erlaubt ist (Deny by Default).

• Serverseitig prüfen: Einen Button in der Oberfläche auszublenden ist Bedienkomfort, aber keine Sicherheitsmaßnahme. Wer die API direkt aufruft, umgeht die Oberfläche. Jede Prüfung gehört deshalb auf den Server.

• Protokollieren: Rechteänderungen und abgelehnte Zugriffe werden protokolliert, damit Missbrauch auffällt.

Auch die Datenbank kennt Rechte (GRANT, REVOKE); sie schützen vor allem davor, dass eine kompromittierte Anwendung mehr anrichtet als nötig. Die Rechte der einzelnen Nutzenden prüft dagegen die Anwendung.

Häufige Missverständnisse

• „Wer angemeldet ist, darf alles“ – nein, Authentifizierung und Autorisierung sind getrennte Prüfungen.

• „Passwort plus Sicherheitsfrage ist Zwei-Faktor-Authentifizierung“ – nein, beides ist Wissen.

• „OAuth2 ist ein Verfahren zur Anmeldung“ – OAuth2 regelt die Autorisierung; für die Anmeldung kommt OpenID Connect darauf.

• „Der Client ist der Mensch am Rechner“ – nein, der Client ist die Anwendung; der Mensch ist der Resource Owner.

• „Beim Login über OAuth2 bekommt die App mein Passwort“ – gerade nicht: Das Passwort gibst Du nur beim Authorization Server ein.

• „Single Sign-on ist sicherer, weil es nur ein Passwort gibt“ – nur, wenn der zentrale Zugang besonders geschützt wird (Mehr-Faktor-Anmeldung); sonst öffnet ein erbeutetes Passwort alle Türen.

• „Der Reset-Link ist sicher, weil er an die hinterlegte Adresse geht“ – die Sicherheit hängt dann am Postfach; ohne Befristung, Einmaligkeit und zweiten Kanal bleibt eine Hintertür.

Leitfragen

1. Worin unterscheiden sich Identifizierung, Authentifizierung und Autorisierung, und warum ist die Reihenfolge wichtig? Antwort

Bei der Identifizierung behauptest Du, wer Du bist (z. B. Benutzername), bei der Authentifizierung beweist Du es (z. B. Passwort gegen gespeicherten Hash), und bei der Autorisierung entscheidet das System, was Du darfst. Die Reihenfolge ist zwingend, weil Rechte nur einer bereits geprüften Identität sinnvoll vergeben werden können – und eine erfolgreiche Anmeldung ist noch keine Erlaubnis für alles; siehe Abschnitt „Wer bist Du, und was darfst Du?“.

2. Welche Authentifizierungsfaktoren gibt es, und welche Vorteile und Sicherheitsrisiken haben Passwort, Chipkarte und Fingerabdruck? Antwort

Es gibt die Faktoren Wissen, Besitz und Inhärenz. Ein Passwort (Wissen) braucht kein Gerät und ist änderbar, kann aber erraten, ausgespäht oder gephisht werden; eine Chipkarte (Besitz) hat ein Angreifer aus der Ferne nicht, sie kann aber verloren gehen oder gestohlen werden; ein Fingerabdruck (Inhärenz) ist bequem und nicht vergessbar, lässt sich aber nach einem Kopieren nicht ändern, kann zu Fehlerkennungen führen und ist als biometrisches Datum besonders schützenswert; siehe Abschnitt „Womit sich Menschen ausweisen: Wissen, Besitz, Inhärenz“.

3. Was macht eine Anmeldung zur Zwei-Faktor-Authentifizierung, und wie läuft eine Anmeldung mit Einmalpasswort ab? Antwort

Zwei-Faktor-Authentifizierung verlangt zwei unabhängige Merkmale aus unterschiedlichen Faktoren – Passwort plus Sicherheitsfrage ist zweimal Wissen und damit keine 2FA. Mit Einmalpasswort gibst Du zuerst Benutzername und Passwort ein, die Anwendung fordert dann den Code (z. B. aus der Authenticator-App) an, Du gibst ihn ein, und nur bei gültigem Code wirst Du angemeldet, bei wiederholten Fehlversuchen wird gebremst; siehe Abschnitt „Zwei Faktoren sind besser als einer: Mehr-Faktor-Authentifizierung“.

4. Welche Schwachstellen hat ein Passwort-Reset per E-Mail-Link, und wie lässt er sich sicherer gestalten? Antwort

Der Link kann über ein kompromittiertes Postfach in falsche Hände geraten, schwach gebaute Tokens lassen sich erraten, zu lange oder mehrfach gültige Links sind riskant, die Anwendung verrät eventuell, ob ein Konto existiert, und gefälschte Reset-Mails dienen dem Phishing. Sicherer ist ein zufälliges, einmaliges, kurz befristetes Token (nur als Hash gespeichert), ein zweiter Kanal oder Faktor, immer dieselbe Antwort, ein fest konfigurierter HTTPS-Link, Beenden aller Sitzungen mit Benachrichtigung nach dem Reset und eine Begrenzung der Anfragen; siehe Abschnitt „Schwachstellen beim Reset per E-Mail-Link“ und Abschnitt „Ein sichereres Vorgehen“.

5. Welche Vor- und Nachteile hat Single Sign-on unter Sicherheitsaspekten, und wie lassen sich die Nachteile verringern? Antwort

Vorteile sind nur ein Passwort, zentral umgesetzte Passwortregeln, MFA und Sperren, keine gespeicherten Passwörter in den einzelnen Anwendungen sowie zentrale Rechteverwaltung. Nachteile: Ein erbeutetes Konto öffnet alle Anwendungen (Single Point of Compromise), und fällt der Identity Provider aus, kann sich niemand anmelden (Single Point of Failure). Abhilfe schaffen Mehr-Faktor-Anmeldung am IdP, redundanter Betrieb, Überwachung ungewöhnlicher Anmeldungen und erneute Anmeldung für kritische Funktionen; siehe Abschnitt „Einmal anmelden, viele Dienste: Single Sign-on“.

6. Welche Rollen gibt es in OAuth2, und an welcher Stelle im Ablauf werden Authorization Code, Access Token und Protected Resource übertragen? Antwort

Die vier Rollen sind Resource Owner (die Person), Client (die Anwendung), Authorization Server und Resource Server. Den Authorization Code erhält der Client nach Anmeldung und Zustimmung per Weiterleitung über den Browser, das Access Token beim Tausch dieses Codes direkt vom Authorization Server, und die Protected Resource liefert der Resource Server, wenn der Client das Access Token im Authorization-Header mitschickt; siehe Abschnitt „Vier Rollen“ und Abschnitt „Der Authorization Code Flow Schritt für Schritt“.

7. Warum erhält die App zuerst einen Code und nicht direkt das Access Token, und wozu dienen state und PKCE? Antwort

Alles, was über den Browser läuft, kann in Verlauf, Logs oder fremden Skripten landen; deshalb kommt dort nur der kurzlebige, einmalige Code an, und das wertvolle Access Token wird direkt zwischen App-Server und Authorization Server gegen einen Nachweis der App getauscht. state ist ein Zufallswert, mit dem die App erkennt, dass die Antwort zu ihrer Anfrage gehört (Schutz vor CSRF), und bei PKCE muss die App beim Tausch das Geheimnis (code_verifier) zur zuvor gesendeten code_challenge vorlegen, sodass ein abgefangener Code nutzlos ist; siehe Abschnitt „Der Authorization Code Flow Schritt für Schritt“ und Abschnitt „Schutzmechanismen und veraltete Varianten“.

8. Wie unterscheiden sich OAuth2 und OpenID Connect, und was steht in einem ID-Token? Antwort

OAuth2 regelt die Autorisierung (Zugriff erlauben), OpenID Connect ergänzt darauf aufbauend die Authentifizierung: Mit dem Scope openid erhält die App zusätzlich ein ID-Token. Das ist ein signiertes JWT mit Angaben zur Person (z. B. sub, Name, E-Mail), zum Aussteller (iss), zur Empfänger-App (aud) und zum Anmeldezeitpunkt; siehe Abschnitt „OpenID Connect: Anmeldung auf Basis von OAuth2“.

9. Warum müssen Rechte serverseitig geprüft werden, und was bedeutet das Prinzip der minimalen Rechte? Antwort

Ein ausgeblendeter Button ist nur Bedienkomfort: Wer die API direkt aufruft, umgeht die Oberfläche, deshalb muss der Server jede Anfrage prüfen – inklusive der Frage, ob der Datensatz der angemeldeten Person gehört. Nach dem Prinzip der minimalen Rechte bekommt jede Person, Rolle und jeder Dienst nur die Rechte, die für die Aufgabe nötig sind, alles andere ist verboten (Deny by Default); siehe Abschnitt „Autorisierung umsetzen: Rollen und Rechte“.

Links und weitere Informationen

• Übungsaufgaben zu Authentifizierung und Autorisierung

• zum Üben mit Sequenzdiagrammen: Authentifizierung mit OAuth2 und Authentifizierung mit Passkeys

• für den Einstieg: BSI für Bürger: Zwei-Faktor-Authentisierung

• für die Praxis: OWASP Forgot Password Cheat Sheet und OWASP Authentication Cheat Sheet

• als Nachschlagewerk: RFC 6749: The OAuth 2.0 Authorization Framework und RFC 9700: Best Current Practice for OAuth 2.0 Security

• für Neugierige: OpenID Connect Core 1.0 und Entwurf OAuth 2.1

• zu Passkeys: FIDO Alliance: Passkeys

• verwandte Artikel: Kryptografie, Schutzziele und Sicherheitsrisiken, REST-API-Grundlagen

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Authentifizierung und Autorisierung: Mehr-Faktor, Passwort-Reset, Single Sign-on und OAuth2” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/authentifizierung veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/it-sicherheit/schutzmassnahmen. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]