Your SlideShare is downloading. ×
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Secure REST by OAuth2
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Secure REST by OAuth2

912

Published on

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

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

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
912
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
14
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Absichern einer REST-API mittel OAuth2 OLIVER WRONKA 31. MÄRZ 2014 Secure REST by OAuth2
  • 2. Absichern einer Server zu Server Kommunikation 2 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. 3 Die Laufzeitsicht des Authorization Code (or Web Server) Flow ist recht komplex.
  • 4. In der OAuth2-Spezifikation sind einige Punkte nicht spezifiziert: 4 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 5 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. 6 Die Laufzeitsicht Resource Owner Password Credential Flow ist sehr einfach. Parameter Beschreibung grant_type: Pflichtfeld, muss mit „password“ vorbelegt sein. username: Pflichtfeld password: Pflichtfeld, aber hier wird nur der Hash (z. B. sha1) des Benutzer- passworts übergeben scope: Optional, eine Liste von angeforderten Rechten auf Ressourcen, z. B. …&scope=CUSTOMER%20ORDER&…
  • 7. Beispiel für eine Antwort 7 Parameter Beschreibung access_token: Pflichtfeld, das eigentliche Token. OAuth2 macht keine Angaben zum Aufbau oder Inhalt. created_at: Timestamp der Ausstellung expires_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 Signature-Algorithm: DSASHA1 Signature-Encoding: base64 Signature-Value: 302c021444bd9861ef54f17e713758d 423d66085c6eb3d0702141bfb0e5cf84fae4c8e30a99cd74 c8bb037d11526 Transfer-Encoding: chunked { "access_token": "d4f7a44b7...", "created_at": 1395155558001, "expires_in": 3600, "refresh_token": "e908766e81372737...", "scope": [ [ "CUSTOMER", "CRUD" ], [ "ORDER", "CRUD" ] ], "token_type": "bearer" }
  • 8. Gültigkeit eines Token 8 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ültigkeit 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 9 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 10 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 Resourceserver kann die Gültigkeit eines Token nun per Server zu Server Kommunikation prüfen. » Vorteil: Schnell zu implementieren. » Nachteil: Skaliert nicht.
  • 11. 11 Umsetzung einer einfachen Validierungsschnittstelle.
  • 12. Signaturservice 12 Die Signatur des Token bietet eine elegante Alternative. » Der OAuth2-Service signiert das Token sowie die wichtigsten Parameter. » Ein Resourceserver 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. 13 Umsetzung eines Prüfverfahrens basieren auf Public Key Encryption
  • 14. Hybride Lösung 14 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. 15
  • 16. Zugriff auf Resourceserver 16 Für den Zugriff auf den Resourceserver wird das Token im Header untergebracht. » Das Token wird base64 kodiert. » Im Header des http-Requests auf den Resourceserver werden neben der Signatur zwei weitere Felder untergebracht: » Token-Encoding: „base64“ » Token-Value: „asdfiojnsviohadiovsdif235nsdif90is…“
  • 17. Unsere Standorte Niederlassung Köln Wilhelmstraße 3 51143 Köln Tel +49 22 03 – 91 22 0 Fax +49 22 03 – 91 22 23 Niederlassung Darmstadt Kasinostraße 60 64293 Darmstadt Tel +49 61 51 – 78 90 0 Fax +49 61 51 – 78 90 23 0 Hauptsitz Bonn Kurfürstenallee 5 53177 Bonn Tel +49 228 – 76 36 31 0 Fax +49 228 –76 36 31 3 Niederlassung Bern Frohbergweg 7 3012 Bern Tel +41 31 – 534 07 06 Fax +41 31 – 536 69 78 Consider IT done!
  • 18. Backup
  • 19. 19 Erzeugen eines Token / Request
  • 20. 20 Erzeugen eines Token / Response mit Scope für Customer und Order und signiert mit SHA1withDSA 1024 Bit
  • 21. 21 Validieren eines Token (Server – Server) / Request - Response
  • 22. 22 Refresh eines Token mit Scopeänderung auf nur Order
  • 23. 23 Refresh eines Token mit Scopeänderung auf Order / Response
  • 24. 24 Löschen eines Tokens / Request - Response
  • 25. 25 Anfordern des öffentlichen Schlüssels zur Signaturprüfung / Request - Response

×