OAuth2 - The good, the bad & the ugly (NDC Oslo 2013)

Slide 1

Slide 1 text

Dominick Baier h.p://leastprivilege.com @leastprivilege OAuth2 – The good, the bad & the ugly

Slide 2

Slide 2 text

2 @leastprivilege Dominick Baier •  Security consultant at thinktecture •  Focus on –  security in distributed applica9ons –  iden9ty management –  access control –  Windows/.NET security –  cloud compu9ng •  MicrosoG MVP for Developer Security •  [email protected] •  h.p://leastprivilege.com think mobile!

Slide 3

Slide 3 text

3 @leastprivilege Agenda •  Overview & use cases •  Concerns & controversies

Slide 4

Slide 4 text

4 @leastprivilege What is OAuth2 ?

Slide 5

Slide 5 text

5 @leastprivilege History •  OAuth started circa 2007 •  2008 -‐ IETF normalizaTon started in 2008 •  2010 -‐ RFC 5849 deﬁnes OAuth 1.0 •  2010 -‐ WRAP (Web Resource AuthorizaTon Proﬁles) proposed by MicrosoG, Yahoo! And Google •  2010 -‐ OAuth 2.0 work begins in IETF •  Working deployments of various draGs & versions at Google, MicrosoG, Facebook, Github, Twi.er, Flickr, Dropbox… •  Mid 2012 – Lead author and editor resigned & withdraws his name from all specs •  October 2012 – RFC 6749, RFC 6750

Slide 6

Slide 6 text

6 @leastprivilege High level overview Human SoGware Service/Data

Slide 7

Slide 7 text

7 @leastprivilege h.p://hueniverse.com/2007/09/explaining-‐oauth/ h.p://amzn.com/1449311601

Slide 8

Slide 8 text

8 @leastprivilege

Slide 9

Slide 9 text

9 @leastprivilege

Slide 10

Slide 10 text

10 @leastprivilege

Slide 11

Slide 11 text

11 @leastprivilege High level overview Resource Owner Client Resource Server

Slide 12

Slide 12 text

12 @leastprivilege Resource Owner Resource Server AuthorizaTon Server Client issues access token Conﬁden9al/Public Trusted/Untrusted OAuth2: The Players "owns" a resource uses trusts is registered with accesses

Slide 13

Slide 13 text

13 @leastprivilege OAuth2 Flows -‐ with User Interac9on •  AuthorizaTon Code Flow –  Web applica9on clients 1.  Request authoriza9on 2.  Request token 3.  Access resource •  Implicit Flow –  Na9ve / local clients 1.  Request authoriza9on & token 2.  Access resource

Slide 14

Slide 14 text

14 @leastprivilege OAuth2 Flows -‐ no User Interac9on •  Resource Owner Password CredenTal Flow –  "Trusted clients" 1.  Request token with resource owner creden9als 2.  Access resource •  Client CredenTal Flow –  Client to Service communica9on 1.  Request token with client creden9als 2.  Access resource

Slide 15

Slide 15 text

15 @leastprivilege Authoriza9on Code Flow (Web Applica9on Clients) Web Applica9on (Client) Resource Server Resource Owner

Slide 16

Slide 16 text

16 @leastprivilege Step 1a: Authoriza9on Request Web Applica9on (Client) Authoriza9on Server Resource Owner GET /authorize? client_id=webapp& scope=resource& redirect_uri=https://webapp/cb& response_type=code& state=123

Slide 17

Slide 17 text

17 @leastprivilege Step 1b: Authen9ca9on

Slide 18

Slide 18 text

18 @leastprivilege Step 1c: Consent

Slide 19

Slide 19 text

19 @leastprivilege Twi_er Consent

Slide 20

Slide 20 text

20 @leastprivilege Evernote Consent

Slide 21

Slide 21 text

21 @leastprivilege The Consent Screen is important! h.p://zachholman.com/2011/01/oauth_will_murder_your_children/

Slide 22

Slide 22 text

22 @leastprivilege Step 1d: Authoriza9on Response Web Applica9on (Client) Authoriza9on Server Resource Owner GET /cb? code=xyz& state=123

Slide 23

Slide 23 text

23 @leastprivilege Step 2a: Token Request Web Applica9on (Client) Authoriza9on Server Resource Owner POST /token Authorization: Basic (client_id:secret) grant_type=authorization_code& authorization_code=xyz

Slide 24

Slide 24 text

24 @leastprivilege Step 2b: Token Response Web Applica9on (Client) Authoriza9on Server Resource Owner { "access_token" : "abc", "expires_in" : "3600", "token_type" : "Bearer", "refresh_token" : "xyz" }

Slide 25

Slide 25 text

25 @leastprivilege Step 3: Resource Access Web Applica9on (Client) Resource Owner GET /resource Authorization: Bearer access_token Resource Server

Slide 26

Slide 26 text

