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