24
Absichern einer REST-API mittel OAuth2 OLIVER WRONKA 02. APRIL 2014 Secure REST by OAuth2

Secure REST by OAuth2

Embed Size (px)

DESCRIPTION

In dieser Präsentation geht Oliver Wronka, Principal Architect/ Project Manager bei axxessio, näher auf das Thema „Secure REST by OAuth2“ ein.

Citation preview

Page 1: Secure REST by OAuth2

Absichern einer REST-API mittel OAuth2

OLIVER WRONKA

02. APRIL 2014

Secure REST by OAuth2

Page 2: 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

Page 3: Secure REST by OAuth2

3

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

Page 4: Secure REST by OAuth2

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.

Page 5: Secure REST by OAuth2

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.

Page 6: Secure REST by OAuth2

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&…

Page 7: Secure REST by OAuth2

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"}

Page 8: Secure REST by OAuth2

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

Page 9: Secure REST by OAuth2

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.

Page 10: Secure REST by OAuth2

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.

Page 11: Secure REST by OAuth2

11

Umsetzung einer einfachen Validierungsschnittstelle.

Page 12: Secure REST by OAuth2

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.

Page 13: Secure REST by OAuth2

13

Umsetzung eines Prüfverfahrens basieren auf Public Key Encryption

Page 14: Secure REST by OAuth2

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!

Page 15: Secure REST by OAuth2

15

Page 16: Secure REST by OAuth2

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!

Page 17: Secure REST by OAuth2

17

Backup

Page 18: Secure REST by OAuth2

18

Erzeugen eines Token / Request

Page 19: Secure REST by OAuth2

19

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

Page 20: Secure REST by OAuth2

20

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

Page 21: Secure REST by OAuth2

21

Refresh eines Token mit Scopeänderung auf nur Order

Page 22: Secure REST by OAuth2

22

Refresh eines Token mit Scopeänderung auf Order / Response

Page 23: Secure REST by OAuth2

23

Löschen eines Tokens / Request - Response

Page 24: Secure REST by OAuth2

24

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