0
OAuth	  –	  authen+ca+on	  &	  authoriza+on	           framework	  for	  REST	  APIs	                  Paul	  Madsen	     ...
Authen+ca+on	  for	  SOAP	  •  The	  SOAP	  world	  has	  long	  had	  standards	  related	  to	     authen+ca+on	  &	  au...
But	  …..	  
1)	  REST	  authen+ca+on	  •  REST	  world	  has	  not	  had	  comparable	  standards	  •  Nothing	  comparable	  to	  WS-...
2)	  Password	  an+-­‐paKern	  	  Site	  asks	  YOU	  for	  your	  GOOGLE	  password	  so	  it	  can	  access	  your	  Goo...
Tsk	  tsk!	  •  Teaches	  users	  to	  be	  indiscriminate	     with	  their	  passwords	  •  Doesn’t	  support	  granular...
Importance	  of	  revoca+on	     This	  is	  shiny!!!!!	                      I	  should	  use	  that	  more	             ...
3)	  Cloud	  APIs	  •  Within	  move	  towards	  SaaS	  –	  trend	  towards	  API	  access	     to	  data/services	  to	  ...
Cloud	  cures	  everything	  
4)	  Na+ve	  mobile	  apps	  
Drivers	                           Password	  Lack	  of	             an+-­‐standards	              paKern	                ...
OAuth 2.0•  Defines	  authoriza+on	  &	  authen+ca+on	     framework	  for	  RESTful	  APIs	  •  Approaching	  final	  stand...
Mobile	  app	  IdM	  architecture	  	  
Na+ve	  vs	  web	  apps	  •  Not	  going	  to	  try	  to	  predict	  winner	  –	  expect	  both	  •  Authen+ca+on	  &	  au...
Federa+on	  •  Federa+on	  abstracts	  away	  from	  applica+ons	     specifics	  of	  authen+ca+on	  &	  authoriza+on	  –	...
Tokens	  •  Federated	  authen+ca+on	  for	  both	  web	  and	     na+ve	  mobile	  applica+ons	  is	  based	  on	  exchan...
Federa+on	  takes	  different	  forms	      For	  web	  apps,	  tokens	  carry	         Browser	                           ...
Tokens	  for	  mobile	  web	  applica+ons	  •  Federa+on	  for	  web	  applica+ons	  manifests	  as	     SSO	  from	  some...
Tokens	  for	  web	  applica+ons	  Iden+ty	  provider	                    Service	  provider	     1.  User	  trades	      ...
Best	  prac+ces	  •  Standards	      –  OpenID	  2.0	  for	  consumer	  scenarios	      –  SAML	  2.0	  for	  enterprise	 ...
Tokens	  for	  na+ve	  applica+ons	  •  Na+ve	  applica+ons	  authen+cate	  to	  REST	  APIs	  by	     presen+ng	  a	  tok...
Mobile	  authn	  op+ons	                                                                  • Pwd	  shared	  with	  3rd	  pa...
Tokens	  for	  na+ve	  applica+ons	  Service	  provider	                             1.  User	  trades	  creden+als	  for	...
Best	  prac+ces	  •  Use	  the	  browser	  to	  authen+cate	  the	  user	  to	  the	  AS,	     don’t	  collect	  user	  pa...
Walk	  through	  •  Walk	  through	  scenario	  of	  an	  employee	  using	  a	     na+ve	  app	  on	  their	  phone/table...
Walk	  through	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  ...
Load	  authz	  page	  
Load	  authz	  page	  
Load	  authz	  page	  GET	  /as/authoriza+on.oauth2?client_id=mobileapp&state=abc123&redirect_uri=mobileapp://redirect_her...
IdP	  Discovery	  
IdP	  Discovery	  
IdP	  discovery	  
SSO	  Request	  
SSO	  request	  
SSO	  Request	                           <form	  method="post"	  ac+on="hKps://idp.example.org/SAML2/SSO/POST"	  >	       ...
User	  authen+ca+on	  
User	  authen+ca+on	  
User	  authen+ca+on	  
SSO	  response	  
SSO	  Response	  
SSO	  Response	  <saml:Asser+on>	  <saml:Issuer>hKps://idp.example.org/SAML2</saml:Issuer>	  <ds:Signature	  xmlns:ds="hKp...
Response	  with	  code	  
Response	  with	  code	  
Response	  with	  code	  HTTP/1.1	  302	  Found	  Loca+on:	  mobileapp://redirect_here?	    	  state=abc123&	    	  code=w...
Trade	  code	  for	  token	  
Trade	  code	  for	  token	  
Trade	  code	  for	  token	  GET	  /as/token.oauth2?client_id=a&redirect_uri=mobileapp://       redirecthere&grant_type=au...
Client	  calls	  API	  
Client	  calls	  API	  
Client	  calls	  API	  hKps://graph.facebook.com/paul.e.madsen/  friends/?  access_token=lSBbci4Jg8MsjiSqZLBrzEXgd4mK  UNh...
Verify	  token	  
Verify	  token	  
Verify	  token	  GET	  /as/token.oauth2?         client_id=b&client_secret=pwd&grant_type=urn:ping:validate&token=lSBbci4J...
Return	  Data	  
Return	  Data	  
Return	  data	  HTTP/1.1	  200	  OK	  Content-­‐Type:	  applica+on/json;	  charset=UTF-­‐8	  
Time	  passes	  
Refresh	  token	  
Refresh	  token	  
Refresh	  token	  GET	  /as/token.oauth2?      client_id=a&grant_type=refresh_token&refresh_token=oQWqwMUIL2nde      MHsWE...
Thanks	  Paul	  Madsen	  @paulmadsen	  
Gluecon oauth-03
Gluecon oauth-03
Gluecon oauth-03
Upcoming SlideShare
Loading in...5
×