26 @leastprivilege JSON Web Token (JWT) { "typ": "JWT", "alg": "HS256" } { "iss": "http://myIssuer", "exp": "1340819380", "aud": "http://myResource", "sub": "alice", "client": "xyz", "scope": ["read", "search"] } Header Claims eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMD.4MTkzODAsDQogImh0dHA6Ly9leGFt Header Claims Signature

Slide 27

Slide 27 text

27 @leastprivilege (Step 4: Refreshing the Token) Web Applica9on (Client) Resource Owner POST /token Authorization: Basic (client_id:secret) grant_type=refresh_token& refresh_token=xyz Authoriza9on Server

Slide 28

Slide 28 text

28 @leastprivilege Refresh Token Management (Flickr)

Slide 29

Slide 29 text

29 @leastprivilege Refresh Token Management (Dropbox)

Slide 30

Slide 30 text

30 @leastprivilege Refresh Token Management (Microsoe Live)

Slide 31

Slide 31 text

31 @leastprivilege Summary – Code Flow •  Designed for server-‐based applicaTons –  Client can store secret securely on the server •  Accountability is provided –  access token never leaked to the browser •  Long-‐lived access can be implemented

Slide 32

Slide 32 text

32 @leastprivilege Implicit Flow (Na9ve / Local Clients) Resource Owner Client

Slide 33

Slide 33 text

33 @leastprivilege Step 1a: Authoriza9on Request Resource Server Resource Owner Client GET /authorize? client_id=nativeapp& scope=resource& redirect_uri=http://localhost/cb& response_type=token& state=123 Authoriza9on Server

Slide 34

Slide 34 text

34 @leastprivilege Step 1b: Token Response Resource Owner Client GET /cb# access_token=abc& expires_in=3600& state=123 Authoriza9on Server Resource Server

Slide 35

Slide 35 text

35 @leastprivilege Step 2: Resource Access Resource Owner Client GET /resource Authorization: Bearer access_token Resource Server

Slide 36

Slide 36 text

36 @leastprivilege Summary – Implicit Flow •  Simpliﬁed handshake –  no authoriza9on code •  Token is exposed to browser / local OS •  No client authenTcaTon –  no refresh tokens –  some9mes cookies and web views used instead •  Heavily debated and many "non-‐standard" variaTons

Slide 37

Slide 37 text

37 @leastprivilege Resource Owner Password Creden9al Flow (Trusted Applica9on) Resource Owner Client Resource Server

Slide 38

Slide 38 text

38 @leastprivilege Step 1a: Token Request Resource Owner Client Authoriza9on Server POST /token Authorization: Basic (client_id:secret) grant_type=password& scope=resource& user_name=owner& password=password& Resource Server

Slide 39

Slide 39 text

39 @leastprivilege Step 1b: Token Response Resource Owner Client Authoriza9on Server { "access_token" : "abc", "expires_in" : "3600", "token_type" : "Bearer", "refresh_token" : "xyz" } Resource Server

Slide 40

Slide 40 text

40 @leastprivilege Step 2: Resource Access Resource Owner Client GET /resource Authorization: Bearer access_token Resource Server

Slide 41

Slide 41 text

41 @leastprivilege Summary – Resource Owner Creden9al Flow •  Resource owner credenTals are exposed to client –  users should not become accustomed to that •  STll be.er to store access/refresh token on device than password –  if the developer is using that feature •  Typically client and back end built by same party

Slide 42

Slide 42 text

42 @leastprivilege Client Creden9als Flow – No human involved at all Client Authoriza9on Server POST /token Authorization: Basic (client_id:secret) grant_type=client_credentials& scope=resource

Slide 43

Slide 43 text

43 @leastprivilege OAuth2 Applica9on Architecture ApplicaTon AuthorizaTon Server Scopes: read, write, delete, search… client_id=client1, scope=search read access token access token { "iss": "myAuthzServer", "aud": "applicaTon", "exp": 192990121, "sub": "Bob", "client_id": "client1", "scope": [ "search", "read" ] } Bob

Slide 44

Slide 44 text

44 @leastprivilege Concerns & Controversies artwork by @ChrisMCarrasco

Slide 45

Slide 45 text

45 @leastprivilege Eran Hammer •  h.p://hueniverse.com/2010/09/oauth-‐bearer-‐tokens-‐are-‐a-‐terrible-‐ idea/ •  h.p://hueniverse.com/2010/09/oauth-‐2-‐0-‐without-‐signatures-‐is-‐bad-‐ for-‐the-‐web/ •  h.p://hueniverse.com/2012/07/oauth-‐2-‐0-‐and-‐the-‐road-‐to-‐hell/ •  OAuth2: Looking back and moving on –  h_ps://vimeo.com/52882780

Slide 46

Slide 46 text

46 @leastprivilege

Slide 47

Slide 47 text

47 @leastprivilege "A Framework to build Protocols"

Slide 48

Slide 48 text

