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

Web API Authorization & Access Control - done right!? (NDC Oslo 2014)

Web API Authorization & Access Control - done right!? (NDC Oslo 2014)

Dominick Baier

June 04, 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   OAuth2  approach   APIs   Authoriza0on

     Server   Scopes:  read,  write,     delete,  search…   client_id=client1,   scope=search  read   access  token   access  token   Bob  
  5. 10   @leastprivilege   JSON  Web  Token  (JWT)   {

         "typ":  "JWT",      "alg":  "HS256"   }   {      "iss":  "http://myIssuer",      "exp":  "1340819380",      "aud":  "http://myResource",      "sub":  "bob",        "client_id":  "client1",      "scope":  ["read",  "search"]   }   Header   Claims   eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMD.4MTkzODAsDQogImh0dHA6Ly9leGFt   Header   Claims   Signature  
  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. 13   @leastprivilege   Star9ng  simple…   •  Machine-­‐to-­‐machine  communica0on

      –  Client  Creden9als  Flow   1   2   POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=client_credentials   &scope=read   {      "access_token"  :  "abc…123",      "expires_in"  :  "3600",      "token_type"  :  "Bearer",   }   Authoriza0on:  Bearer  <token>  
  8. 14   @leastprivilege   Involving  humans   •  "Trusted"  clients

      –  Resource  Owner  Password  Creden9al  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&   username=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   (Step  3:  Refreshing  the  Token)  

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

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

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

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

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

     Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   GET  /cb?      code=xyz&      state=123  
  22. 36   @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  
  23. 37   @leastprivilege   Step  2b:  Token  Response   Web

     Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   {      "access_token"  :  "abc",      "expires_in"  :  "3600",      "token_type"  :  "Bearer",      "refresh_token"  :  "xyz"       }  
  24. 38   @leastprivilege   Step  3:  Resource  Access   Web

     Applica9on   (Client)   Resource  Owner   GET  /resource      Authorization:  Bearer  access_token   Resource  Server  
  25. 39   @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  
  26. 40   @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?   –  use  Facebook  login  to  access  your  service   –  translate  Windows  account  to  access  token   –  SAML  to  JWT   –  …  
  27. 41   @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  
  28. 42   @leastprivilege   Authoriza9on   -­‐  iden0ty   -­‐

     claims  from  token   -­‐  DB  /  profile  data   User   -­‐  iden0ty   -­‐  client  type   -­‐  scopes   Client  
  29. 43   @leastprivilege   Authoriza9on   •  User   • 

    Client   [ResourceAuthorize("add",  "customer"]   public  HfpResponseMessage  Post(Customer  c)   {  }   [ScopeAuthorize("readwrite")]   public  HfpResponseMessage  Post(Customer  c)   {  }   h;ps://github.com/thinktecture/Thinktecture.Iden0tyModel  
  30. 44   @leastprivilege   Summary   •  Users  /  Clients

     /  APIs  is  the  mindset   •  OAuth2  is  a  framework   –  and  a  set  of  design  paferns   •  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)