Web  API  Authoriza0on  &     Access  Control     done  right?!   Dominick  Baier   h;p://leastprivilege.com   @leastprivilege   think mobile!

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!

Enterprise  Security   SOAP WS* XML SAML Kerberos/LDAP

No SOAP No SAML No WS* No Windows HTTP JSON

5   @leastprivilege   Modern  applica9ons   Users   Clients   Resources  

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   @leastprivilege   …s9ll  can  become  complex   *  

8   @leastprivilege   OAuth2  

9   @leastprivilege   OAuth2  approach   APIs   Authoriza0on  Server   Scopes:  read,  write,     delete,  search…   client_id=client1,   scope=search  read   access  token   access  token   Bob  

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  

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   @leastprivilege   h;ps://github.com/thinktecture/Thinktecture.Authoriza0onServer   h;ps://github.com/thinktecture/Thinktecture.Iden0tyServer.v3   AuthorizationServer IdentityServer v3 (preview)

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    

14   @leastprivilege   Involving  humans   •  "Trusted"  clients   –  Resource  Owner  Password  Creden9al  Flow  

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  

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   @leastprivilege   Step  2:  Use  token   Resource  Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  

18   @leastprivilege   (Step  3:  Refreshing  the  Token)   Client   POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=refresh_token&   refresh_token=xyz   Authoriza9on  Server  

19   @leastprivilege   Refresh  Token  Management  (Flickr)  

20   @leastprivilege   Refresh  Token  Management   (Dropbox)  

21   @leastprivilege   Refresh  Token  Management   (Microsod  Live)  

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  

23   @leastprivilege   Separa9ng  user  creden9als     from  the  client…   •  Local  /  mobile  /  user-­‐agent  based  clients   –  Implicit  Flow   •  Server-­‐based  /  confiden0al  clients   –  Autoriza9on  Code  Flow  

24   @leastprivilege   Implicit  Flow  (Na9ve  /  Local  Clients)   Resource  Owner   Client  

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  

26   @leastprivilege   Step  1b:  Authen9ca9on  

27   @leastprivilege   Step  1c:  Consent  

28   @leastprivilege   Twifer  Consent  

29   @leastprivilege   Evernote  Consent  

30   @leastprivilege   The  Consent  Screen  is  important!   h;p://zachholman.com/2011/01/oauth_will_murder_your_children/  

31   @leastprivilege   Step  1d:  Token  Response   Resource  Owner   Client   GET  /cb#      access_token=abc&      expires_in=3600&      state=123   Authoriza9on  Server   Resource  Server  

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  

33   @leastprivilege   Authoriza9on  Code  Flow     (Server-­‐based  Clients)   Web  Applica9on   (Client)   Resource  Server   Resource  Owner  

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  

35   @leastprivilege   Step  1d:  Authoriza9on  Response   Web  Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   GET  /cb?      code=xyz&      state=123  

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  

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"       }  

38   @leastprivilege   Step  3:  Resource  Access   Web  Applica9on   (Client)   Resource  Owner   GET  /resource      Authorization:  Bearer  access_token   Resource  Server  

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  

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   –  …  

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  

42   @leastprivilege   Authoriza9on   -­‐  iden0ty   -­‐  claims  from  token   -­‐  DB  /  profile  data   User   -­‐  iden0ty   -­‐  client  type   -­‐  scopes   Client  

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  

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)  

45   @leastprivilege   thank  you!