Was ist OAuth2?

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.

Werbeanzeigen

Was ist 2-Faktor Authentifizierung?

Beim Thema 2-Faktor Authentifizierung, geht es darum, wie ein Benutzer sich in einem System einloggen kann. Ob das dabei eine Webseite oder ein Server ist, ist unerheblich. Liest man im Internet zu dem Thema, wird grundsätzlich gesagt, dass 2-Faktor Authentifizierung gewährleistet ist, wenn der Benutzer etwas Bestimmtes weiss und etwas Bestimmtes besitzt.

Grundsätzlich gilt: Aus der folgenden Liste der Authentifizierungsklassen muss der Benutzer zwei von den drei Punkten besitzen/erfüllen/wissen, um 2-Faktor Authentifizierung zu gewährleisten.

Die drei Authentifizierungsklassen

1. Etwas was du weisst – Benutzername und Passwort
2. Etwas was du hast – Login-Karte, Zertifikat
3. Etwas was du bist – Fingerabdruck, Iris-Scan

Das heisst gleichzeitig, wenn ein Benutzer zwei Passwörter eingeben muss, ist das nicht 2-Faktor Authentifizierung.

Was ist Mutual SSL Authentication?

Mutual Authentication referenziert sich darauf, dass sich zwei Parteien gegenseitig authentifizieren. Es wird auch zertifikatbasiertes gegenseitiges Authentifizieren genannt. Die zwei Parteien verifizieren sich dabei anhand der ausgetauschten digitalen Zertifikaten, so dass jede Partei sicher sein kann, mit wem sie spricht.

Es geht also darum, dass sich ein Client (etwa ein Webbrowser) einem Server gegenüber authentifiziert. Der Server wiederum macht dasselbe beim Client. Der Server prüft dafür das Public Key Certificate/digitale Zertifikat, welches von einer zertifiziertern Stelle, der Certificate Authority (CA) ausgestellt wurde. Die Authentifizierung im Netz basiert auf Zertifikaten, weshalb Anbieter wie Verisign Microsoft Certificate Server ein wichtiger Teil der Prozesses sind. Grosse Firmen haben dabei üblicherweise ihre eigene CA.

Die benötigten Schritte

Grob betrachtet sind bei einer Mutual Authentication folgende Schritte durchzuführen:

1. Ein Client beantragt Zugang zu einer geschützten Ressource

2. Der Server präsentiert sein Zertifikat dem Client

3. Der Client verifiziert dieses Zertificate

4. Ist der Client zufrieden, sendet er sein Zertifikat dem Server

5. Der Server überprüft die Eigenschaften des Clients

6. Ist der Server zufrieden, gibt er dem Client Zugang zu der gewünschten Ressource

Der Unterschied zur SSL Authentifizierung

Mutual Authentication funktioniert ähnlich wie die SSL (Secure Socket Layer) Authentifizierung. Der Unterschied ist jedoch, dass noch die Client Authentifizierung mittels Zertifikaten dazukommt. Mutual Authentication wird deshalb auch Two way SSL authentication genannt.

Will man genau verstehen, bei einer SSL Authentifizierung geschieht, sollte man die Spezialitäten der Handshake Nachrichten kennen.

SSL Authentication Handshake

Bei der SSL Authentifizierung wird dem Client das Server Zertifikat angezeigt – Der Server authentifiziert sich also gegenüber dem Client. Der Client probiert dann die CA des Serverzertifikat in der Liste der CA’s zu finden, denen er vertraut (trusted CA’s). Während des ganzen Prozesses werden neun Nachrichten ausgetauscht.

1. Der Client sendet die Nachricht ClientHello mit einem Vorschlag von SSL Optionen

2. Der Server antwortet mit dem ServerHello und wählt darin die SSL Optionen

3. Der Server schickt sein Server Zertifikat

4. Der Server bestätigt seine Nachricht mit einem ServerHelloDone

5. Der Client schickt die Session Key Information in einer ClientKeyExchange Nachricht – Verschlüsselt mit dem Public Key des Servers, welche er aus dem Zertifikat entnommen hat

6. Der Client schickt die ChangeCipherSpec Nachricht um die gewählte Verschlüsselungsmethode zu bestätigen

7. Der Client schickt eine Finished Nachricht, damit der Server die aktivierten Optionen prüfen kann

8. Der Server schickt ebenfalls eine ChangeCipherSpec Nachricht, um die gewählte Verschlüsselungsmethode zu aktivieren.

9. Der Server schickt ebenfalls eine Finished Nachricht zum Abschluss

Mutual SSL Authentication

Bei der Mutual SSL Authentication authentifizieren sich der Server und der Client gegenseitig. Um einen verschlüsselten Kanal zu öffnen werden insgesamt 12 Nachrichten verwendet.

1. Der Client sendet die Nachricht ClientHello mit einem Vorschlag von SSL Optionen

2. Der Server antwortet mit dem ServerHello und wählt darin die SSL Optionen

3. Der Server schickt sein Server Zertifikat

4. Der Server verlangt das Zertifikat des Kunden in einem CertificateRequest, damit die Verbindung gegenseitig authentifiziert werden kann

5. Der Server bestätigt seine Nachricht mit einem ServerHelloDone

6. Der Client antwortet mit seinem Client Zertifikat

7. Der Client schickt die Session Key Information in einer ClientKeyExchange Nachricht – Verschlüsselt mit dem Public Key des Servers, welche er aus dem Zertifikat entnommen hat

8. Der Client schickt eine CertificateVerify Nachricht, um den Server wissen zu lassen, dass er der Besitzer des Zertifikats ist

9. Der Client schickt die ChangeCipherSpec Nachricht um die gewählte Verschlüsselungsmethode zu bestätigen

10. Der Client schickt eine Finished Nachricht, damit der Server die aktivierten Optionen prüfen kann

11. Der Server schickt ebenfalls eine ChangeCipherSpec Nachricht, um die gewählte Verschlüsselungsmethode zu aktivieren.

12. Der Server schickt ebenfalls eine Finished Nachricht zum Abschluss

Die Nachrichten mit Wireshark aufgenommen:

mutualauthenticationpic

Klick mich für das Bild in gross