Gluecon oauth-03

2,809

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,809
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Gluecon oauth-03"

  1. 1. OAuth  –  authen+ca+on  &  authoriza+on   framework  for  REST  APIs   Paul  Madsen   Ping  Iden+ty  
  2. 2. Authen+ca+on  for  SOAP  •  The  SOAP  world  has  long  had  standards  related  to   authen+ca+on  &  authoriza+on  of  web  services  •  WS-­‐Trust  defines  a  protocol  by  which  a  SOAP  client   can  obtain  a  security  token(typically  a  SAML   asser+on)  •  WS-­‐Security  s+pulates  how  to  aKach  the  token   (SAML  asser+on)  to  a  SOAP  request  
  3. 3. But  …..  
  4. 4. 1)  REST  authen+ca+on  •  REST  world  has  not  had  comparable  standards  •  Nothing  comparable  to  WS-­‐Security  -­‐  mish  mash  of   HTTP  Basic,  HTTP  Digest,  password,  and  SSL  for   message  authen+ca+on    •  Nothing  comparable  to  WS-­‐Trust  –  consequently   client  bears  burden  of  managing  creden+als  &  trust  
  5. 5. 2)  Password  an+-­‐paKern    Site  asks  YOU  for  your  GOOGLE  password  so  it  can  access  your  Google  stuff.  
  6. 6. Tsk  tsk!  •  Teaches  users  to  be  indiscriminate   with  their  passwords  •  Doesn’t  support  granular   permissions,  e.g.  X  can  read  but  not   write  •  Doesn’t  support  (easy)  revoca+on  –   to  be  sure  of  turning  off  access   users  must  change  password  
  7. 7. Importance  of  revoca+on   This  is  shiny!!!!!   I  should  use  that  more   WTF  is  this  thing?  
  8. 8. 3)  Cloud  APIs  •  Within  move  towards  SaaS  –  trend  towards  API  access   to  data/services  to  supplement/replace  browser   access  •  Salesforce.com expects that within the next year – only 1/3 of access will be via browser  •  APIs  of  PaaS  offerings  allow  the  customer  to  expose  its   own  cloud  services  •  Clear  trend  for  these  APIs  is  towards  REST  
  9. 9. Cloud  cures  everything  
  10. 10. 4)  Na+ve  mobile  apps  
  11. 11. Drivers   Password  Lack  of   an+-­‐standards   paKern   OAuth   Na+ve   mobile   Cloud  APIs   Applica+ons  
  12. 12. OAuth 2.0•  Defines  authoriza+on  &  authen+ca+on   framework  for  RESTful  APIs  •  Approaching  final  standardiza+on  in  IETF  •  Applied  to  delegated  authoriza+on  –  mi+gates   password  an+-­‐paKern  -­‐  archetypical  use  case  •  Also  applicable  to  many  other  scenarios  –   even  those  with  no  users  •  Notable  for  its  op+miza+ons  for  mobile  
  13. 13. Mobile  app  IdM  architecture    
  14. 14. Na+ve  vs  web  apps  •  Not  going  to  try  to  predict  winner  –  expect  both  •  Authen+ca+on  &  authoriza+on  should  be  consistent   across  both  models,  so  that   –  Users  are  not  confused,  eg  use  different   creden+als  and/or  authen+ca+on  ceremony  for   the  two  models,  even  if  accessing  the  same   applica+on   –  Service  Providers  aren’t  forced  to  implement   duplicate  &  incompa+ble  security  frameworks   for  the  two  models  
  15. 15. Federa+on  •  Federa+on  abstracts  away  from  applica+ons   specifics  of  authen+ca+on  &  authoriza+on  –   outsourced  to  specialized  providers  •  Complexity  hidden  by  token  issuance  &  valida+on  •  Federa+on  standards  define   –  Token  formats   –  How  clients  obtain  tokens   –  How  clients  present  tokens  to  applica+on   providers    
  16. 16. Tokens  •  Federated  authen+ca+on  for  both  web  and   na+ve  mobile  applica+ons  is  based  on  exchange   and  delivery  of  tokens  to  the  applica+on  •  Tokens  carry  (or  point  to)  security  informa+on   (like  aKributes  or  authoriza+ons)  for  user  trying   to  access  the  applica+on.    •  Clients  typically  exchange  creden+als  for  tokens   -­‐  easier/safer  to  share  the  token  across  the   network  rather  than  the  original  creden+als  •  When  token  is  subsequently  presented  to  an   applica+on  provider,  they  serve  to  authen+cate   and/or  authorize  the  request  
  17. 17. Federa+on  takes  different  forms   For  web  apps,  tokens  carry   Browser   app   AKributes  for  authen+ca+on   For  na+ve  apps,  tokens  carry   app   data   Authoriza+on  for  aKributes  
  18. 18. Tokens  for  mobile  web  applica+ons  •  Federa+on  for  web  applica+ons  manifests  as   SSO  from  some  IdP  to  the  applica+on  provider  •  SSO  especially  relevant  for  mobile  •  Tokens  aKes+ng  to  the  user’s  iden+ty  and/or   authen+ca+on  status  delivered  through  (as   redirects)  the  browser  from  IdP  to  the   applica+on  provider  •  Applica+on  provider  validates  token  and   extracts  iden+ty  aKributes  from  within  in  order   to  create  local  session    
  19. 19. Tokens  for  web  applica+ons  Iden+ty  provider   Service  provider   1.  User  trades   creden+als  for  a   token  from  IdP   SAML   2.  Token  delivered   OpenID   Applica+on   through  the   browser  to  SP   3.  SP  validates  token,   and  delivers   applica+on  HTML   Pwd   HTML   to  browser   Token  Device   Browser  
  20. 20. Best  prac+ces  •  Standards   –  OpenID  2.0  for  consumer  scenarios   –  SAML  2.0  for  enterprise  &  cloud   –  WS-­‐Federa+on  for  homogeneous  MSFT  •  IdP  Discovery   –  In  consumer  space,  consider  Nascar  with  email-­‐ based  supplement   –  In  cloud  space,  consider  email-­‐based  •  Both  IdP  (portal)  and  SP  (deep-­‐linking)  ini+ated   are  relevant  •  Mobile  browser  constraints  may  recommend   ar+fact  model  in  SAML  
  21. 21. Tokens  for  na+ve  applica+ons  •  Na+ve  applica+ons  authen+cate  to  REST  APIs  by   presen+ng  a  token  on  the  call  •  The  precursor  act  of  the  na+ve  applica+on  obtaining  a   token  is  oeen  called  ‘authoriza+on’  (par+cularly  in   those  cases  when  the  API  fronts  user  info,  eg  profile,   tweets,  etc)  •  User  authorizes  (or  consents)  to  the  na+ve  applica+on   having  access  to  the  API  (and  their  data)  –  the   authoriza+on  is  manifested  as  the  issuance  of  a  token  to   the  na+ve  app  •  OAuth  2.0  dominant  protocol  by  which  a  na+ve  app   obtains  the  desired  authoriza+ons  and  the   corresponding  token  (and  then  uses  against  API)  
  22. 22. Mobile  authn  op+ons   • Pwd  shared  with  3rd  party  Embedded  browser   Inline   • App  owns  UI   • No  need  to  leave  app   • Custom  scheme   • Enables  SSO   • Enables  strong  authn   • AS  owns  UI   • Visual  trust  cues   • Can  leverage  stored  pwds   External  browser  
  23. 23. Tokens  for  na+ve  applica+ons  Service  provider   1.  User  trades  creden+als  for  a  token   2.  Token  delivered  through  the  browser   to  na+ve  applica+on   Applica+on   3.  Na+ve  applica+on  presents  token  on   API  calls   4.  Applica+on  returns  applica+on  data   as  JSON   Pwd   Token   JSON/XML  Device   Browser   Applica+on   OAuth  
  24. 24. Best  prac+ces  •  Use  the  browser  to  authen+cate  the  user  to  the  AS,   don’t  collect  user  passwords  within  na+ve  applica+on   itself  •  A  separate  browser  window  preferred  to  embedded  –   gives  user  the  visual  trust  cues  trained  to  look  for  •  OAuth  authoriza+on  code  grant  type  is  relevant  –  allows   a  refresh  token  to  be  delivered  to  the  na+ve  applica+on   (obviates  need  to  con+nually  reauthorize)  •  Use  browser  for  IdP  discovery  if  doing  SSO  (rather  than   within  na+ve  applica+on  itself)  •  Na+ve  applica+on  should  register  custom  scheme  on   install,  to  enable  subsequent  passing    of  token  from   browser  back  to  na+ve  applica+on  
  25. 25. Walk  through  •  Walk  through  scenario  of  an  employee  using  a   na+ve  app  on  their  phone/tablet  to  interact   with  a  SaaS  provider  •  SAML  provides   –  Authen+ca+on  of  employee  to  SaaS  provider  •  OAuth  provides   –  authoriza+on  of  na+ve  app  to  access  SaaS  APIs   –  Issuance  of  tokens  from  SaaS  to  na+ve  app  
  26. 26. Walk  through                                                                                                                      OAuth                                                                                                            SAML                                                                                                                                                OAuth  
  27. 27. Load  authz  page  
  28. 28. Load  authz  page  
  29. 29. Load  authz  page  GET  /as/authoriza+on.oauth2?client_id=mobileapp&state=abc123&redirect_uri=mobileapp://redirect_here&response_type=code  HTTP/1.1   Note   -­‐ -­‐  No  client  pwd   -­‐ -­‐  custom  scheme  on  redirect  URL   -­‐ -­‐  response  type  of  ‘code’  
  30. 30. IdP  Discovery  
  31. 31. IdP  Discovery  
  32. 32. IdP  discovery  
  33. 33. SSO  Request  
  34. 34. SSO  request  
  35. 35. SSO  Request   <form  method="post"  ac+on="hKps://idp.example.org/SAML2/SSO/POST"  >   <input  type="hidden"  name="SAMLRequest"  value="request"  />   <input  type="submit"  value="Submit"  />   </form>    <samlp:AuthnRequest    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"   xmlns:saml="urn:oasis:names:tc:SAML:2.0:asser+on"  ID="aaf23196-­‐1773-­‐2113-­‐474a-­‐ fe114412ab72"  Version="2.0"  IssueInstant="2004-­‐12-­‐05T09:21:59Z”>      <saml:Issuer>hKps://sp.example.com/SAML2</saml:Issuer>    <samlp:NameIDPolicy   AllowCreate="true"    Format="urn:oasis:names:tc:SAML: 2.0:nameid:format:persistent"/>  </samlp:AuthnRequest>  
  36. 36. User  authen+ca+on  
  37. 37. User  authen+ca+on  
  38. 38. User  authen+ca+on  
  39. 39. SSO  response  
  40. 40. SSO  Response  
  41. 41. SSO  Response  <saml:Asser+on>  <saml:Issuer>hKps://idp.example.org/SAML2</saml:Issuer>  <ds:Signature  xmlns:ds="hKp://www.w3.org/2000/09/xmldsig#">...</ds:Signature>  <saml:Subject>  <saml:NameID  Format="urn:oasis:names:tc:SAML:2.0:nameid-­‐format:persistent">   3f7b3dcf-­‐1674-­‐4ecd-­‐92c8-­‐1544f346baf8  </saml:NameID></saml:Subject>  <saml:AKributeStatement>  <saml:AKribute  Name=“email”  >  <saml:AKributeValue  xsi:type="xs:string">pmadsen@pingiden+ty.com</saml:AKributeValue>    </saml:AKribute>    </saml:AKributeStatement>    </saml:Asser+on>    
  42. 42. Response  with  code  
  43. 43. Response  with  code  
  44. 44. Response  with  code  HTTP/1.1  302  Found  Loca+on:  mobileapp://redirect_here?    state=abc123&    code=wizJmaSTPAf0wqSeB3vmDx2mNSZK6g  Content-­‐Length:  0  
  45. 45. Trade  code  for  token  
  46. 46. Trade  code  for  token  
  47. 47. Trade  code  for  token  GET  /as/token.oauth2?client_id=a&redirect_uri=mobileapp:// redirecthere&grant_type=authoriza+on_code&code=wizJmaSTPAf0wqSeB3vmDx2 mNSZK6g  HTTP/1.1  Host:  as.com  Accept:  */*  HTTP/1.1  200  OK  Content-­‐Type:  applica+on/json;  charset=UTF-­‐8  {"token_type":"Bearer","expires_in":"60","refresh_token":"oQWqwMUIL2ndeMHsWEy FO0GyalvKSvc2QI4YuG82RMGkM","access_token":"lSBbci4Jg8MsjiSqZLBrzEXgd4m KUNhOkyF"}  
  48. 48. Client  calls  API  
  49. 49. Client  calls  API  
  50. 50. Client  calls  API  hKps://graph.facebook.com/paul.e.madsen/ friends/? access_token=lSBbci4Jg8MsjiSqZLBrzEXgd4mK UNhOkyF  
  51. 51. Verify  token  
  52. 52. Verify  token  
  53. 53. Verify  token  GET  /as/token.oauth2? client_id=b&client_secret=pwd&grant_type=urn:ping:validate&token=lSBbci4Jg8MsjiSqZLBrzEXgd4mKUNhOkyF   HTTP/1.1  Host:  as.com  Accept:  */*    HTTP/1.1  200  OK  Content-­‐Type:  applica+on/json;  charset=UTF-­‐8     Not  OAuth  defined  
  54. 54. Return  Data  
  55. 55. Return  Data  
  56. 56. Return  data  HTTP/1.1  200  OK  Content-­‐Type:  applica+on/json;  charset=UTF-­‐8  
  57. 57. Time  passes  
  58. 58. Refresh  token  
  59. 59. Refresh  token  
  60. 60. Refresh  token  GET  /as/token.oauth2? client_id=a&grant_type=refresh_token&refresh_token=oQWqwMUIL2nde MHsWEyFO0GyalvKSvc2QI4YuG82RMGkM  HTTP/1.1  Host:  localhost:9031  Accept:  */*  HTTP/1.1  200  OK  Content-­‐Type:  applica+on/json;  charset=UTF-­‐8  {"token_type":"Bearer","expires_in":"60","refresh_token":"JZ7Qa4yH5C8E3Cik vcZZsd4ZLUgVyYnieXqybAFjObQpz","access_token":"49BPI5LuNM310o7h bB9m9cIzImT5M8gcRjE"}  
  61. 61. Thanks  Paul  Madsen  @paulmadsen  
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×