Secure REST by OAuth2

50 %
50 %
Information about Secure REST by OAuth2
Technology

Published on April 2, 2014

Author: axxessio

Source: slideshare.net

Description

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

Absichern einer REST-API mittel OAuth2 OLIVER WRONKA 31. MÄRZ 2014 Secure REST by OAuth2

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 Die Laufzeitsicht des Authorization Code (or Web Server) Flow ist recht komplex.

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.

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

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

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ü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

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.

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 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.

Signaturservice 12 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

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

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!

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

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

WCF REST SECURITY USING OAUTH 2.0 - social.msdn.microsoft.com

Hi jthirumurugan, >> How to secure those WCF REST services using OAuth 2.0 or is there any other approach to secure WCF REST based Services? It ...
Read more

Security scenarios · DotNetOpenAuth/DotNetOpenAuth Wiki ...

Security scenarios with ASP.NET MVC, ASP.NET Web API, OAuth2 and DotNetOpenAuth About the Author: This article has been contributed by Manfred Steyer.
Read more

Securing RESTful Web Services with OAuth2 | Pivotal P.O.V.

Securing RESTful Web Services with OAuth2. ... The remainder of this article is about securing REST services in ... Why would you use OAuth2 to secure a ...
Read more

OAuth 2.0 — OAuth

OAuth 2.0 is the next evolution of the OAuth protocol which was originally created in late 2006. ... with management REST API) PHP OAuth2.0 for Silex and Demo;
Read more

authentication - Secure REST API and Single Page App by ...

The aim is to secure access to the REST API ... Secure REST API and Single Page App by using external OAuth 2 Authorization Code. ... OAuth2 is not meant ...
Read more

Secure Your REST API… The Right Way - Stormpath User ...

The Stormpath playbook on REST API Security. Dive into authentication protocols, benefits of API keys, avoiding sessions and more.
Read more

Authorizing with Google for REST APIs - Google Developers

Authorizing with Google for REST ... the GoogleAuthUtil class and related APIs provide your users a secure and ... String SCOPE = "oauth2: ...
Read more

Secure WCF RESTful service using OAUTH - CodeProject

Secure WCF RESTful service using OAUTH. ... but i required with token & token secret kindly share me code for both OAuth2 ... I am finding how to secure ...
Read more