Übungsaufgaben zu Authentifizierung und Autorisierung: Single Sign-on, OAuth2, Passwort-Reset und Mehr-Faktor-Anmeldung

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Authentifizierung und
Autorisierung: Single Sign-on, OAuth2, Passwort-Reset und Mehr-Faktor-
Anmeldung“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/authentifizierung
- Stilbeispiel: https://oer-informatik.de/authentifizierung-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Authentifizierung
- Autorisierung
- Single Sign-on
- OAuth2
- OpenID Connect
- Passwort-Reset
- Mehr-Faktor-Authentifizierung
- Passkeys

Kompetenzstufe: Profilkompetenz (alternativ: Basiskompetenz, Kernkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

• Authentifizierung (2 P): Prüfung, ob jemand wirklich die Person ist, für die sie sich ausgibt (Nachweis der Identität). Beispiel: Aylin Kaya meldet sich mit ihrem Schulkonto und Passwort beim Anmeldedienst an; der Anmeldedienst prüft die Angaben, und RatzFahrt weiß danach, dass wirklich Aylin angemeldet ist.

• Autorisierung (2 P): Festlegung bzw. Prüfung, was eine bereits authentifizierte Person tun darf (Rechte). Beispiel: Aylin darf eine Mitfahrt anfragen und ihre eigenen Gesuche bearbeiten, aber nicht die Angebote anderer ändern; nur Andrea Wolf (Rolle Admin) darf die Einwilligung der Erziehungsberechtigten eintragen.

Je Begriff 1 P für die Erklärung und 1 P für ein passendes Beispiel. Wichtig ist die Reihenfolge: Erst die Identität prüfen, dann die Rechte.

Je Vorteil bzw. Nachteil 2 P (1 P für die Nennung, 1 P für die Erläuterung mit Bezug zur Sicherheit). Mögliche Antworten:

Vorteile:

• Kein weiteres Passwort: Die Auszubildenden müssen sich kein zusätzliches Passwort merken. Dadurch sinkt die Gefahr, dass sie ein schwaches Passwort wählen, es aufschreiben oder dasselbe Passwort wie bei anderen Diensten verwenden.

• Keine Passwörter in RatzFahrt: RatzFahrt speichert selbst keine Passwörter oder Passwort-Hashwerte. Ein Einbruch in den RatzFahrt-Server liefert also keine Zugangsdaten; auch ein eigenes „Passwort vergessen“ entfällt.

• Zentrale Verwaltung und schnelle Reaktion: Konten und Sicherheitsregeln (Passwortregeln, Mehr-Faktor-Anmeldung, Sperren) werden an einer Stelle bei der Schul-IT OWL verwaltet. Verlässt jemand die Schule oder wird ein Konto missbraucht, wird es einmal zentral gesperrt und ist sofort auch in RatzFahrt gesperrt.

• Geprüfte Identität: Nur Personen mit einem Schulkonto, also Schüler*innen und Beschäftigte des RRB, können sich anmelden; Fremde können sich keine Konten anlegen.

Nachteile:

• Ein Zugang öffnet alles: Wird das Passwort eines Schulkontos erbeutet (z. B. durch Phishing), haben Angreifende Zugriff auf alle angeschlossenen Anwendungen gleichzeitig, also auch auf RatzFahrt mit Fahrtzeiten und Haltepunkten.

• Abhängigkeit von der Verfügbarkeit: Fällt der Anmeldedienst aus oder ist er gestört, kann sich niemand mehr bei RatzFahrt anmelden, auch wenn RatzFahrt selbst einwandfrei läuft (Single Point of Failure).

• Abhängigkeit vom Betreiber: RatzFahrt hat keinen Einfluss darauf, wie sicher der Anmeldedienst betrieben wird, und muss der Schul-IT OWL vertrauen; Fehler oder Sicherheitslücken dort betreffen auch RatzFahrt.

Beispiele (2 P, wenn die Maßnahme zum genannten Nachteil passt):

• gegen „ein Zugang öffnet alles“: Mehr-Faktor-Anmeldung am Anmeldedienst (z. B. Authenticator-App oder Passkey), damit ein erbeutetes Passwort allein nicht reicht; zusätzlich Schulung gegen Phishing und Erkennen auffälliger Anmeldungen.

• gegen die Abhängigkeit von der Verfügbarkeit: redundanter Betrieb des Anmeldedienstes (z. B. zweiter Server im Rechenzentrum der Schul-IT OWL), Überwachung und eine Vereinbarung über die Verfügbarkeit (SLA). Bereits angemeldete Nutzende bleiben bei einem kurzen Ausfall angemeldet, weil RatzFahrt eine eigene Sitzung führt.

Je richtiger Zuordnung 1 P. Der Browser hat keine eigene OAuth2-Rolle; er leitet nur weiter (User Agent). Typischer Fehler: Aylin als „Client“ zu bezeichnen – der Client ist immer die Anwendung.

Je Lücke 0,5 P für die Angabe und 0,5 P für den Weg. Auffällig: Nur der Code geht über den Browser, Token und Daten bleiben zwischen den Servern. Ein Passwort taucht in keiner Lücke auf: Aylin gibt es nur beim Anmeldedienst ein, RatzFahrt erfährt es nie.

• Die Rückleitung zu RatzFahrt läuft über den Browser (Weiterleitung mit Daten in der Adresse). Was durch den Browser geht, kann im Verlauf, in Server-Logs, über den Referer oder durch fremde Skripte bzw. Browsererweiterungen in falsche Hände geraten. (1 P)

• Deshalb wird dort nur der Authorization Code übergeben: Er ist kurzlebig, nur einmal verwendbar und allein wertlos. (1 P)

• Das eigentliche Access Token erhält RatzFahrt erst, wenn es den Code direkt (Server zu Server, per HTTPS) beim Anmeldedienst einlöst und sich dabei selbst mit client_id und client_secret (bzw. PKCE) ausweist. Wer nur den Code abfängt, kann ihn ohne das Client-Geheimnis nicht in ein Token umtauschen. (1 P)

Der Vorschlag ist abzulehnen (1 P für eine klare, begründete Position, 3 P für drei passende Gründe), z. B.:

• RatzFahrt würde das Passwort kennen. Genau das soll OAuth2 verhindern. Das Schulkonto-Passwort öffnet auch E-Mail, Lernplattform und andere Dienste; ein Fehler oder Einbruch bei RatzFahrt (z. B. Passwort im Log) gefährdet dann alle diese Dienste.

• Phishing wird gefördert. Wenn Auszubildende es gewohnt sind, ihr Schulkonto-Passwort in fremde Formulare einzugeben, erkennen sie gefälschte Anmeldeseiten schlechter. Die Anmeldung soll immer auf der bekannten Adresse des Anmeldedienstes stattfinden.

• Mehr-Faktor-Anmeldung und Freigabe gehen verloren. Ein zweiter Faktor, die Freigabe der Daten (Scopes) und spätere Verbesserungen des Anmeldedienstes (z. B. Passkeys) funktionieren nur auf der Seite des Anmeldedienstes.

• Das Verfahren gilt als veraltet. Die Weitergabe von Benutzername und Passwort durch die App (Resource Owner Password Credentials Grant) wird nach RFC 9700 nicht mehr empfohlen und ist im Entwurf von OAuth 2.1 nicht mehr enthalten; der Anmeldedienst der Schul-IT OWL würde es vermutlich gar nicht zulassen.

Für das Design-Anliegen gibt es eine bessere Lösung: Der Anmeldedienst kann den Namen und das Logo von RatzFahrt anzeigen, und die Startseite von RatzFahrt erklärt mit einem Satz, dass man zur Anmeldung zur Schulseite weitergeleitet wird.

Scope (1 P): Ein Scope legt fest, auf welche Daten bzw. für welche Aktionen ein Access Token berechtigt. Der Client fordert die Scopes in der Autorisierungsanfrage an, die Person sieht sie bei der Freigabe, und der Resource Server liefert nur Daten, die vom Scope des Tokens gedeckt sind.

Auswahl (3 P, Abzug je fehlendem nötigen oder überflüssigen Scope):

• anfordern: openid (Anmeldung, Zuordnung zum Konto), profil (Name für bestätigte Mitfahrende und für die Verwaltung), email (Erinnerungen werden laut Projektfestlegung per E-Mail an das Schulkonto verschickt), klasse und schultage (passende Fahrten zu den Berufsschultagen finden), volljaehrig (Minderjährige brauchen die Einwilligung der Erziehungsberechtigten).

• nicht anfordern: geburtsdatum – für die Regel reicht die Information „volljährig ja/nein“; das vollständige Geburtsdatum wäre mehr als nötig. adresse – Treffpunkte sind öffentliche Haltepunkte, Wohnadressen werden ausdrücklich nicht verwendet. noten – haben mit Fahrgemeinschaften nichts zu tun.

Hinweis: Die bisherige Tabelle nutzer speichert ein Geburtsdatum. Wer geburtsdatum mit Verweis darauf wählt, erhält die Punkte nur, wenn erkannt wird, dass volljaehrig datensparsamer ist. Da sich die Volljährigkeit im Laufe des Schuljahres ändert, wird volljaehrig bei jeder Anmeldung neu abgefragt.

• ID-Token (1,5 P): gehört zu OpenID Connect und dient der Authentifizierung. Es ist ein vom Anmeldedienst signiertes JSON Web Token mit Angaben zur angemeldeten Person (z. B. Kennung sub, Name), zum Aussteller und zur Empfänger-App. RatzFahrt prüft Signatur, Aussteller, Empfänger und Ablaufzeit, weiß dann, wer sich angemeldet hat, ordnet die Person ihrem Datensatz in nutzer zu und legt eine eigene Sitzung an.

• Access Token (1,5 P): gehört zu OAuth2 und dient der Autorisierung gegenüber der Schuldaten-API. RatzFahrt schickt es bei jedem Aufruf im Header Authorization: Bearer … mit; es berechtigt nur für die freigegebenen Scopes (z. B. Klasse, Schultage) und ist kurz gültig. RatzFahrt wertet es nicht selbst aus.

Je Zeile 1 P (0,5 P für die Entscheidung, 0,5 P für die Begründung). Zu Zeile 5: Laut Datenbestand hat Lina früher bereits eine Anfrage zu Angebot 1 gestellt, die abgelehnt wurde. Das hätte der Server gar nicht annehmen dürfen – ein Hinweis darauf, dass die Sperre bisher nur in der Oberfläche geprüft wurde.

• Der Server ermittelt die angemeldete Person aus der Sitzung bzw. dem Token (nicht aus einem Feld der Anfrage), liest Angebot 5 aus der Datenbank und vergleicht fahrer_id mit der Kennung der angemeldeten Person. Weil sie nicht übereinstimmen (und Ben keine Rolle mit Sonderrechten hat), wird die Änderung nicht ausgeführt und der Versuch protokolliert. (1 P)

• Statuscode 403 Forbidden: Ben ist angemeldet (also nicht 401 Unauthorized), aber nicht berechtigt. (1 P)

Grundsatz: Rechte werden immer serverseitig geprüft, alles nicht ausdrücklich Erlaubte ist verboten (Deny by Default).

1. 4 Punkte · b) 10 Punkte (8 + 2) · c) 13 Punkte (4 + 6 + 3) · d) 4 Punkte · e) 7 Punkte (4 + 3) · f) 8 Punkte (6 + 2) · Summe 46 Punkte

