Slide 1

Slide 1 text

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!

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     •  MicrosoL  MVP  for  Developer  Security   •  [email protected]   •  hCp://leastprivilege.com   think mobile!

Slide 3

Slide 3 text

3   @leastprivilege   Agenda   •  How  we  got  there   •  OAuth2   •  OpenID  Connect   •  JSON  Web  Tokens  

Slide 4

Slide 4 text

Enterprise  Security   SOAP WS* XML SAML Kerberos/LDAP

Slide 5

Slide 5 text

The  mobile  Revolu9on   No SOAP No SAML No WS* HTTP JSON

Slide 6

Slide 6 text

Scenario  1:  Mobile  Enterprise  Apps  

Slide 7

Slide 7 text

Scenario  2:  Business  to  Customer   §  Mobile web apps / app store deployment §  Reach and cross-platform becomes much more important Web  API  

Slide 8

Slide 8 text

8   @leastprivilege   Authen9ca9on,  Single  Sign-­‐on  &   Federa9on   Applica0ons   Security   Service   use  

Slide 9

Slide 9 text

9   @leastprivilege   (Delegated)  authoriza9on   Applica0ons   Security   Service   use   Back  end  Services   access  

Slide 10

Slide 10 text

10   @leastprivilege   What  is  OAuth2  ?  

Slide 11

Slide 11 text

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  

Slide 12

Slide 12 text

12   @leastprivilege   High  level  overview   Human   SoLware   Service/Data  

Slide 13

Slide 13 text

13   @leastprivilege   hCp://hueniverse.com/2007/09/explaining-­‐oauth/   hCp://amzn.com/1449311601  

Slide 14

Slide 14 text

14   @leastprivilege  

Slide 15

Slide 15 text

15   @leastprivilege  

Slide 16

Slide 16 text

16   @leastprivilege  

Slide 17

Slide 17 text

17   @leastprivilege   High  level  overview   Resource  Owner   Client   Resource  Server  

Slide 18

Slide 18 text

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  

Slide 19

Slide 19 text

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  

Slide 20

Slide 20 text

20   @leastprivilege   Authoriza9on  Code  Flow     (Web  Applica9on  Clients)   Web  Applica9on   (Client)   Resource  Server   Resource  Owner  

Slide 21

Slide 21 text

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  

Slide 22

Slide 22 text

22   @leastprivilege   Step  1b:  Authen9ca9on  

Slide 23

Slide 23 text

23   @leastprivilege   Step  1c:  Consent  

Slide 24

Slide 24 text

24   @leastprivilege   Twiber  Consent  

Slide 25

Slide 25 text

25   @leastprivilege   Evernote  Consent  

Slide 26

Slide 26 text

26   @leastprivilege   The  Consent  Screen  is  important!   hCp://zachholman.com/2011/01/oauth_will_murder_your_children/  

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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  

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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  

Slide 32

Slide 32 text

32   @leastprivilege   Refresh  Token  Management  (Flickr)  

Slide 33

Slide 33 text

33   @leastprivilege   Refresh  Token  Management   (Dropbox)  

Slide 34

Slide 34 text

34   @leastprivilege   Refresh  Token  Management   (Microsoe  Live)  

Slide 35

Slide 35 text

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  

Slide 36

Slide 36 text

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  

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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  

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

40   @leastprivilege   Step  2:  Resource  Access   Resource  Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  

Slide 41

Slide 41 text

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  

Slide 42

Slide 42 text

42   @leastprivilege   Resource  Owner  Password  Creden9al   Flow  (Trusted  Applica9on)   Resource  Owner   Client   Resource  Server  

Slide 43

Slide 43 text

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  

Slide 44

Slide 44 text

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  

Slide 45

Slide 45 text

45   @leastprivilege   Step  2:  Resource  Access   Resource  Owner   Client   GET  /resource      Authorization:          Bearer  access_token   Resource  Server  

Slide 46

Slide 46 text

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  

Slide 47

Slide 47 text

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  

Slide 48

Slide 48 text

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/    

Slide 49

Slide 49 text

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  

Slide 50

Slide 50 text

50   @leastprivilege   OAuth2  for  Authen9ca9on:  Response   UserInfo   Resource  Owner   Client   GET  /cb?      access_token=abc&      userid=123&      expires_in=3600&      state=123   Authoriza9on  Server  

Slide 51

Slide 51 text

51   @leastprivilege   OAuth2  for  Authen9ca9on:     Accessing  User  Profile   UserInfo  RS   Resource  Owner   Client   GET  /userinfo      Authorization:          Bearer  access_token   Firstname,  Lastname,  Email…  

Slide 52

Slide 52 text

52   @leastprivilege   A  Solu9on?  

Slide 53

Slide 53 text

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!

Slide 54

Slide 54 text

54   @leastprivilege   hbp://openid.net/connect  

Slide 55

Slide 55 text

55   @leastprivilege  

Slide 56

Slide 56 text

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  

Slide 57

Slide 57 text

57   @leastprivilege   OpenID  Connect:  The  Players   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client

Slide 58

Slide 58 text

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  

Slide 59

Slide 59 text

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  

Slide 60

Slide 60 text

60   @leastprivilege   Step  1b:  Authen9ca9on   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

62   @leastprivilege   Step  1d:  Authoriza9on  Response   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client GET  /cb?      code=abc&      state=123  

Slide 63

Slide 63 text

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  

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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  

Slide 66

Slide 66 text

66   @leastprivilege   Step  3a:  UserInfo  Request   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client GET  /userinfo      Authorization:          Bearer  access_token  

Slide 67

Slide 67 text

67   @leastprivilege   Step  3b:  UserInfo  Response   Identity Provider Authorization Endpoint Token Endpoint UserInfo Endpoint User Agent Client {        "sub":  "248289761001",        "name":  "Jane  Doe",        "email":  "[email protected]"   }  

Slide 68

Slide 68 text

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