Upload
axxessio-gmbh
View
760
Download
0
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
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