Download - Secure REST by OAuth2
![Page 1: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/1.jpg)
Absichern einer REST-API mittel OAuth2
OLIVER WRONKA
02. APRIL 2014
Secure REST by OAuth2
![Page 2: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/2.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/3.jpg)
3
Die Laufzeitsicht des Authorization Code (or Web Server) Flow ist recht komplex.
![Page 4: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/4.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/5.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/6.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/7.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/8.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/9.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/10.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/11.jpg)
11
Umsetzung einer einfachen Validierungsschnittstelle.
![Page 12: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/12.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/13.jpg)
13
Umsetzung eines Prüfverfahrens basieren auf Public Key Encryption
![Page 14: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/14.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/15.jpg)
15
![Page 16: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/16.jpg)
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](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/17.jpg)
17
Backup
![Page 18: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/18.jpg)
18
Erzeugen eines Token / Request
![Page 19: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/19.jpg)
19
Erzeugen eines Token / Response mit Scope für Customer und Order und signiert mit SHA1withDSA 1024 Bit
![Page 20: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/20.jpg)
20
Validieren eines Token (Server – Server) / Request - Response
![Page 21: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/21.jpg)
21
Refresh eines Token mit Scopeänderung auf nur Order
![Page 22: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/22.jpg)
22
Refresh eines Token mit Scopeänderung auf Order / Response
![Page 23: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/23.jpg)
23
Löschen eines Tokens / Request - Response
![Page 24: Secure REST by OAuth2](https://reader033.vdocuments.pub/reader033/viewer/2022042521/54bc17504a7959336b8b4753/html5/thumbnails/24.jpg)
24
Anfordern des öffentlichen Schlüssels zur Signaturprüfung / Request - Response