Das erste Bild zeigt, wie ein Anwender mit seinem Device über eine mobile Anwendung z.B. E-Mail Programm von einem unbekannten Unternehmen die E-Mails (Resources) von einem z.B. Google Server (Resource Server) abfragen möchte. Für das Vorhaben muss der Anwender innerhalb der mobilen Anwendung seine Google Zugangsdaten eingeben. Jedoch ist das Ganze mit gewissen Risiken verbunden, da a) das E-Mail Programm das Passwort speichern kann und b) die Anwendung das Passwort verwenden kann, um z.B. auf andere Google Dienste zuzugreifen.
OAuth (Open Authorization) ist ein offenes Protokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Anwendungen erlaubt.
Ein Endbenutzer (User oder Resource Owner) kann mit Hilfe dieses Protokolls einer Anwendung (Client oder Third-Party) den Zugriff auf seine Daten erlauben (Autorisierung), die von einem anderen Dienst (Resource Server) bereitgestellt werden, ohne geheime Details seiner Zugangsberechtigung (Authentifizierung) dem Client preiszugeben. Der Endbenutzer kann so Dritte damit beauftragen in seinem Namen einen Dienst zu konsumieren. Typischerweise wird dabei die Übermittlung von Passwörtern an Dritte vermieden. [wikipedia]
Bevor das Gerät überhaupt eine Anfrage an den OAuth Server stellen kann, muss sich dieser zunächst einmal registrieren. Nach der Registrierung erhält das Gerät unter dem Endpoints /auth ein Authentifizierungs-Code. Hierfür muss das Gerät unter Anderem seine Client-ID, den er bei der Registrierung verwendet hat an den OAuth Server übertragen Bsp.: https://server.com/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=email&state=1234zyx
| https://server.com/auth | Authentifizierung Endpoint des Servers |
| response_type=code | Spezifiziert, dass die Anwendung ein Authentifizierungs-Code (grant) erhalten möchte. |
| client_id | Geräte ID welches für die OAuth Server Registrierung verwendet wurde. |
| redirect_url | Zu dieser Seite wird der Anwender nach der erfolgreichen Authentifizierung weitergeleitet. |
| scope | Hier gibt das Gerät an, auf welche Resourcen z.B. E-Mails er zugreifen möchte. |
Bevor der Authentifizierungs-Code ausgestellt wird, setzt sich der OAuth Server mit dem Eigentümer der Dateien bzw. E-Mails in Verbindung. Um sicher zu gehen, dass es sich bei dem Eigentümer um die richtige Person handelt, muss sich dieser zunächst einmal durch Eingabe seiner Zugangsdaten Authentifizieren. Hierfür wir er auf eine Loginseite weitergeleitet.
Nachdem sicher gestellt wurde, dass es sich um die richtige Person handelt, erhält der Eigentümer eine Liste über alle Ressourcen, worauf der Client zugreifen möchte z.B. E-Mails. Der Eigentümer muss diese Anfrage bestätigen.
Erst jetzt generiert der OAuth Server den Authentifizierungs-Code (NICHT Token), den er an den Client sendet. Dieser Code repräsentiert den Eigentümer + Zugriffserlaubnis für die E-Mails. Der Authentifizierungs-Code bleibt nur für ein paar Minuten gültig.
Jetzt kann der Client den Endpoint /token aufrufen, sich zunächst einmal Authentifizieren und den zuvor erhaltenen Authentifizierungs-Code an den OAuth Server übertragen.
Anschließend werden die Zugangsdaten des Clients und der
Authentifizierungs-Code validiert. Sollten beide Informationen korrekt sein, wird ein ‚Access Token‘ generiert und an den Client gesendet. Die E-Mail Anwendung ist für die sichere Aufbewahrung des Tokens verantwortlich.
Als nächstes fragt der Client bei ‚Resource Server‘ nach den E-Mails. Jedoch muss der Server erst einmal sicherstellen, dass der Client in der Zwischenzeit immer noch damit beauftragt ist die die E-Mails abzufragen.
Daher fragt der ‚Resource Server‘ den ‚OAuth Server‘ ob der Token noch gültig ist.
Anschließend wird der ‚Resource Server‘ über Status der Validierung informiert.
Und erst an dieser Stelle werden die E-Mails an den Client übertragen.
Image Licence:
„Designed by Freepik“
„Designed by macrovector / Freepik“
„Designed by rawpixel.com / Freepik“