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

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

75681814fbbb90c9224ea5ed0f8324ee?s=128

Dominick Baier

June 13, 2013
Tweet

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