Je Mangel 1 P, je passende Verbesserung 1 P. Mögliche Mängel:

• Annahme (1 P): Wer das Postfach der hinterlegten Adresse lesen kann, ist die Person, der das Konto gehört. Das Postfach ist damit der einzige Nachweis der Identität.

• Begründung (1 P): Der Link kann zufällig, kurz gültig und einmalig sein – er landet trotzdem im richtigen Postfach, das inzwischen nur einer anderen Person gehört. Gegen eine Übernahme des Postfachs (neu vergebene Adresse, erbeutetes Mailpasswort, Mitlesen im Haushalt) helfen Verbesserungen am Token nicht. Dafür braucht es einen zweiten Nachweis, der nicht vom Postfach abhängt.

Je Erweiterung 1 P für eine passende Bewertung, 2 P für eine schlüssig begründete Empfehlung.

• SMS-Code: unabhängig vom Postfach und für viele bequem. Aber vier von zwölf aktiven Konten im Testbestand (ein Drittel) haben keine Mobilnummer und kämen nicht weiter. SMS sind nicht Ende-zu-Ende-verschlüsselt, die Nummer kann per SIM-Swapping übernommen werden, und Let’s Meet müsste zusätzliche Telefonnummern speichern (Datenminimierung).

• Vorhandener zweiter Faktor: der stärkste Schutz, ein Passkey ist sogar phishingresistent. Er wirkt aber nur für Nutzende, die ihn eingerichtet haben, und hilft nicht, wenn gerade das Smartphone verloren gegangen ist.

