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

Transcript

1. Dominick  Baier   h.p://leastprivilege.com   @leastprivilege   OAuth2  –   The  good,  the  bad  &  the  ugly  
2. 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   •  dominick.baier@thinktecture.com   •  h.p://leastprivilege.com   think mobile!
3. 3   @leastprivilege   Agenda   •  Overview  &  use  cases   •  Concerns  &  controversies  
4. 4   @leastprivilege   What  is  OAuth2  ?  
5. 5   @leastprivilege   History   •  OAuth  started  circa  2007     •  2008  -­‐  IETF  normalizaTon  started  in  2008     •  2010  -­‐  RFC  5849  defines  OAuth  1.0     •  2010  -­‐  WRAP  (Web  Resource  AuthorizaTon  Profiles)  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  
6. 6   @leastprivilege   High  level  overview   Human   SoGware   Service/Data  
7. 7   @leastprivilege   h.p://hueniverse.com/2007/09/explaining-­‐oauth/   h.p://amzn.com/1449311601  
8. 8   @leastprivilege  
9. 9   @leastprivilege  
10. 10   @leastprivilege  
11. 11   @leastprivilege   High  level  overview   Resource  Owner   Client   Resource  Server  
12. 12   @leastprivilege   Resource  Owner   Resource  Server   AuthorizaTon  Server   Client   issues  access  token   Confiden9al/Public   Trusted/Untrusted   OAuth2:  The  Players   "owns"  a  resource   uses   trusts   is  registered  with   accesses  
13. 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  
14. 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  
15. 15   @leastprivilege   Authoriza9on  Code  Flow     (Web  Applica9on  Clients)   Web  Applica9on   (Client)   Resource  Server   Resource  Owner  
16. 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  
17. 17   @leastprivilege   Step  1b:  Authen9ca9on  
18. 18   @leastprivilege   Step  1c:  Consent  
19. 19   @leastprivilege   Twi_er  Consent  
20. 20   @leastprivilege   Evernote  Consent  
21. 21   @leastprivilege   The  Consent  Screen  is  important!   h.p://zachholman.com/2011/01/oauth_will_murder_your_children/  
22. 22   @leastprivilege   Step  1d:  Authoriza9on  Response   Web  Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   GET  /cb?      code=xyz&      state=123  
23. 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  
24. 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"       }  
25. 25   @leastprivilege   Step  3:  Resource  Access   Web  Applica9on   (Client)   Resource  Owner   GET  /resource      Authorization:  Bearer  access_token   Resource  Server  
26. 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  
27. 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  
28. 28   @leastprivilege   Refresh  Token  Management  (Flickr)  
29. 29   @leastprivilege   Refresh  Token  Management   (Dropbox)  
30. 30   @leastprivilege   Refresh  Token  Management   (Microsoe  Live)  
31. 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  
32. 32   @leastprivilege   Implicit  Flow  (Na9ve  /  Local  Clients)   Resource  Owner   Client  
33. 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  
34. 34   @leastprivilege   Step  1b:  Token  Response   Resource  Owner   Client   GET  /cb#      access_token=abc&      expires_in=3600&      state=123   Authoriza9on  Server   Resource  Server  
35. 35   @leastprivilege   Step  2:  Resource  Access   Resource  Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  
36. 36   @leastprivilege   Summary  –  Implicit  Flow   •  Simplified  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  
37. 37   @leastprivilege   Resource  Owner  Password  Creden9al   Flow  (Trusted  Applica9on)   Resource  Owner   Client   Resource  Server  
38. 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  
39. 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  
40. 40   @leastprivilege   Step  2:  Resource  Access   Resource  Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  
41. 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  
42. 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  
43. 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  
44. 44   @leastprivilege   Concerns  &  Controversies   artwork  by  @ChrisMCarrasco  
45. 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  
46. 46   @leastprivilege  
47. 47   @leastprivilege   "A  Framework  to  build  Protocols"  
48. 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  Profiles   SAML  2.0  Bearer  Token  Profiles   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/  
49. 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).!
50. 50   @leastprivilege   Developers  &  SSL  
51. 51   @leastprivilege   Infrastructure  &  SSL   h_p://gigaom.com/2013/01/10/nokia-­‐yes-­‐we-­‐decrypt-­‐your-­‐h_ps-­‐data-­‐but-­‐dont-­‐worry-­‐about-­‐it/  
52. 52   @leastprivilege   Security  Theater   h_ps://wellsoffice.wellsfargo.com/ceoportal/signon/loader.jsp  
53. 53   @leastprivilege  
54. 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-­‐fix-­‐it.html  
55. 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  
56. 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/    
57. 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  
58. 58   @leastprivilege   OAuth2  for  Authen9ca9on:  Response   UserInfo   Resource  Owner   Client   GET  /cb?      access_token=abc&      userid=123&      expires_in=3600&      state=123   Authoriza9on  Server  
59. 59   @leastprivilege   OAuth2  for  Authen9ca9on:     Accessing  User  Data   UserInfo  RS   Resource  Owner   Client   GET  /userinfo      Authorization:          Bearer  access_token   Firstname,  Lastname,  Email…  
60. 60   @leastprivilege   A  Solu9on?  
61. 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!
62. 62   @leastprivilege  
63. 63   @leastprivilege   Conclusion   •  The  OAuth2  "approach"  is  useful  for  many  typical   applicaTons  scenarios   •  Spec  needs  some  refinement   –  "basic  profile"   –  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