Eine Präsentation zur Einführung in OAuth 2.0

1. OAuth 2.0

2. OAuth 2.0
- standardisiertes Protokoll/Autorisierungsframework
- Ermöglicht es Clients (z.B. Webanwendungen) auf Ressourcen eines Benutzers
zuzugreifen. Diese Ressourcen liegen auf einem Ressourcenserver
- Anmeldedaten (Benutzernamen und Passwort) werden dabei nicht direkt preisgegeben!

3. Ablauf
- Wir haben eine Client-Anwendung (z.B. Web- oder Mobilanwendung)
- Diese muss beim Autorisierungsserver registriert werden
- Wir erhalten dazu eine Client-ID und ein Client-Secret
Beispiel:
Entwickler der Fitness-Tracker-App registriert die Anwendung bei Google, um
Client-ID und Client-Secret zu erhalten. Die Anwendung gibt die Redirect-URIs
an, zu denen Google nach der Authentifizierung weiterleiten soll

4. Ablauf
- Benutzer initiiert den Ablauf, indem er auf der Client-Anwendung eine
Aktion ausführt, die eine Anmeldung oder Zugriffsberechtigung
erfordert
- Die Client-Anwendung leitet den Benutzer dann zum
Autorisierungsserver weiter, wo der Benutzer aufgefordert wird, sich
anzumelden (falls nötig) und der Anwendung Zugriff auf bestimmte
Ressourcen zu gewähren
Beispiel:
Wir haben in unserer Fitness-App einen Button “Mit Google anmelden”. Die
App leitet den Benutzer zu Google mit der Autorisierungsanfrage um,
einschließlich der Client-ID und der angeforderten Berechtigungen (z.B. Zugriff
auf die E-Mailadresse)

5. Ablauf
- Benutzer erteilt die Einwilligung auf dem
Autorisierungsserver, indem er die angeforderten
Berechtigungen bestätigt
- Der Autorisierungsserver sendet daraufhin den Benutzer
zurück zur Client-Anwendung, üblicherweise mit einem
Autorisierungscode
Beispiel:
Google fordert den Benutzer also auf, sich einzuloggen. Dies stellt
sicher, dass der Benutzer die Anfrage versteht und explizit
zustimmt

6. Ablauf
Die Client-Anwendung sendet den Autorisierungscode zusammen mit
ihrer Client-ID und dem Client-Secret zurück an den
Autorisierungsserver, um seine Identität zu bestätigen
- Im Gegenzug sender der Autorisierungsserver einen Access Token (bzw.
Refresh Token) an die Client-Anwendung
Beispiel:
Nach Authentifizierung und Zustimmung durch den Benutzer leitet Google den
Benutzer zurück zur Redirect-URI der Fitness-App, einschließlich eines
Autorisierungscodes

7. Ablauf
- Die Client-Anwendung verwendet den Access Token, um beim
Ressourcenserver Anfragen im Namen des Benutzers zu stellen
- Der Ressourcenserver validiert den Access Token und gewährt bei
erfolgreicher Validierung Zugriff auf die angeforderten Ressourcen
Beispiel: Die Fitness-App extrahiert den Autorisierungscode aus der
Weiterleitung und machen einen Server-zu-Server-Aufruf an Google, um den
Autorisierungscode gegen einen Access Token einzutauschen. Die Anfrage
beinhaltet den Autorisierungsocde, die Client-ID, das Client-Secret und die
Redirect-URI. Google authentifiziert die Anwendung mithilfe Client-ID und
Secret. Wenn alles gültig, gibt es einen Zugriffstoken!

8. Sessionmanagement
- Die App kann das Zugriffstoken sicher speichern und für nachfolgende Anfragen bis zum
Ablauf verwenden.
- Bei Bedarf kann das Aktualisierungstoken verwendet werden, um ein neues
Zugriffstoken zu erhalten, ohne dass der Benutzer sich erneut authentifizieren muss.

9. Abmeldung und Widerruf
- Der Benutzer kann die Berechtigungen jederzeit in seinen Google-Kontoeinstellungen
widerrufen.
- Die App sollte ebenfalls eine Option zum Abmelden bereitstellen, um das Zugriffstoken
zu löschen und die Session zu beenden.

12. Workflow - Darstellung

13. Beispiel
Wir werden ein Beispiel durchcoden und sehen in diesem Beispiele wesentliche Dinge des
OAuth 2.0 Workflows

14. Beispiel
Hier wird Express initialisiert und Middlewares
für die Verarbeitung von URL-kodierten Daten,
Sessions und Passport (für Authentifizierung)
konfiguriert. Die session-Middleware ist
wichtig für das Tracking von
Benutzersitzungen über mehrere Anfragen
hinweg, was ein Schlüsselelement nach der
Authentifizierung im OAuth 2.0-Workflow ist.

15. Beispiel
Dieser Teil des Codes konfiguriert die Google
OAuth 2.0-Strategie mit den
Umgebungsvariablen CLIENT_ID und
CLIENT_SECRET. Die callbackURL ist der Ort,
an den Google den Benutzer nach erfolgreicher
Authentifizierung und Autorisierung
weiterleitet. Innerhalb der Callback-Funktion
erfolgt dann die Verarbeitung des
Benutzerprofils, was typischerweise das
Suchen oder Erstellen eines Benutzers in der
Datenbank umfasst. Dies ist direkt Teil des
OAuth 2.0-Workflows, wo nach der
Authentifizierung und Erlangung des
Zugriffstokens Benutzerinformationen von
Google abgerufen werden.

16. Beispiel
Der erste Endpunkt leitet Benutzer zur Authentifizierung
mit Google weiter. Hier beginnt der OAuth 2.0-
Authentifizierungsprozess, indem der Benutzer
aufgefordert wird, sich bei Google anzumelden und der
Anwendung Zugriff zu gewähren. Der Scope ["profile"]
definiert, welche Informationen die Anwendung anfordert.
Der zweite Endpunkt ist die callbackURL, die in der
GoogleStrategy konfiguriert wurde. Nach der
Authentifizierung und Autorisierung durch Google wird
der Benutzer zusammen mit dem Autorisierungscodes an
diesen Endpunkt weitergeleitet. Passport handhabt dann
den Austausch des Autorisierungscodes gegen ein
Zugriffstoken und ruft das Benutzerprofil ab. Bei
Fehlschlag wird der Benutzer zum /login umgeleitet; bei
Erfolg wird er zur Homepage (/) weitergeleitet.

17. Beispiel
serializeUser und deserializeUser sind für das
Management der Benutzersitzungen
verantwortlich. Wenn ein Benutzer authentifiziert
wird, wird seine user.id in der Sitzung gespeichert.
Bei nachfolgenden Anfragen wird die ID aus der
Sitzung extrahiert und verwendet, um den
Benutzer aus der Datenbank zu laden. Dies ist ein
wichtiger Schritt nach der Authentifizierung, um
den Benutzer über mehrere Anfragen hinweg als
angemeldet zu kennzeichnen, ohne dass er sich
erneut authentifizieren muss.