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   Resources  

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   OAuth2  approach   APIs   Authoriza0on  Server   Scopes:  read,  write,     delete,  search…   client_id=client1,   scope=search  read   access  token   access  token   Bob  

Slide 10

Slide 10 text

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  

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

Slide 13

Slide 13 text

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    

Slide 14

Slide 14 text

14   @leastprivilege   Involving  humans   •  "Trusted"  clients   –  Resource  Owner  Password  Creden9al  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&   username=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   (Step  3:  Refreshing  the  Token)   Client   POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=refresh_token&   refresh_token=xyz   Authoriza9on  Server  

Slide 19

Slide 19 text

19   @leastprivilege   Refresh  Token  Management  (Flickr)  

Slide 20

Slide 20 text

20   @leastprivilege   Refresh  Token  Management   (Dropbox)  

Slide 21

Slide 21 text

21   @leastprivilege   Refresh  Token  Management   (Microsod  Live)  

Slide 22

Slide 22 text

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  

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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  

Slide 26

Slide 26 text

26   @leastprivilege   Step  1b:  Authen9ca9on  

Slide 27

Slide 27 text

27   @leastprivilege   Step  1c:  Consent  

Slide 28

Slide 28 text

28   @leastprivilege   Twifer  Consent  

Slide 29

Slide 29 text

29   @leastprivilege   Evernote  Consent  

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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  

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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  

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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  

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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  

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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  

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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  

Slide 44

Slide 44 text

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)  

Slide 45

Slide 45 text

45   @leastprivilege   thank  you!