17.02.2017

OAuth2 ist ein Sicherheitsprotokoll, um eine Webapplikation sicher zu machen und Benutzer zu authentifizieren und authorisieren. OAuth2 wird etwa bei Facebook oder Github verwendet.

Warum OAuth2?

Eine typische Webapplikation wird vom Benutzer am Client verwendet, welcher sich beim Server anmelden muss, zum Beispiel über REST Services. Normalerweise verwendet der Benutzer dafür seinen Benutzernamen und ein Passwort. Diese könnte man nun mit jeder REST Anfrage mitsenden. Dies hat aber einen Nachteil: Benutzername und Passwort müssten bei jeder Anfrage vom Server überprüft werden.

Häufig sind Services mit BasicAuth geschützt. Dort wird bei jeder Anfrage der Benutzername und das Passwort im Header mitgeschickt, codiert mit Base64.

Der Vorteil von OAuth2 ist, dass das Passwort nur einmal beim Login verschickt werden muss. Zurück kommen dann zwei Tokens, das Access Token und das Refresh Token. Das Access Token hat dabei eine beschränkte Gültigkeit. Falls dieses abgelaufen ist, kann der Client ein neues mit Hilfe des Refresh Token bestellen.

Die Tokens werden üblicherweise persistiert, weil in einer modernen Infrastruktur verschiedene Instanzen von Applikationsserver die Benutzerrequests bearbeiten können und dafür Zugriff auf die Tokens benötigen.

Wie funktioniert die Anmeldung?

OAuth2 verwendet also Zugriffstokens / Access Tokens für Anfragen und verzichtet vollständig auf digitale Signaturen, was den Umgang viel einfacher macht. Zum Glück setzt OAuth2 auch vollständig auf HTTPS.

Folgende Schritte werden in OAuth2 gemacht:

1. Der Benutzer wird nach seinem Benutzernamen und Passwort gefragt. Diese werden dem Server, etwa eine Buchhaltungswebpage, übergeben. Der Benutzer erhält dann einen sogenannten Access Grant, also die Erlaubnis, weiterzumachen.
2. Die Anfrage wird zum Authorisierungsserver weitergeleitet, der die Daten prüft.
3. Sind die Daten gültig, erstellt der Server ein Access Token und ein Refresh Token
4. Mit dem Access Token kann der Benutzer nun auf die Dienste des Anbieters zugreifen

Im OAuth2 Jargon redet man dabei vom Serviceanbieter von einem Ressource Owner, das sich das Protokoll als ressourcenbasiert sieht.

Was für eine Antwort erhält man von der Authentifizierung?

Wenn die Anmeldung beim Authorisierungsserver geklappt hat, erhält man eine Antwort im JSON Format mit den relevanten Informationen:

{
"access_token": "asdfwerpoiupou",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "opiulfgasdfwer"
}

Darin steht auch gleich, wie lange das Token gültig ist.

Was ist der Token Type Bearer?

Das Token, dass man erhält, ist ein sogenanntes Bearer Token. Mit diesem kann man auf die gewünschten Ressourcen zugreifen. Damit das Token geschützt bleibt, sollte es über eine mit TLS gesichterte Verbindung gehen – weshalb TLS auch Voraussetzung ist für die Verwendung des Tokens.

Das Access Token muss dann in der nächsten Anfrage im Authorization Header mitgeschickt werden.

In Java kann man den Authorization Header folgendermassen befüllen:

HttpPost request = new HttpPost("http://example.com/auth");
request.addHeader("Authorization", "Basic asdfwerpoiupou ");

JWT bei Architektur mit vielen Applikationsinstanzen

Wie gesagt muss das Token auf die eine oder andere Art persistiert werden. Dies kann zum Beispiel über eine In Memory Datenbank geschehen. Diese Datenbank hätte dann den Zugriff auf alle Applikationsinstanzen geben müssen, welche die Token benötigen. Hat man etwa einen REST Service, der OAuth2 verwendet, zwanzig Mal instanziert, müssen diese Instanzen das Token lesen können.

Eine weitere Option wäre der Einsatz von JSON Web Tokens = JWT. Die Authentifizierung erfolgt dabei mit einem Schlüssel, der sich aus verschiedenen Metainformationen des Benutzers zusammensetzt. So kann jede Instanz des Services prüfen, ob das aktuelle Token gültig ist.

Um zu prüfen, ob ein Token für den Benutzer existiert, wird ein JWT Repository angefragt. Es entschlüsselt das Token und gibt die benötigten Informationen zurück.

Besuchen Sie doch einmal https://jwt.io/ um ein Beispiel eines Tokens zu sehen. Im Header wird der Verschlüsselungsalgorithmus genannt. Im Payload sieht man schön die Daten wie etwa der Name des Benutzers.