• Wiederherstellungscodes: brauchen weder Telefonnummer noch Smartphone und funktionieren für alle Konten. Viele bewahren die Codes aber nicht auf; liegen sie neben dem Passwort, schützen sie wenig.

• Empfehlung, z. B. gestuft: Wer einen zweiten Faktor hat, muss ihn verwenden; alle anderen bestätigen mit einem Wiederherstellungscode; ein SMS-Code wird nur dort angeboten, wo eine Nummer freiwillig hinterlegt ist. Als letzter Weg prüft der Support die Identität (z. B. über den bei der Verifizierung hinterlegten Altersnachweis), ohne das Passwort zu erfahren. Zusätzlich: Benachrichtigung bei jeder Passwortänderung und Abmelden aller Sitzungen.

Andere begründete Empfehlungen sind ebenfalls richtig.

• Bei der Mehr-Faktor-Authentifizierung weist sich eine Person mit mindestens zwei voneinander unabhängigen Merkmalen aus verschiedenen Faktoren aus (Wissen, Besitz, Inhärenz). Wer nur ein Merkmal erbeutet, z. B. das Passwort, kommt nicht ins Konto. (1 P)

• Passwort und Sicherheitsfrage gehören beide zum Faktor Wissen. Sie können auf demselben Weg erbeutet werden (z. B. auf derselben Phishing-Seite), sind also nicht unabhängig. (1 P)

