Mobile Client Security: Authentifizierung, Personalisierung und sichere Service-Kommunikation

Selbstverständlich müssen wir unsere mobilen Apps – bzw. die dahinter liegenden Web-APIs – absichern. Wenn wir in klassischen Systemen bisher mit "Username/Passwort" oder Windows Authentifizierung in der Anwendung gedacht haben, so müssen wir dies bei modernen Business- und mobilen Apps ändern. In dieser Session zeigen Dominick Baier und Christian Weyer architekturelle Wege und Implementierungen auf, um Authentifizierung und Autorisierung und Service Kommunikation sicher über OAuth-2.0 und OpenID Connect-basierte Ansätze abzuwickeln. Darauf aufbauend sehen Sie auch, wie mit der Idee von Tokens und Claims eine für Benutzer einfache Personalisierbarkeit Ihrer App realisiert werden kann – so schlagen Sie zwei Fliegen mit einer Klappe.

Transcript

1. Dominick Baier, Christian Weyer | Thinktecture AG Mobile Client Security Authentifizierung, Personalisierung und sichere Service-Kommunikation
2. Dominick & Christian • Dominick Baier, Chief Security Officer – dominick.baier@thinktecture.com – @leastprivilege • Christian Weyer, Managing Director – christian.weyer@thinktecture.com – @christianweyer • http://www.thinktecture.com • http://www.leastprivilege.com 2
3. Agenda • Mobile client apps • Moving to token-based authentication • Authentication & Identity with OpenID Connect (OIDC) • OIDC Implicit Flow • Authorization & Personalization 3
4. Mobile Client Apps • 'Mobile' is not just about devices – New way of working without being tied to a desktop in an office – Users expect modern business applications to work on multiple devices, at multiple locations, online and offline • Mobile spans the whole stack – From native Windows 8 applications on laptop and tablets – To modern HTML5-based desktop applications – To classic Windows clients developed with WPF – To native applications developed for iPhone, iPad, Android and Windows Phone 4
5. Simplified Overall Architecture 5 Human user Client applications Services / Data
6. Traditional Authentication & Trusted Subsystem Design Trusted Subsystem 6
7. Authentication & Trusted Subsystem Design Trusted Subsystem SAML2p & WS-Federation T 7
9. Application (Domain) Authentication Implicit Browser Authentication • Web APIs share security settings of host application – e.g. cookies, Windows/Basic authentication, client certs... Pages Web APIs $.ajax 9
10. CSRF – the Problem 10 Browser Tab/Process Tab/Process Login (e.g. Forms), get authentication cookie http://app.com e.g. POST to http://app.com/delete/5 Send authentication cookie
11. Modern Application Security • Works across any platforms & systems – Cross origin (application mash ups) – Common denominator technologies • Factoring out authentication & authorization – Separation of concerns – Decoupling of technical details – Authentication-as-a-service – Access-Control-as-a-service 11
12. Delegated Service/API Access Trust Boundary ? ? 12
13. Delegated Service/API Access Trust Boundary T T T OAuth2 WS-Trust 13
15. What is OAuth2 ? 15
16. OAuth2 Approach 16 Web APIs Authorization Server Scopes: read, write, delete, search… client_id=client1, scope=search read access token access token { "iss": "myAuthzServer", "aud": "application", "exp": 192990121, "sub": "Bob", "client_id": "client1", "scope": [ "search", "read" ] } Bob
17. OAuth2 Flows (relevant) • Resource Owner Password Credential Flow – "Trusted clients" • Request token with resource owner credentials • Access resource • Implicit Flow – Native / local clients • Request authorization & token • Access resource 17
18. Step 1a: Token Request 18 Resource Owner Client Authorization Server POST /token Authorization: Basic (client_id:secret) grant_type=password& scope=read& username=owner& password=password& Resource Server
19. Step 1b: Token Response 19 Resource Owner Client Authorization Server { "access_token" : "abc", "expires_in" : "3600", "token_type" : "Bearer", "refresh_token" : "xyz" } Resource Server
20. Step 2: Use Token 20 Resource Owner Client GET /resource Authorization: Bearer access_token Resource Server
21. What's wrong with OAuth2? 21
22. • Authentication protocol on top of OAuth2 – Defines identity tokens – Defines standard token type – Defines standard cryptography – Defines validation procedures – Defines standard scopes – Combines authentication with short/long-lived delegated API access – Defines flows for native, browser and server-based applications "OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol." 22
23. OIDC Flows • Implicit Flow – Native/browser/web applications – No explicit client authentication • Authorization Code Flow – Server-based applications – Stronger authentication – Long lived API access • Hybrid Flow – "in-between" 23
24. OpenID Connect Implicit Flow for Client-side Applications GET /authorize ?client_id=app1 &scope=openid email &redirect_uri=https://app1/cb &response_type=id_token 24
25. Excursion: Scopes Scope Claims profile name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at email email, email_verified address address phone phone_number, phone_number_verified offline_access requests refresh token 25
26. Authentication 26
27. Consent 27
28. Response GET /cb #id_token=x12f…zsz 28
29. Excursion: Identity Token { "typ": "JWT", "alg": "HS256" } { "iss": "https://idsrv3", "exp": 1340819380, "aud": "app1", "sub": "182jmm199", "email": "alice@alice.com", "email_verified": true, "amr": "password", "auth_time": 12340819300 } Header Claims eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMD.4MTkzODAsDQogImh0dHA6Ly9leGFt Header Claims Signature 29
30. Combining Authentication with API Access GET /authorize ?client_id=app1 &scope=openid email api1 api2 &redirect_uri=oob://app1/cb &response_type=id_token token 30
31. Response GET /cb #id_token=x12f…zsz &token=32x…133 &expires_in=3600 &token_type=bearer 31
32. Accessing the API Authorization: Bearer <token> 32
33. Client-side Token Management • Client requests token • Persisting the token data locally • Life time management – Tokens have finite lifetime • Client application needs to explicitly renew token 33
34. Personalization • Need for “authorization” in the UI layer – Which user can see or do what in the client application? – Authorization always has to happen on the server, anyway • Technical concept of authorization morphs into user-oriented concept of personalization – Features – Capabilities – Constraints 34
35. Personalization Illustrated – „bob“ 35
36. Personalization Illustrated – „cw“ 36
37. Implementing personalization with Web API • Model personalization data and populate from server-side repository – based on incoming token 37 public class PersonalizationController : ApiController { public PersonalizationData GetPersonalizationData() { var user = …; var persData = new PersonalizationData { Features = GetFeatures(user), UiClaims = new UiClaimsData { UserName = user, Capabilities = GetCapabilities(user), Constraints = GetConstraints(user), NameValueClaims = GetNameValueClaims(user) } }; return persData; } var user = RequestContext.Principal as ClaimsPrincipal; var userName = user.FindFirst("sub").Value;
38. Implementing personalization with AngularJS • Get personalization data upon successful authentication • Implement AngularJS service to inject personalization data into controllers • Data-bind to e.g. capabilities on $scope • Fully-fledged solution includes custom directives 38 $http({ method: "GET", url: ttTools.baseUrl + "api/personalization" }) .success(function (data) { tt.personalization.data = data; // populate routes/UI states from features… $rootScope.$broadcast(tt.personalization.constants.dataLoaded); }); app.factory("personalizationService", function () { return tt.personalization; });
39. Summary • OpenID Connect is the future – OAuth is not enough • Replaces – SAML2p & WS-Federation – Home-grown OAuth2 authentication extensions • Combines authentication & API access (authorization) • Access token can be used to provide personalization data – Dynamically deliver application parts – Customize UI 39
40. Resources • dominick.baier@thinktecture.com • christian.weyer@thinktecture.com • http://www.thinktecture.com • Thinktecture IdentityServer – https://github.com/identityserver/Thinktecture.identityServer3 • Thinktecture’s GitHub Repositories – https://github.com/thinktecture • Christian Weyer’s GitHub Repositories – https://github.com/ChristianWeyer 40
41. Resources • OpenID Libraries, Products, and Tools – http://openid.net/developers/libraries/ • Open Source Identity System Particicpants – http://osis.idcommons.net/wiki/ Category:OC5_Participant 41