API Security and Federation Patterns


Published on

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1iq4lYa.

Francois Lascelles examines the role of API management infrastructure in API Security, API Access Control and API Federation and its interaction with enterprise infrastructure, social identity and application developers. Filmed at qconsf.com.

Francois Lascelles is a subject matter expert on API security and the application of standards such as OAuth and OpenID Connect. As Layer 7’s Chief Architect, he guides the solutions architecture team and aligns product evolution with field trends. Francois joined Layer 7 in the company’s infancy – contributing as the first developer and designing the foundation of Layer 7’s Gateway technology.

Published in: Technology, News & Politics
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

API Security and Federation Patterns

  1. 1. API  Security  and   Federa1on  Pa3erns   QCon  San  Francisco  -­‐  November  13,  2013   Francois  Lascelles,  Chief  Architect,  Layer  7  Technologies                                        #qconsf    #OAuth                          @flascelles  
  2. 2. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations /api-security-federation-patterns InfoQ.com: News & Community Site • 750,000 unique visitors/month • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • News 15-20 / week • Articles 3-4 / week • Presentations (videos) 12-15 / week • Interviews 2-3 / week • Books 1 / month
  3. 3. Presented at QCon San Francisco www.qconsf.com Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide
  4. 4. Agenda   §  Introduc1on   §  API  Security  Components   §  Authoriza1on  Server  Pa3erns   –  –  –  –  –  Two-­‐way  token  issuing   Redirec1on-­‐based  token  issuing   Nested  handshakes   Federated  handshakes   Other  extension  handshakes   §  Vulnerabili1es  and  Mi1ga1on   –  Fishing  a3acks   –  Public  vs  Confiden1al  clients   –  Bearer  vs  MAC  token  types   §  Managing  API  Security   2   API  Security  and  Federa1on  Pa3erns  
  5. 5. Informa=on  fragmenta=on   –  Users  and  organiza1ons  interact  with  IT  assets  fragmented  across   an  increasing  number  of  service  providers,  applica1ons  and   devices   Your  Org   –  In  isola1on,  each  asset  provides  limited  value   3   API  Security  and  Federa1on  Pa3erns  
  6. 6. Applica=on-­‐to-­‐applica=on  interac=on   –  APIs  let  providers  and  applica1ons  interact   §  HTTP! §  REST! §  OData! §  XML/JSON! §  Web Services! 4   API  Security  and  Federa1on  Pa3erns  
  7. 7. Secure  API  exchange   –  These  APIs  deal  with  personal  and/or  sensi1ve  informa1on  and  need  to   be  secured   §  Confiden1ality   §  Integrity   §  Availability   §  …   5   API  Security  and  Federa1on  Pa3erns  
  8. 8. Interac=ons  on  behalf  of  users   –  OAuth  lets  users  and  organiza1ons  control  these  interac1ons   §  Express  consent   §  Limit  scope   §  Turn  on/off   6   API  Security  and  Federa1on  Pa3erns  
  9. 9. API  security  logical  components   IdP   User   Authoriza1on  Server   Applica1on   Token  Server   Policy  Enforcement  Point   Resource  Server   7   API  Security  and  Federa1on  Pa3erns   API  Endpoint  
  10. 10. Authoriza=on  server  paGerns   Let  us  count  the  ways…   8   API  Security  and  Federa1on  Pa3erns  
  11. 11. Two-­‐way  handshakes   §  Limit  shared-­‐secret  exposure  by  nego1a1ng  temporary  token   1.  Authen1cate  with  secret,  get  token   2.  Consume  API,  include  token  in  requests   9   API  Security  and  Federa1on  Pa3erns  
  12. 12. E.g.  OAuth  client  creden=als  grant  type   §  In  this  grant  type,  the  applica1on  presents  its  own  creden1als   to  get  a  token.   –  No  concept  of  user  iden1ty   §  Alterna1ves   –  Present  client  creden1als  with  every  API  call  (over  secure  channel)   –  HMAC  signatures  for  every  API  call   §  Only  for  confiden1al  clients   §  No  refresh  token  in  this  case   10   API  Security  and  Federa1on  Pa3erns  
  13. 13. E.g.  OAuth  password  grant  type  (ropc)   §  Resource-­‐owner  password  creden1als   –  For  trusted  apps  only   –  For  public  or  confiden1al  clients   –  Op1mal  UX  on  mobile  apps   1.  App  collects  user  creden1als   POST /token! [Authorization: Basic optional]! Content-Type: application/x-www-formurlencoded! grant_type=password&username=franco&pass word=blah! Email:  _______   Passwd:  _______      [Login]   3.  App  gets  back  token(s)   Content-Type: application/json { 11   2.  App  uses  creds  in  call  to  token   endpoint   "access_token":”foo”, "expires_in":3600, ["refresh_token":”optional”] }! API  Security  and  Federa1on  Pa3erns  
  14. 14. Redirec=on-­‐based  handshakes   12   API  Security  and  Federa1on  Pa3erns  
  15. 15. Redirec=on-­‐based  handshakes  –  Why?   §  Avoid  the  password  sharing  an1-­‐pa3ern   Online   statement   Pretend  to  be  user   Pull  statement   Please  provide  your  cc  account  info:   •  Username   •  Password     This  seems   wrong   13   Expense   system   API  Security  and  Federa1on  Pa3erns  
  16. 16. RBH  –  step  1   (Authoriza1on  server)   Authen1cate  locally  (if  needed)   Express  consent   14   Redirect   API  Security  and  Federa1on  Pa3erns  
  17. 17. RBH  –  step  2   -­‐  User  did  not  share   passwd  with  app   Redirect   back   15   Receive   code   API  Security  and  Federa1on  Pa3erns   (callback  address)  
  18. 18. RBH  –  step  3   tmp  code   I  can  haz   token?   access  token   Call  API   (with  token)   -­‐  Applica1on  now  accesses   Much   be3er…   16   data  on  behalf  of  user   API  Security  and  Federa1on  Pa3erns  
  19. 19. E.g.  OAuth  2.0  code,  implicit   OAuth  2.0  core  specifies  two  varia1ons  on  a  redirec1on-­‐based   handshake   1.  Authoriza1on  code   –  As  we  just  described   2.  Implicit   –  No  temporary  code   –  App  gets  token  directly  through  redirect  back  from  authoriza1on  server   17   API  Security  and  Federa1on  Pa3erns  
  20. 20. Social  Login   §  An  applica1on  delegates  user  authen1ca1on  to  a  social   plamorm   –  Enhanced  user  experience   –  Remove  burden  of  managing  shared  secrets  with  users   18   API  Security  and  Federa1on  Pa3erns  
  21. 21. Social  Login  –  Step  1   §  User  click  Login  with  [Social  provider]   –  Redirected  to  Social  provider’s  authoriza1on  server   §  User  authen1cated,  expresses  consent   Do  you  authorize  app  to  get  basic  info   about  you?   Yes    [x]   No      [    ]   19   API  Security  and  Federa1on  Pa3erns  
  22. 22. Social  Login  –  Step  2   §  User  expresses  consent   –  Redirected  back  to  the  applica1on   –  Applica1on  now  has  OAuth  access  token  to  call  API  on  behalf  of  user     ++token   20   API  Security  and  Federa1on  Pa3erns  
  23. 23. Social  Login  –  Step  3   §  App  calls  [Social  provider]’s  api   –  User_info  endpoint   –  Discovers  iden1ty  of  user   –  A3aches  it  to  session  between  app  and  user-­‐agent   Who  was  this?  [access_token]   user_info   21   {  ‘sub’:  ‘franco’,  ‘email’:  ‘flascelles@gmail.com’…}     API  Security  and  Federa1on  Pa3erns  
  24. 24. Social  Login  -­‐>  OpenID  Connect   §  In  this  case,  the  API  provided  is  there  to  enable  the  federated   authen1ca1on   §  This  pa3ern  is  specified  in  standard  OpenID  Connect   –  Extends  OAuth  2.0   –  Describes  user_info,  ID  token  based  on  JWT,  …   §  Web-­‐friendly  and  modern  alterna1ve  to  SAML  web  browser   SSO   –  No  SAML,  no  XML,  no  digital  signatures,…   API  Provider  -­‐>  IdP   22   API  Security  and  Federa1on  Pa3erns  
  25. 25. Nested  handshakes   §  When  users  interact  with  an  authoriza1on  server,  they  need   to  be  authen1cated   §  What  happens  when  the  API  provider  wants  to  delegate   authen1ca1on  to  a  social  login/openid  connect  provider?   Username:  _________   Password:    _________    [Login]     Log  in  with  [Google]  [facebook]  […]     23   API  Security  and  Federa1on  Pa3erns   Step  1   App  wants  to  consume  API   on  behalf  of  user,  redirects   to  API  provider’s   authoriza1on  server  to  get   back  access  token   app  
  26. 26. Nested  handshakes   Step  2   User  redirected  to  IdP  of  choice  so  that  the  first   authoriza1on  server  gets  an  access  token  from  the   2nd  authoriza1on  server   app   Do  you  authorize  app*  to  get  basic  info   about  you?   Yes    [x]   No      [    ]   24   API  Security  and  Federa1on  Pa3erns  
  27. 27. Nested  handshakes   Step  3   User  redirected  back,  its  iden1ty  now  known  to  the   first  authoriza1on  server,  expresses  consent.   Do  you  authorize  app*  to  [scope]  on   your  behalf?   Yes    [x]   No      [    ]   25   API  Security  and  Federa1on  Pa3erns   app  
  28. 28. Nested  handshakes   Step  4   User  redirected  back  to  app.  Nested  handshakes   complete.   Two  apps,  two  access  tokens   26   API  Security  and  Federa1on  Pa3erns  
  29. 29. Federated  handshakes   §  Applica1on  already  has  a  ‘proof-­‐of-­‐authen1ca1on’,  needs  to   consume  API  on  behalf  of  user   –  Login  using  SAML  on  a  web  app   –  OpenID  Connect   §  No  redirec1on,  no  creden1als   <saml>   {jwt}   27   ?   API  Security  and  Federa1on  Pa3erns  
  30. 30. Federated  handshakes   §  SAML  Bearer  Grant   –  urn:ietf:params:oauth:grant-type:samXX-bearer   <saml>   access_token   §  JWT  Bearer  Grant   –  urn:ietf:params:oauth:grant-type:jwt-bearer   {jwt}   access_token   28   API  Security  and  Federa1on  Pa3erns  
  31. 31. Example:  Domain  of  apps  sharing  an  auth  context   §  A  domain  of  apps  on  a  mobile  device  share  an  auth  context   –  OpenID  Connect  -­‐>  JWT   §  Each  app  gets  its  own  access  token   –  urn:ietf:params:oauth:grant-type:jwt-bearer! §  Single  sign-­‐on  experience   OpenID  Connect   JWT  Bearer  Grant   Group  KeyChain   API  Provider   Mobile  apps   29   API  Security  and  Federa1on  Pa3erns  
  32. 32. Other  ‘extension’  handshakes   §  Challenge-­‐response  grant   –  One-­‐1me  passwords   –  Risk-­‐based,  context-­‐based  auth   –  Mul1-­‐factor   §  [Insert  Secret]  bearer  grant   –  Cookie   –  …   30   API  Security  and  Federa1on  Pa3erns  
  33. 33. Threats  and  Mi=ga=on   31   API  Security  and  Federa1on  Pa3erns  
  34. 34. Fishing  aGacks   §  Risk  associated  with  redirec1on-­‐based  handshakes   –  Malicious  ‘applica1on’  pretends  to  be  legi1mate   –  Inserts  its  own  endpoint  in  callback  address   –  Gets  token   §  (especially  implicit  grant)   Do  you  authorize  Legi1mate   app  to  access  API  on  your   behalf?     [X]  Yes   [    ]    No   Tricked   you   GET /authorize? response_type=token&client_id=legitimate &redirect_uri=[malicious]! 32   API  Security  and  Federa1on  Pa3erns  
  35. 35. Fishing  mi=ga=on  101   §  Register  and  validate  redirec1on  URIs   §  Strict  valida1on  (not  par1al)   §  Never  skip  consent  step   (out-­‐of-­‐band)   Register  Legi1mate  app   Callback=foo   foiledL   Error    Invalid  callback   GET /authorize? response_type=token&client_id=legitimate &redirect_uri=[malicious]! 33   API  Security  and  Federa1on  Pa3erns  
  36. 36. Fishing  on  mobile   §  On  the  web,  the  user-­‐agent  is  responsible  for  redirec1ng  to   the  callback  address   –  On  the  web,  DNS  resolves  addresses  and  HTTPS  validates  server-­‐side   trust   §  With  na1ve  mobile  apps,  each  app  registers  its  own  URL   scheme  instead   APPLE: “If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme. ” --link 34   API  Security  and  Federa1on  Pa3erns  
  37. 37. Public  vs  confiden=al  clients   §  It’s  either  confiden1al,  or  it  isn’t   –  Don’t  ‘hide’  a  secret  on  a  public  app   store  or  render  on  a  web  page   (badly  hidden  witch)   35   API  Security  and  Federa1on  Pa3erns  
  38. 38. Client  confiden=ality  does  strengthen  security   §  Assigned  secrets  to  clients  (when  appropriate)  adds  security   –  E.g.  compromised  refresh  token:   1.  Compromised   access  tokens,   refresh   foiledL  tokens   2.  Exploit  stolen   token  for  x   minutes   3.  Token  expired   4.  A3empt  to  get  fresh  token   (using  refresh  token)   5.  Authen1ca1on  required   36   API  Security  and  Federa1on  Pa3erns  
  39. 39. Bearer  vs  MAC  tokens   §  Bearer   §  MAC   Adop=on!   Tough   choice   App  developer   37   API  Security  and  Federa1on  Pa3erns  
  40. 40. Bearer,  use  responsibly   §  Bearer  tokens  are  easier  but  need  to  be  used  responsibly   –  Exchanged  and  used  over  a  secure  channel   -­‐  Don’t  log  them.   -­‐  Forget  original  (hash   them).   tokens  in   query  strings   App  developer   API  Publisher   OAuth  Server  Impl   38   -­‐  Don’t  render  them  where   they  can  be  copied  from.   -­‐  Store  them  securely.   -­‐  Server-­‐side  trust   API  Security  and  Federa1on  Pa3erns  
  41. 41. MAC,  is  it  really  more  secure?   §  Pros   –  Be3er  protected  against  man-­‐in-­‐the-­‐middle   –  If  a  request  is  intercepted,  no  big  deal   §  Cons   –  You  have  to  keep  two  secrets  safe  on  the  server  side  (per  client)   39   API  Security  and  Federa1on  Pa3erns  
  42. 42. Managing  API  Security   Extend   framework  to   client  app   Integrate   •  •  •  •  •  Authoriza1on  Server   Policy  Enforcement  Point   Resource  Server   ALFW   …   Protect   Configure,  not   code   40   API  Security  and  Federa1on  Pa3erns   •  •  •  •  Web  SSO   Analy1cs   Dev/User  Portal   …   Decouple  
  43. 43. Thank  you   QCon  SF  2013   Francois  Lascelles,  Chief  Architect,  Layer  7  Technologies    
  44. 44. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations/apisecurity-federation-patterns