Je richtiger Zuordnung 0,5 P. Typischer Fehler: Den Code aus App oder SMS als „Wissen“ einzuordnen – man kennt ihn nur, weil man das Gerät besitzt.

Je richtig ergänzter Zelle 1 P (6 Zellen). Andere sinnvolle Vorteile und Risiken sind ebenfalls richtig.

Ablauf (3 P):

• Bei der Registrierung erzeugt das Gerät für Let’s Meet ein eigenes Schlüsselpaar. Nur der öffentliche Schlüssel wird an den Server geschickt und beim Konto gespeichert; der private Schlüssel bleibt auf dem Gerät bzw. im Passwortmanager. (1 P)

• Bei der Anmeldung schickt der Server eine zufällige Herausforderung (Challenge). Die Person entsperrt ihr Gerät mit Fingerabdruck, Gesicht oder Geräte-PIN, und das Gerät signiert die Challenge mit dem privaten Schlüssel. (1 P)

• Der Server prüft die Signatur mit dem gespeicherten öffentlichen Schlüssel; passt sie, ist die Person angemeldet. (1 P)

Vorteile (je 1 P, zwei verlangt):

• Kein Geheimnis auf dem Server: Bei einem Einbruch in die Datenbank werden nur öffentliche Schlüssel erbeutet, mit denen man sich nicht anmelden kann – anders als bei Passwort-Hashwerten, die offline durchprobiert werden können.

• Phishingresistent: Der Browser bietet den Passkey nur auf letsmeet.example an; eine nachgemachte Seite kann ihn nicht abfragen. Ein Passwort dagegen kann man auf jeder Seite eintippen.

• Nichts zu vergessen: Es gibt kein Passwort, das vergessen werden kann; der Reset-Link – eine typische Schwachstelle – wird seltener gebraucht.

• Zwei Faktoren in einem Schritt: Besitz des Geräts und Entsperren (Inhärenz oder Wissen) wirken zusammen.

Der Text nennt auch eine Einschränkung: Passwort und Reset-Link bleiben als Rückfallweg bestehen. Deren Sicherheit (siehe a und b) bleibt deshalb wichtig.

1. 8 Punkte · b) 7 Punkte (2 + 5) · c) 12 Punkte (2 + 4 + 6) · d) 5 Punkte · Summe 32 Punkte