48 @leastprivilege JSON Web Token (JWT) JSON Web Encryp9on (JWE) JSON Web Signatures (JWS) JSON Web Algorithms (JWA) OAuth2 Resource Set Registra9on Dynamic Client Registra9on User-‐Managed Access Chaining and Redelega9on Metadata & Introspec9on h_p://openid.net/specs/openid-‐connect basic-‐1_0-‐23.html implicit-‐1_0-‐06.html messages-‐1_0-‐15.html standard-‐1_0-‐16.html discovery-‐1_0-‐12.html registra9on-‐1_0-‐14.html session-‐1_0-‐11.html Asser9on Framework for OAuth2 JWT Bearer Token Proﬁles SAML 2.0 Bearer Token Proﬁles Token Revoca9on MAC Tokens The OAuth2 AuthorizaTon Framework (RFC 6749) OAuth2 Bearer Token Usage (RFC 6750) Core (proposed standards) Threat Model and Security ConsideraTons (RFC 6819) Informa9onal h_p://datatracker.iel.org/wg/oauth/

Slide 49

Slide 49 text

49 @leastprivilege Bearer Token! !A security token with the property that any party !in possession of the token (a "bearer") can use the !token in any way that any other party in possession !of it can. Using a bearer token does not !require a bearer to prove possession of !cryptographic key material (proof-of-possession).!

Slide 50

Slide 50 text

50 @leastprivilege Developers & SSL

Slide 51

Slide 51 text

51 @leastprivilege Infrastructure & SSL h_p://gigaom.com/2013/01/10/nokia-‐yes-‐we-‐decrypt-‐your-‐h_ps-‐data-‐but-‐dont-‐worry-‐about-‐it/

Slide 52

Slide 52 text

52 @leastprivilege Security Theater h_ps://wellsoﬃce.wellsfargo.com/ceoportal/signon/loader.jsp

Slide 53

Slide 53 text

53 @leastprivilege

Slide 54

Slide 54 text

54 @leastprivilege A_ack Surface GET /authorize? client_id=nativeapp& redirect_uri=http://localhost/cb& scope=resource& response_type=token& state=123 h.p://leastprivilege.com/2013/03/15/common-‐oauth2-‐vulnerabiliTes-‐and-‐miTgaTon-‐techniques/ h.p://leastprivilege.com/2013/03/15/oauth2-‐security/ h.p://homakov.blogspot.de/2012/08/saferweb-‐oauth2a-‐or-‐lets-‐just-‐ﬁx-‐it.html

Slide 55

Slide 55 text

55 @leastprivilege Some Facebook Hacks •  h.p://www.darkreading.com/blog/240148995/ the-‐road-‐to-‐hell-‐is-‐authenTcated-‐by-‐facebook.html •  h.p://homakov.blogspot.no/2013/02/hacking-‐ facebook-‐with-‐oauth2-‐and-‐chrome.html •  h.p://www.nirgoldshlager.com/2013/03/ how-‐i-‐hacked-‐any-‐facebook-‐accountagain.html

Slide 56

Slide 56 text

56 @leastprivilege OAuth2 & Authen9ca9on •  OAuth2 is for (delegated) authorizaTon –  authen9ca9on is a pre-‐requisite for that •  What most developers really want is: –  let's use OAuth2 for authen9ca9on •  "Sign-‐in with social provider X" •  à especially mobile apps h.p://www.thread-‐safe.com/2012/01/problem-‐with-‐oauth-‐for-‐authenTcaTon.html h.p://www.cloudidenTty.com/blog/2013/01/02/oauth-‐2-‐0-‐and-‐sign-‐in-‐4/

Slide 57

Slide 57 text

57 @leastprivilege OAuth2 for Authen9ca9on: Request UserInfo RS Resource Owner Client GET /authorize? client_id=nativeapp& redirect_uri=http://localhost/cb& scope=signin& response_type=token& state=123 Authoriza9on Server

Slide 58

Slide 58 text

58 @leastprivilege OAuth2 for Authen9ca9on: Response UserInfo Resource Owner Client GET /cb? access_token=abc& userid=123& expires_in=3600& state=123 Authoriza9on Server

Slide 59

Slide 59 text

59 @leastprivilege OAuth2 for Authen9ca9on: Accessing User Data UserInfo RS Resource Owner Client GET /userinfo Authorization: Bearer access_token Firstname, Lastname, Email…

Slide 60

Slide 60 text

60 @leastprivilege A Solu9on?

Slide 61

Slide 61 text

61 @leastprivilege Another Problem 1.  User logs into malicious app (app steals token) userid, access token 2. Malicious developer uses stolen access token in legiTmate app access token Impersonated!

Slide 62

Slide 62 text

62 @leastprivilege

Slide 63

Slide 63 text

63 @leastprivilege Conclusion •  The OAuth2 "approach" is useful for many typical applicaTons scenarios •  Spec needs some reﬁnement –  "basic proﬁle" –  MAC tokens •  Current implementaTons are lacking –  even by the big guys –  let alone the myriad of DIY implementa9ons •  Very good & balanced view –  h_ps://www.tbray.org/ongoing/When/201x/2013/01/23/OAuth