Secure REST by OAuth2

Absichern einer REST-API mittel OAuth2

OLIVER WRONKA

02. APRIL 2014

Secure REST by OAuth2

2

Absichern einer Server zu Server Kommunikation

OAuth2 wird häufig in der Server zu Server Kommunikation genutzt.

» Typischerweise wird OAuth2 genutzt, um die Kommunikation zwischen zwei Servern abzusichern.

» Diese wird in der Regel durch einen Nutzer angestoßen, der diese Kommunikation initiieren möchte.

» Beispiel: Zugriff auf meine Bilder auf einem Bilderdienst (Ressource) mittels eines Account bei einem sozialen Netzwerk (Authorization) -> Authorization Code (or Web Server) Flow

3

Die Laufzeitsicht des Authorization Code (or Web Server) Flow ist recht komplex.

4

In der OAuth2-Spezifikation sind einige Punkte nicht spezifiziert:

Das OAuth2 Protokoll enthält Spezifikationslücken

» Ein Token erhält eine Gültigkeitsdauer. Es wird jedoch keine Aussage darüber gemacht, wie diese aussieht und wie diese geprüft werden soll.

» Es wird auch keine Aussage darüber gemacht, wie ein Token abgesichert werden sollte oder wie der Ressource Server die Gültigkeit eines Tokens prüfen soll.

5

Resource Owner Password Credential Flow

Der weniger bekannte Resource Owner Password Credential Flow eignet sich sehr gut zur Absicherung einer REST-API

» Es geht darum, einen mobile Client mittels OAuth2 den Zugriff auf eine REST API eines Backendservice zu ermöglichen.

» Es soll auch die Absicherung sowie Prüfung des Access Token spezifiziert werden.

» Hierzu eignet sich der eher unbekannte Resource Owner Password Credential Flow.

» Der Flow wird hier auch gleich um eine Rechteverwaltung aufgebohrt.

6

Die Laufzeitsicht Resource Owner Password Credential Flow ist sehr einfach.

Parameter Beschreibunggrant_type: Pflichtfeld, muss mit „password“ vorbelegt sein.username: Pflichtfeldpassword: Pflichtfeld, aber hier wird nur der Hash (z. B. sha1) des Benutzer-

passworts übergebenscope: Optional, eine Liste von angeforderten Rechten auf Ressourcen, z. B.

…&scope=CUSTOMER%20ORDER&…

7

Beispiel für eine Antwort

Parameter Beschreibungaccess_token: Pflichtfeld, das eigentliche Token. OAuth2 macht keine Angaben zum Aufbau oder Inhalt.created_at: Timestamp der Ausstellungexpires_in: Hier Gültigkeit des Token in Sekunden.refresh_token: Das optionale Token um ein abgelaufenes Access Token durch ein neues, gültiges Token zu

ersetzen.scope: Basierend auf dem Scope-Parameter hier nun die Ausprägung der Rechte.signature: Signatur des Servers über die Attribute access_token, created_at, expires_in sowie scope.token_type: Pflichtfeld, muss hier immer „bearer“ sein.

HTTP/1.1 200 OK Status Code: 200 OK Cache-Control: no-store Content-Type: application/json Date: Tue, 18 Mar 2014 15:12:59 GMT Pragman: no-cache Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=kZKo-9ydALi+l2Hjx1yN2zJA; Path=/services Transfer-Encoding: chunked

{ "access_token": "d4f7a44b7...", "created_at": 1395155558001, "expires_in": 3600, "refresh_token": "e908766e81372737...", "scope": [ [ "CUSTOMER", "CRUD" ], [ "ORDER", "CRUD" ] ], "signature": "c18ed169dd30f401bd90eb34cea60a19...", "token_type": "bearer"}

8

Gültigkeit eines Token

Die Gültigkeit eines Token muss selbst spezifiziert werden

» Die OAuth2-Spezifikation gibt nur an, dass eine Gültigkeitsdauer in Sekunden für das Token übergeben wird.

