A technical Introduction to OAuth2, OpenID Connect and JSON Web Tokens (NDC London 2013)

1. A  technical  Introduc0on  to     OAuth2,  OpenID  Connect     and  JSON  Web  Tokens     The  Security  Stack  for  modern   Applica0ons   Dominick  Baier   hCp://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     •  MicrosoL  MVP  for  Developer  Security   •  dominick.baier@thinktecture.com   •  hCp://leastprivilege.com   think mobile!
3. 3   @leastprivilege   Agenda   •  How  we  got  there   •  OAuth2   •  OpenID  Connect   •  JSON  Web  Tokens  
4. Enterprise  Security   SOAP WS* XML SAML Kerberos/LDAP
5. The  mobile  Revolu9on   No SOAP No SAML No WS* HTTP JSON
6. Scenario  1:  Mobile  Enterprise  Apps  
7. Scenario  2:  Business  to  Customer   §  Mobile web apps / app store deployment §  Reach and cross-platform becomes much more important Web  API  
8. 8   @leastprivilege   Authen9ca9on,  Single  Sign-­‐on  &   Federa9on   Applica0ons   Security   Service   use  
9. 9   @leastprivilege   (Delegated)  authoriza9on   Applica0ons   Security   Service   use   Back  end  Services   access  
10. 10   @leastprivilege   What  is  OAuth2  ?  
11. 11   @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   MicrosoL,  Yahoo!  And  Google     •  2010  -­‐  OAuth  2.0  work  begins  in  IETF   •  Working  deployments  of  various  draLs  &  versions  at  Google,   MicrosoL,  Facebook,  Github,  TwiCer,  Flickr,  Dropbox…   •  Mid  2012  –  Lead  author  and  editor  resigned  &  withdraws  his   name  from  all  specs       •  October  2012  –  RFC  6749,  RFC  6750  
12. 12   @leastprivilege   High  level  overview   Human   SoLware   Service/Data  
13. 13   @leastprivilege   hCp://hueniverse.com/2007/09/explaining-­‐oauth/   hCp://amzn.com/1449311601  
14. 14   @leastprivilege  
15. 15   @leastprivilege  
16. 16   @leastprivilege  
17. 17   @leastprivilege   High  level  overview   Resource  Owner   Client   Resource  Server  
18. 18   @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  
19. 19   @leastprivilege   OAuth2  Flows   •  Authoriza0on  Code  Flow   –  front  +  back  channel   –  "confiden9al"  clients   •  Implicit  Flow   –  front  channel   –  na9ve  /  user  agent  based  clients   •  Resource  Owner  Password  Creden0al  Flow   –  back  channel   –  trusted  clients   •  Client  Creden0als  Flow   –  back  channel   –  service  to  service  communica9on  
20. 20   @leastprivilege   Authoriza9on  Code  Flow     (Web  Applica9on  Clients)   Web  Applica9on   (Client)   Resource  Server   Resource  Owner  
21. 21   @leastprivilege   Step  1a:  Authoriza9on  Request   Web  Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   GET  /authorize?      client_id=webapp&      scope=resource&      redirect_uri=https://webapp/cb&      response_type=code&      state=123  
22. 22   @leastprivilege   Step  1b:  Authen9ca9on  
23. 23   @leastprivilege   Step  1c:  Consent  
24. 24   @leastprivilege   Twiber  Consent  
25. 25   @leastprivilege   Evernote  Consent  
26. 26   @leastprivilege   The  Consent  Screen  is  important!   hCp://zachholman.com/2011/01/oauth_will_murder_your_children/  
27. 27   @leastprivilege   Step  1d:  Authoriza9on  Response   Web  Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   GET  /cb?      code=xyz&      state=123  
28. 28   @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  
29. 29   @leastprivilege   Step  2b:  Token  Response   Web  Applica9on   (Client)   Authoriza9on  Server   Resource  Owner   {      "access_token"  :  "abc",      "expires_in"  :  "3600",      "token_type"  :  "Bearer",      "refresh_token"  :  "xyz"       }  
30. 30   @leastprivilege   Step  3:  Resource  Access   Web  Applica9on   (Client)   Resource  Owner   GET  /resource      Authorization:  Bearer  access_token   Resource  Server  
31. 31   @leastprivilege   (Step  4:  Refreshing  the  Token)   Web  Applica9on   (Client)   Resource  Owner   POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=refresh_token&   refresh_token=xyz   Authoriza9on  Server  
32. 32   @leastprivilege   Refresh  Token  Management  (Flickr)  
33. 33   @leastprivilege   Refresh  Token  Management   (Dropbox)  
34. 34   @leastprivilege   Refresh  Token  Management   (Microsoe  Live)  
35. 35   @leastprivilege   Summary  –  Code  Flow   •  Designed  for  "confiden0al"  clients   –  client  can  store  secret  securely   –  typically  server-­‐based  applica9ons   •  Accountability  is  provided   –  access  token  never  leaked  to  the  browser   •  Long-­‐lived  access  can  be  implemented  
36. 36   @leastprivilege   JSON  Web  Token  (JWT)   {      "typ":  "JWT",      "alg":  "HS256"   }   {      "iss":  "http://myIssuer",      "exp":  "1340819380",      "aud":  "http://myResource",      "sub":  "alice",        "client":  "xyz",      "scope":  ["read",  "search"]   }   Header   Claims   eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMD.4MTkzODAsDQogImh0dHA6Ly9leGFt   Header   Claims   Signature  
37. 37   @leastprivilege   Implicit  Flow  (Na9ve  /  Local  Clients)   Resource  Owner   Client  
38. 38   @leastprivilege   Step  1a:  Authoriza9on  Request   Resource  Server   Resource  Owner   Client   GET  /authorize?      client_id=nativeapp&      scope=resource&          redirect_uri=http://localhost/cb&      response_type=token&      state=123   Authoriza9on  Server  
39. 39   @leastprivilege   Step  1b:  Token  Response   Resource  Owner   Client   GET  /cb#      access_token=abc&      expires_in=3600&      state=123   Authoriza9on  Server   Resource  Server  
40. 40   @leastprivilege   Step  2:  Resource  Access   Resource  Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  
41. 41   @leastprivilege   Summary  –  Implicit  Flow   •  Simplified  handshake   –  no  authoriza9on  code   •  Token  is  exposed  to  browser  /  local  OS   •  No  client  authen0ca0on   –  no  refresh  tokens   –  oeen  combined  with  cookies  and  web  views  or  OS  APIs  
42. 42   @leastprivilege   Resource  Owner  Password  Creden9al   Flow  (Trusted  Applica9on)   Resource  Owner   Client   Resource  Server  
43. 43   @leastprivilege   Step  1a:  Token  Request   Resource  Owner   Client   Authoriza9on  Server   POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=password&   scope=resource&   user_name=owner&   password=password&   Resource  Server  
44. 44   @leastprivilege   Step  1b:  Token  Response   Resource  Owner   Client   Authoriza9on  Server   {      "access_token"  :  "abc",      "expires_in"  :  "3600",      "token_type"  :  "Bearer",      "refresh_token"  :  "xyz"       }   Resource  Server  
45. 45   @leastprivilege   Step  2:  Resource  Access   Resource  Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  
46. 46   @leastprivilege   Summary  –     Resource  Owner  Creden9al  Flow   •  Resource  owner  creden0als  are  exposed  to  client   –  users  should  not  become  accustomed  to  that   •  S0ll  beCer  to  store  access/refresh  token  on  device  than   password   –  if  the  developer  is  using  that  feature   •  Typically  client  and  back  end  built  by  same  party  
47. 47   @leastprivilege   Client  Creden9als  Flow  –   No  human  involved  at  all   Client   Authoriza9on  Server   POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=client_credentials&   scope=resource  
48. 48   @leastprivilege   OAuth2  &  Authen9ca9on   •  OAuth2  is  for  (delegated)  authoriza0on   –  authen9ca9on  is  part  of  that   –  …but  with  the  authoriza9on  server,  not  the  client   •  OAuth2  can  be  used  as  founda0on  for  authen0ca0on   –  many  "homegrown"  solu9on   hCp://www.thread-­‐safe.com/2012/01/problem-­‐with-­‐oauth-­‐for-­‐authen0ca0on.html   hCp://www.cloudiden0ty.com/blog/2013/01/02/oauth-­‐2-­‐0-­‐and-­‐sign-­‐in-­‐4/    
49. 49   @leastprivilege   OAuth2  for  Authen9ca9on:  Request   UserInfo  RS   Resource  Owner   Client   GET  /authorize?      client_id=nativeapp&      redirect_uri=http://localhost/cb&      scope=signin&      response_type=token&      state=123   Authoriza9on  Server  
50. 50   @leastprivilege   OAuth2  for  Authen9ca9on:  Response   UserInfo   Resource  Owner   Client   GET  /cb?      access_token=abc&      userid=123&      expires_in=3600&      state=123   Authoriza9on  Server  
51. 51   @leastprivilege   OAuth2  for  Authen9ca9on:     Accessing  User  Profile   UserInfo  RS   Resource  Owner   Client   GET  /userinfo      Authorization:          Bearer  access_token   Firstname,  Lastname,  Email…  
52. 52   @leastprivilege   A  Solu9on?  
53. 53   @leastprivilege   Another  Problem   1.  User  logs  into  malicious  app   (app  steals  token)   access  token   2.  Malicious  developer  uses  stolen     access  token  in  legi0mate  app   access  token   Impersonated!
54. 54   @leastprivilege   hbp://openid.net/connect  
55. 55   @leastprivilege  
56. 56   @leastprivilege   OpenID  Connect   •  OpenID  Connect  builds  on  top  of  OAuth2   –  Authoriza9on  Code  Flow   –  Implicit  Flow   –  (and  some  varia9ons)   •  Specifies  addi0onal  concepts   –  ID  Token   –  UserInfo  endpoint   •  ..and  some  addi0onal  protocols,  e.g.   –  discovery  &  dynamic  registra9on   –  session  management  
57. 57   @leastprivilege   OpenID  Connect:  The  Players   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client
58. 58   @leastprivilege   Step  1a:  Authoriza9on  Request   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client GET  /authorize?      client_id=webapp&      redirect_uri=https://webapp/cb&      scope=openid  profile&      response_type=code&      state=123  
59. 59   @leastprivilege   Scopes  &  Claims   •  OpenID  defines  a  set  of  standard  scopes  and  claims   Scope   Claims   profile   name,  family_name,  given_name,  middle_name,   nickname,  preferred_username,  profile,  picture,   website,  gender,  birthdate,  zoneinfo,  locale,  and   updated_at.   email   email,  email_verified   address   address   phone   phone_number,  phone_number_verified   offline_access   requests  refresh  token  
60. 60   @leastprivilege   Step  1b:  Authen9ca9on   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client
61. 61   @leastprivilege   Step  1c:  Consent   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client Application WebApp asks for permission to access your profile
62. 62   @leastprivilege   Step  1d:  Authoriza9on  Response   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client GET  /cb?      code=abc&      state=123  
63. 63   @leastprivilege   Step  2a:  Token  Request   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client POST  /token    Authorization:  Basic  (client_id:secret)     grant_type=authorization_code&   authorization_code=abc&   redirect_uri=https://webapp/cb  
64. 64   @leastprivilege   Step  2b:  Token  Response   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client {      "access_token"  :  "abc",      "id_token":  "uvw",      "expires_in"  :  "3600",      "token_type"  :  "Bearer",      "refresh_token"  :  "xyz"       }  
65. 65   @leastprivilege   ID  Token   •  JWT  that  contains  claims  about  the  authen0ca0on   event   –  Issuer  (iss)   –  Subject  (sub)   –  Audience  (aud)   –  Expira9on  (exp)   •  Client  must  validate  the  ID  token  at  this  point  
66. 66   @leastprivilege   Step  3a:  UserInfo  Request   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client GET  /userinfo      Authorization:          Bearer  access_token  
67. 67   @leastprivilege   Step  3b:  UserInfo  Response   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client {        "sub":  "248289761001",        "name":  "Jane  Doe",        "email":  "janedoe@example.com"   }  
68. 68   @leastprivilege   Summary   •  OAuth2  is  a  founda0on  (or  framework)   –  least  common  denominator  technology   –  delegated  authoriza9on   –  extensible   •  OpenID  Connect  is  an  authen0ca0on  protocol   –  built  on  top  of  OAuth2  extensibility   –  interoperable   •  JSON  Web  Token  is  a  standardized  token  format   –  issuer,  life9me,  audience  +  other  claims   –  signatures  &  encryp9on