Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Web API Authorization & Access Control - done r...

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

Avatar for Dominick Baier

Dominick Baier

January 17, 2014
Tweet

More Decks by Dominick Baier

Other Decks in Programming

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   •  [email protected]   •  h;p://leastprivilege.com   think mobile!
  3. 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?  
  4. 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)  
  5. 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  
  6. 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  
  7. 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  
  8. 14   @leastprivilege   Star9ng  simple…   •  Trusted  clients

      –  Resource  Owner  Password  Creden9al  Flow   •  Machine-­‐to-­‐machine  communica0on   –  Client  Creden9als  Flow  
  9. 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  
  10. 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  
  11. 17   @leastprivilege   Step  2:  Use  token   Resource

     Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  
  12. 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  
  13. 19   @leastprivilege   (Step  3:  Refreshing  the  Token)  

    Client   POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=refresh_token&   refresh_token=xyz   Authoriza9on  Server  
  14. 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)  
  15. 24   @leastprivilege   Separa9ng  user  creden9als     from

     the  client…   •  Local  /  mobile  /  user-­‐agent  based  clients   –  Implicit  Flow   •  Server-­‐based  /  confiden0al  clients   –  Autoriza9on  Code  Flow  
  16. 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  
  17. 31   @leastprivilege   The  Consent  Screen  is  important!  

    h;p://zachholman.com/2011/01/oauth_will_murder_your_children/  
  18. 32   @leastprivilege   Step  1d:  Token  Response   Resource

     Owner   Client   GET  /cb#      access_token=abc&      expires_in=3600&      state=123   Authoriza9on  Server   Resource  Server  
  19. 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  
  20. 34   @leastprivilege   Authoriza9on  Code  Flow     (Server-­‐based

     Clients)   Web  Applica9on   (Client)   Resource  Server   Resource  Owner  
  21. 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  
  22. 36   @leastprivilege   Step  1d:  Authoriza9on  Response   Web

     Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   GET  /cb?      code=xyz&      state=123  
  23. 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  
  24. 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"       }  
  25. 39   @leastprivilege   Step  3:  Resource  Access   Web

     Applica9on   (Client)   Resource  Owner   GET  /resource      Authorization:  Bearer  access_token   Resource  Server  
  26. 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  
  27. 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  
  28. 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  
  29. 43   @leastprivilege   Authoriza9on   -­‐  iden0ty   -­‐

     claims  from  token   -­‐  DB  /  profile  data   User   -­‐  iden0ty   -­‐  client  type   -­‐  scopes   Client  
  30. 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  
  31. 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)