» Um diese zu prüfen müsste also noch mindestens ein Zeitstempel zum Ausstellzeitpunkt hinzugefügt werden. Mögliche Option ist ein Datum im Response Header z. B. Date: Mon, 10 Mar 2014 13:20:32 GMT

» Alternative: Den Ablaufzeitpunkt direkt als Zeitstempel im Accesstoken übergeben.» Mögliche Ausprägungen sind Anzahl in ms seit 1970, für einen Timestamp mit 5

Minuten Gültikeit also

new java.util.Date().getTime() + 5 * 60 * 1000

» Zeitzone wird nicht mitgeliefert, diese muss also per Konvention vereinbart werden z.B. UTC+0 bzw. die beteiligten Server müssen in der gleichen Zeitzone stehen.

» Alternativ: Als UTC-String mit Zeitzone

2014-04-12T23:20:50+01:00

9

Tokenvalidierung

Die Prüfung des Token muss vollständig selbst spezifiziert werden.

» Es gibt mehrere Möglichkeiten ein Token zu validieren:» Erweiterung des eigenen OAuth2-Service um eine

Validierungsschnittstelle.» Signatur des Token.

10

Validierungsservice

Der Tokenservice sollte um eine Validierungsschnittstelle erweitert werden.

» Der OAuth2-Service legt eine Tabelle an unter welcher er alle ausgestellten Token ablegt.

» Als Key wird das Accesstoken verwendet.» Ein Ressourceserver kann die Gültigkeit eines Token nun

per Server zu Server Kommunikation prüfen.» Vorteil: Schnell zu implementieren.» Nachteil: Skaliert nicht.

11

Umsetzung einer einfachen Validierungsschnittstelle.

12

Signaturservice

Die Signatur des Token bietet eine elegante Alternative.

» Der OAuth2-Service signiert das Token sowie die wichtigsten Parameter.

» Ein Ressourceserver kann die Gültigkeit eines Token nun ohne Server zu Server Kommunikation prüfen.

» Vorteil: Skaliert beliebig.» Nachteil: Das Token ist für den ausgestellten Zeitraum

gültig auch wenn der Nutzer sich bereits ausgeloggt hat.

13

Umsetzung eines Prüfverfahrens basieren auf Public Key Encryption

14

Hybride Lösung

Die Kombination beider Verfahren macht die Sache erst rund.

» Der OAuth2-Service erhält eine Schnittstelle über welche der Resourceserver prüfen kann, ob der User sich zwischenzeitlich ausgeloggt hat.

» Der Resourceserver nutzt einen Backendservice. Die Gültigkeit dieses Zugriffes wird ebenfalls mit dem Token geprüft.

» Allerdings muss der Backendservice nicht mehr nachfragen, ob der User noch eingeloggt ist.

» Das folgende Sequenzdiagramm zeigt die Aufrufreihenfolge. Zur besseren Übersicht wurden die Schritte des vorigen Diagramms stark zusammengefasst!

15

Unsere Standorte

Niederlassung Köln

Wilhelmstraße 351143 KölnTel +49 22 03 – 91 22 0Fax +49 22 03 – 91 22 23

Niederlassung Darmstadt

Kasinostraße 6064293 DarmstadtTel +49 61 51 – 78 90 0Fax +49 61 51 – 78 90 23 0

Hauptsitz Bonn

Kurfürstenallee 553177 BonnTel +49 228 – 76 36 31 0Fax +49 228 –76 36 31 3

Niederlassung Bern

Frohbergweg 73012 BernTel +41 31 – 534 07 06Fax +41 31 – 536 69 78

Consider IT done!

17

Backup

18

Erzeugen eines Token / Request

19

Erzeugen eines Token / Response mit Scope für Customer und Order und signiert mit SHA1withDSA 1024 Bit

20

Validieren eines Token (Server – Server) / Request - Response

21

Refresh eines Token mit Scopeänderung auf nur Order

22

Refresh eines Token mit Scopeänderung auf Order / Response

23

Löschen eines Tokens / Request - Response

24

Anfordern des öffentlichen Schlüssels zur Signaturprüfung / Request - Response