• Was ist OAuth?
• Was ist OAuth2?
• Wie funktioniert OAuth2?

Was ist OAuth?

OAuth steht für “Open Authorization”. Dabei handelt es sich um ein offenes Standardprotokoll. Dieses Protokoll stellt eine sichere API-Autorisierung zur Verfügung. Heißt: Mittels einer API (Schnittstelle) können Daten zwischen zwei Anwendungen oder Websites übertragen werden. Damit das sicher abläuft, muss eine Autorisierung stattfinden, damit die Daten nicht von Unbefugten angefangen werden können. Diesen Job übernimmt OAuth.

Ein Beispiel
Du kennst sicher Programme oder Apps, die in deinem Namen auf Facebook einige Postings erstellen können. Damit das geschehen kann, muss dieses Programm auf die API von Facebook zugreifen. Wenn der Zugriff stattfinden, dann muss das Programm bei Facebook die Erlaubnis des Nutzers für diesen Vorgang vorweisen, damit das funktioniert.

Noch ein Beispiel
Viele Dienste bieten mittlerweile SSO (Single Sign-on) an. Heißt: Man meldet sich bei GMail an und kann sich mit den gleichen Anmeldedaten bei YouTube anmelden. Auch ist es mit SSO möglich, dass man sein Google-Mail-Konto nutzt, um sich bspw. bei GitHub zu registrieren und anzumelden. Auch vielen andere Websites bieten an, dass man sich z.B. mit seinem bestehenden Mail-Dienst anmelden kann. Wählt man diese Option, dann landet man zunächst auf ein Anmeldeformular seines Mail-Dienstes, wo nach Erlaubnis gefragt wird. Die Informationen und Daten, auf die Website zugreifen möchte, sind dort ebenfalls mit aufgeführt. Stimmt man diesen zu, werden die Profilinformationen von einem Dienst (GMail z.B.) zum Anderen (z.B. GitHub) gezogen. Mit der Bestätigung dieses Vorgangs gibt man gleichzeitig die Vollmacht – also Autorisierung – der jeweiligen Anwendung.

Was ist OAuth2?

Mittlerweile wurde OAuth durch OAuth2 fast komplett abgelöst. Von Prinzip funktioniert OAuth2 genauso wie sein Vorgänger, bringt jedoch zahlreiche Verbesserungen.

Wie funktioniert OAuth2?

Um die Funktionsweise zu verstehen, müssen zunächst die Rollen und Genehmigungsprozesse bei OAuth2 verstanden werden. Es gibt 4 Rollen:

• Resource Owner: Das ist in der Regel der Nutzer, der einem Client den Zugriff auf die eigenen Daten (=Ressourcen) gibt. Diese Daten/Ressourcen werden auf einen Ressouce Server gespeichert.
• Resource Server: Auf diesem Server liegen nun die bereitgestellten und geschützten Daten. Der Server kann nun dem Client den Zugriff auf diese Daten gewähren – dazu wird jedoch ein Access Token benötigt. Der Token ist gleichzeitig die gegebene Autorisierung (Vollmacht) des Nutzers (Resource Owners).
• Client: Das ist dann die Anwendung, App oder Website, die auf die geschützten Daten zugreifen möchte. Die Daten werden vom Ressource Server bereit gestellt.
• Authorization Server: Das ist ein Server, der den Resource Owner authentifiziert. Zudem stellt dieser Server einen Access Token für den vom Resource Owner erlaubten Anwendungsbereich (Scope) aus. Der Authorization Server wird oft zusammen mit dem Resource Server betrieben. Als Einheit werden sie dann auch als OAuth-Server bezeichnet.

Dann gibt es noch 4 verschiedene Genehmigungsprozesse, um möglichst viele Anwendungsfälle abdecken zu können. Die Genehmigungsprozesse werden auch als Grant Types bezeichnet:

• Authorization Code (Autorisierungscode): Hier wird der Resource Owner durch den Client gebeten, sich beim Authorization Server einzuloggen. Wenn das geschehen ist, wird der Resource Owner zum Client zurückgeleitet. Dabei wird auch ein Autorisierungscode erstellt und mit weitergeleitet. Mit diesem Code kann nun der Client zum Authorization Server ankloppen, um den Access-Token für einen Zugriff auf die Ressourcen des Nutzers zu bekommen.
• Implicit Authorization (Implizite Autorisierung): Funktioniert wie der Autorisierungscode, jedoch stellt hier der Authorization Server den Access Token direkt aus.
• Resource Owner Password Credentials (Passwortfreigabe): Bei diesem Prozess vertraut der Nutzer (also Resource Owner) dem Client direkt – sprich die Zugangsdaten werden dem Client direkt zur Verfügung gestellt.
• Client Credentials (Client-Berechtigung): Bei diesem Prozess greift der Client auf Daten zu, die keinen Besitzer haben und für keine Autorisierung benötigt wird.

Wie funktioniert nun OAuth2? Schauen wir uns folgenden Prozess dabei an:

1. Der Client möchte Zugang zu den Daten des Resource Owner. Daher fordert der Client eine Autorisierung beim Resource Owner an. Die Anforderung kann direkt erfolgen (Client<>Resource Owner) oder über einen Authorization Server (Client<>Authorization Server<>Resource Owner), was eher der Fall ist.
2. Wenn der Resource Owner die Genehmigung erteilt, bekommt der Client die Autorisierung. Die Autorisierung kann dabei über eines der oben 4 genannten Genehmigungsprozesse ablaufen.
3. Nun fordert der Client das Access Token vom Authorization Server an. Damit diese erteilt wird, muss der Client die Autorisierungsgenehmigung vom Resource Owner vorweisen.
4. Dann prüft der Authorization Server den Client und die Autorisierungsgenehmigung des Resource Owners.
5. Bei erfolgreicher Prüfung wird nun ein Access Token ausgestellt.
6. Jetzt kann der Client beim Resource Server anfragen, um Zugriff auf die geschützten Daten zu bekommen. Dabei muss der Client Access Token benutzen.
7. Zuletzt prüft der Resource Server den Access Token auf Gültigkeit. Wenn es passt, dann werden die Daten bereitgestellt.