Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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!

Slide 3

Slide 3 text

Enterprise  Security   SOAP WS* XML SAML Kerberos/LDAP

Slide 4

Slide 4 text

No SOAP No SAML No WS* No Windows HTTP JSON

Slide 5

Slide 5 text

5   @leastprivilege   Modern  applica9ons   Users   Clients   Web  APIs  

Slide 6

Slide 6 text

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?  

Slide 7

Slide 7 text

7   @leastprivilege   …s9ll  can  become  complex   *  

Slide 8

Slide 8 text

8   @leastprivilege   OAuth2  

Slide 9

Slide 9 text

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)  

Slide 10

Slide 10 text

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  

Slide 11

Slide 11 text

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  

Slide 12

Slide 12 text

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  

Slide 13

Slide 13 text

13   @leastprivilege   h;ps://github.com/thinktecture/Thinktecture.Authoriza0onServer   AuthorizationServer

Slide 14

Slide 14 text

14   @leastprivilege   Star9ng  simple…   •  Trusted  clients   –  Resource  Owner  Password  Creden9al  Flow   •  Machine-­‐to-­‐machine  communica0on   –  Client  Creden9als  Flow  

Slide 15

Slide 15 text

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  

Slide 16

Slide 16 text

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  

Slide 17

Slide 17 text

17   @leastprivilege   Step  2:  Use  token   Resource  Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  

Slide 18

Slide 18 text

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  

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

20   @leastprivilege   Refresh  Token  Management  (Flickr)  

Slide 21

Slide 21 text

21   @leastprivilege   Refresh  Token  Management   (Dropbox)  

Slide 22

Slide 22 text

22   @leastprivilege   Refresh  Token  Management   (Microsoe  Live)  

Slide 23

Slide 23 text

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)  

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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  

Slide 27

Slide 27 text

27   @leastprivilege   Step  1b:  Authen9ca9on  

Slide 28

Slide 28 text

28   @leastprivilege   Step  1c:  Consent  

Slide 29

Slide 29 text

29   @leastprivilege   Twiger  Consent  

Slide 30

Slide 30 text

30   @leastprivilege   Evernote  Consent  

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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  

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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  

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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  

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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  

Slide 41

Slide 41 text

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  

Slide 42

Slide 42 text

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  

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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  

Slide 45

Slide 45 text

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)  

Slide 46

Slide 46 text

46   @leastprivilege   thank  you!