Web API Authorization & Access Control - done right (Warm Crocodile Developer Conference 2014)

Transcript

1. Web  API  Authoriza0on  &     Access  Control     done  right   Dominick  Baier   h;p://leastprivilege.com   @leastprivilege   think mobile!
2. 2   @leastprivilege   Dominick  Baier   •  Security  consultant  at  thinktecture   •  Focus  on   –  security  in  distributed  applica9ons   –  iden9ty  management   –  access  control   –  Windows/.NET  security   –  mobile  app  security     •  MicrosoG  MVP  for  Developer  Security   •  ASP.NET  Web  API  Advisor   •  dominick.baier@thinktecture.com   •  h;p://leastprivilege.com   think mobile!
3. Enterprise  Security   SOAP WS* XML SAML Kerberos/LDAP
4. No SOAP No SAML No WS* No Windows HTTP JSON
5. 5   @leastprivilege   Modern  applica9ons   Users   Clients   Web  APIs  
6. 6   @leastprivilege   "simple"  Requirements   -­‐  Which  app  do  I  want  to  use  today?   -­‐  Do  I  trust  this  app?   -­‐  Who  is  the  user?   -­‐  How  can  I  securely  communicate      with  the  back-­‐end   -­‐  Who  is  the  user?   -­‐  Who  is  the  client?   -­‐  What  are  they  allowed  to  do?  
7. 7   @leastprivilege   …s9ll  can  become  complex   *  
8. 8   @leastprivilege   OAuth2  
9. 9   @leastprivilege   History   •  OAuth  started  circa  2007     •  2008  -­‐  IETF  normaliza0on  started  in  2008     •  2010  -­‐  RFC  5849  defines  OAuth  1.0     •  2010  -­‐  WRAP  (Web  Resource  Authoriza0on  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   •  January  2014  –  OpenID  Connect  (built  on  top  of  OAuth2)  
10. 10   @leastprivilege   OAuth2  approach   Web  APIs   Authoriza0on  Server   Scopes:  read,  write,     delete,  search…   client_id=client1,   scope=search  read   access  token   access  token   {        "iss":  "myAuthzServer",        "aud":  "applica0on",        "exp":  192990121,        "sub":  "Bob",        "client_id":  "client1",        "scope":  [  "search",  "read"  ]   }   Bob  
11. 11   @leastprivilege   Flows   •  Pa;erns  for  orchestra0ng  communica0on  between   client  and  authoriza0on  server   –  server-­‐rendered  web  applica9ons   –  user-­‐agent  based  web  applica9ons   –  na9ve  applica9ons   –  machine-­‐to-­‐machine  communica9on   –  federa9on   •  Ability  to  treat  the  client  as  par0ally  trusted   –  as  well  as  client  authen9ca9on  
12. 12   @leastprivilege   Resource  Owner   Resource  Server   Authoriza0on  Server   Client   issues  access  token   Confiden9al/Public   Trusted/Untrusted   OAuth2:  The  Players   "owns"  a  resource   uses   trusts   is  registered  with   accesses  
13. 13   @leastprivilege   h;ps://github.com/thinktecture/Thinktecture.Authoriza0onServer   AuthorizationServer
14. 14   @leastprivilege   Star9ng  simple…   •  Trusted  clients   –  Resource  Owner  Password  Creden9al  Flow   •  Machine-­‐to-­‐machine  communica0on   –  Client  Creden9als  Flow  
15. 15   @leastprivilege   Step  1a:  Token  Request   Resource  Owner   Client   Authoriza9on  Server   POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=password&   scope=read&   user_name=owner&   password=password&   Resource  Server  
16. 16   @leastprivilege   Step  1b:  Token  Response   Resource  Owner   Client   Authoriza9on  Server   {      "access_token"  :  "abc",      "expires_in"  :  "3600",      "token_type"  :  "Bearer",      "refresh_token"  :  "xyz"       }   Resource  Server  
17. 17   @leastprivilege   Step  2:  Use  token   Resource  Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  
18. 18   @leastprivilege   JSON  Web  Token  (JWT)   {      "typ":  "JWT",      "alg":  "HS256"   }   {      "iss":  "http://myIssuer",      "exp":  "1340819380",      "aud":  "http://myResource",      "sub":  "alice",        "client_id":  "xyz",      "scope":  ["read",  "search"]   }   Header   Claims   eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMD.4MTkzODAsDQogImh0dHA6Ly9leGFt   Header   Claims   Signature  
19. 19   @leastprivilege   (Step  3:  Refreshing  the  Token)   Client   POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=refresh_token&   refresh_token=xyz   Authoriza9on  Server  
20. 20   @leastprivilege   Refresh  Token  Management  (Flickr)  
21. 21   @leastprivilege   Refresh  Token  Management   (Dropbox)  
22. 22   @leastprivilege   Refresh  Token  Management   (Microsoe  Live)  
23. 23   @leastprivilege   Summary   •  Allows  exchanging  a  password  with  a  token   –  short  lived  or  long  lived   •  Be;er  than  dealing  with  passwords  directly   –  e.g.  storing  the  password   –  client  s9ll  can  "see"  the  password   –  maybe  not  what  you  want   •  Client  creden0als  flow   –  similar  but  no  user  creden9als   –  client  acts  on  behalf  of  itself  (not  the  user)  
24. 24   @leastprivilege   Separa9ng  user  creden9als     from  the  client…   •  Local  /  mobile  /  user-­‐agent  based  clients   –  Implicit  Flow   •  Server-­‐based  /  confiden0al  clients   –  Autoriza9on  Code  Flow  
25. 25   @leastprivilege   Implicit  Flow  (Na9ve  /  Local  Clients)   Resource  Owner   Client  
26. 26   @leastprivilege   Step  1a:  Authoriza9on  Request   Resource  Server   Resource  Owner   Client   GET  /authorize?      client_id=nativeapp&      scope=read&          redirect_uri=http://localhost/cb&      response_type=token&      state=123   Authoriza9on  Server  
27. 27   @leastprivilege   Step  1b:  Authen9ca9on  
28. 28   @leastprivilege   Step  1c:  Consent  
29. 29   @leastprivilege   Twiger  Consent  
30. 30   @leastprivilege   Evernote  Consent  
31. 31   @leastprivilege   The  Consent  Screen  is  important!   h;p://zachholman.com/2011/01/oauth_will_murder_your_children/  
32. 32   @leastprivilege   Step  1d:  Token  Response   Resource  Owner   Client   GET  /cb#      access_token=abc&      expires_in=3600&      state=123   Authoriza9on  Server   Resource  Server  
33. 33   @leastprivilege   Summary  –  Implicit  Flow   •  User  enters  creden0als  at  the  authoriza0on  server   –  not  at  the  client   •  authoriza0on  server  returns  (short  lived)  access  token   –  to  reduce  exposure  of  token   •  OGen  combined  with  OS  helper  mechanisms   –  cookie  container   –  na9ve  APIs  
34. 34   @leastprivilege   Authoriza9on  Code  Flow     (Server-­‐based  Clients)   Web  Applica9on   (Client)   Resource  Server   Resource  Owner  
35. 35   @leastprivilege   Step  1a:  Authoriza9on  Request   Web  Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   GET  /authorize?      client_id=webapp&      scope=read&      redirect_uri=https://webapp/cb&      response_type=code&      state=123  
36. 36   @leastprivilege   Step  1d:  Authoriza9on  Response   Web  Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   GET  /cb?      code=xyz&      state=123  
37. 37   @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  
38. 38   @leastprivilege   Step  2b:  Token  Response   Web  Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   {      "access_token"  :  "abc",      "expires_in"  :  "3600",      "token_type"  :  "Bearer",      "refresh_token"  :  "xyz"       }  
39. 39   @leastprivilege   Step  3:  Resource  Access   Web  Applica9on   (Client)   Resource  Owner   GET  /resource      Authorization:  Bearer  access_token   Resource  Server  
40. 40   @leastprivilege   Summary  –  Code  Flow   •  Designed  for  "confiden0al"  clients   –  client  can  store  secret  securely   –  client  authen9ca9on  and  authoriza9on  based  on  client   iden9ty  possible   –  typically  server-­‐based  applica9ons   •  Accountability  is  provided   –  access  token  never  leaked  to  the  browser   •  Long-­‐lived  access  can  be  implemented  
41. 41   @leastprivilege   Crossing  trust  boundaries…   •  So  far  authoriza0on  server  and  resource  server  are   always  in  the  same  trusted  subsystem   –  your  client  accessing  your  back-­‐end   –  facebook  client  accessing  facebook  back-­‐end   •  What  if  you  want  to  cross  the  line?   –  Asser9on  Flow  
42. 42   @leastprivilege   Asser9on  flow   Client   "home"   Authoriza0on  Server   Resource   "partner"   Authoriza0on  Server   1)  request  token    using  "core"  flow   2)  request  token  using     "asser0on"  flow   3)  use     token   trust   trust  
43. 43   @leastprivilege   Authoriza9on   -­‐  iden0ty   -­‐  claims  from  token   -­‐  DB  /  profile  data   User   -­‐  iden0ty   -­‐  client  type   -­‐  scopes   Client  
44. 44   @leastprivilege   Authoriza9on   •  User   •  Client   [ResourceAc9onAuthorize("add",  "customer"]   public  HgpResponseMessage  Post(Customer  c)   {  }   [ScopeAuthorize("add")]   public  HgpResponseMessage  Post(Customer  c)   {  }   h;ps://github.com/thinktecture/Thinktecture.Iden0tyModel  
45. 45   @leastprivilege   Summary   •  Users  /  Clients  /  APIs  is  the  mindset   •  OAuth2  is  a  framework   –  and  a  set  of  design  pagerns   •  The  authoriza0on  server  acts  a  a  traffic  cop  between   the  par0es   •  Access  control  is  based  on  access  tokens   •  Authoriza0on  is  based  on  the  user   –  and  op9onally  the  client  (type)  
46. 46   @leastprivilege   thank  you!