Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Loading in …3
1 of 49

OAuth for your API - The Big Picture



Download to read offline

OAuth is taking off as a standard way for apps and websites to handle authentication. But OAuth is a fast moving spec that can be hard to pin down.
Why should you use OAuth and what are the business and operational benefits? What's the story with all of the different versions and which one should you choose?
Watch this webinar with Apigee's CTO Gregory Brail and Sr. Architect Brian Pagano for 'big picture straight talk' on these OAuth questions and more.

Related Books

Free with a 30 day trial from Scribd

See all

OAuth for your API - The Big Picture

  1. 1. OAuth:  The  Big  Picture   8.11.11  @  11:05  PST   VOIP  or  Dial-­‐in  (see  chat)   Greg  Brail    @gbrail   Brian  Pagano  @brianpagano  
  2. 2. @gbrail @brianpagano
  3. 3. API Workshop Webinar Series (videos & slides at Mapping  out  your  API  Strategy                             PragmaHc  REST:  API  Design  Fu                           10  PaLerns  in  Successful  API  Programs   What  to  Measure:  API  AnalyHcs   Is  your  API  Naked?    API  Tech  &    OperaHons   Does  your  API  need  PCI?  (Compliance)   Developers  Hate  MarkeHng:  Driving  API  AdopHon   OAuth:    The  Big  Picture     “Boss,  we  need  an  API”  (coming  Sep  14)  
  4. 4. Topics   A  Brief  IntroducHon  to  OAuth   Why  OAuth  is  good  for  API  consumers  (really!)     Why  OAuth  is  good  for  API  providers   ImplementaHon  challenges  for  the  provider   RecommendaHons  
  5. 5. A  Brief  IntroducHon  to  OAuth  
  6. 6. Mo;va;ons  Behind  OAuth   We  all  understand  the  idea  of  a  service   APIs,  web  sites  that  support  mobile  apps  …     We  all  understand  password-­‐based  security:   Provide  your  creden:als  in  a  secure  way  to  gain  access  
  7. 7. Mo;va;ons  Behind  OAuth   Services  are  used  by  applica;ons   Your  web  browser  is  merely  one  applica:on     Services  and  passwords  don’t  mix  well   How  many  applica:ons  have  your  password?   Do  you  trust  them  all?  Are  you  sure?  
  8. 8. What  is  OAuth?   OAuth  is  another  way  to  authenHcate  to  a  service.   .  
  9. 9. Imagine  ....   …you  had  a  different  password  for  every  service   Already  do?  You  are  in  a  :ny  minority.     …you  had  a  different  password  for  every  applicaHon   A  compromised  applica:on  can’t  wreak  as  much  havoc     …You  can’t  possibly  remember  it  or  write  it  down              Instead,  it  is  stored  by  the  applica:on  that  needs  it  
  10. 10. That’s  what  OAuth  does.  
  11. 11. See Eran Hammer-Lehav’s writeup on the history of OAuth:
  12. 12. Terminology  (simplified)   App used to access service CLIENT Sometimes called “consumer” USER Person using the service! Where the service runs Sometimes called “resource SERVER owner” Sometimes called “service provider”
  13. 13. Example  OAuth  Flow   1.  Bob  visits,  which  uses  a  service  provided  by  TwiLer.    Bob  already  has   logins  for  and  TwiLer.   2.  Behind  the  scenes,  uses  its  OAuth  credenHals  to  begin  the   authenHcaHon  process  for  Bob   3.  redirects  Bob  temporarily  to  to  log  in.  never  sees   Bob’s  TwiIer  password   4.  If  and  only  if  this  is  successful,  uses  its  own  OAuth  creden;als  to   retrieve  credenHals  for  Bob   5.  stores  Bob’s  new  credenHals  along  with  Bob’s  account.  They  allow   him  to  use,  and  only,  to  access  TwiLer  
  14. 14. Let’s  see  that  again   Bob’s password BIT.LY (CLIENT) Bob’s OAuth credentials for Twitter API a BOB cc (USER) ess Bob’s Twitter TWITTER password (SERVER)
  15. 15. What  if...  is  hacked  and  the  password  database  is  leaked?   TwiDer  revokes’s  OAuth  creden:als   All  creden:als  stored  by  are  immediately  rejected     TwiLer  users  don’t  have  to  change  their  passwords  
  16. 16. What  if...   Hackers  phish  Bob  and  get  his  TwiLer  password?   He  changes  his  TwiDer  password  as  soon  as  he  knows.     Bob  doesn’t  have  to  do  anything  at  because  it   never  had  the  password  
  17. 17. Next  Example:    OAuth  Flow  for  Mobile  Apps   1.  Bob  launches  FooApp,  which  uses  a  service  provided  by  TwiLer.         2.  Bob  already  has  a  TwiLer  username  and  password.       3.  Behind  the  scenes,  FooApp  uses  its  OAuth  credenHals  to  begin  the   authenHcaHon  process  for  Bob   4.  FooApp  opens  a  browser  window  and  directs  Bob  to  TwiLer  to  log  in.   FooApp  never  sees  Bob’s  TwiLer  password   5.  If  and  only  if  this  is  successful,  FooApp  uses  its  OAuth  credenHals  to   retrieve  credenHals  for  Bob   6.  FooApp  stores  these  locally.  They  allow  Bob  to  use  FooApp,  and  only   FooApp  to  access  TwiLer  
  18. 18. Another  Example  OAuth  Flow   Bob’s OAuth token for Twitter FOOAPP (CLIENT) API a BOB cc (USER) ess Bob’s Twitter TWITTER (SERVER) password
  19. 19. What  if...   Bob  loses  his  phone,  and  he  didn’t  set  a  phone  password?   He  immediately  logs  in  to  TwiDer   He  revokes  the  creden:als  that  TwiDer  gave  FooApp  on  his   phone     He  doesn’t  have  to  change  his  TwiLer  password  because  his   phone  never  had  it.  
  20. 20. For  Web  Apps  that  Expose  APIs   OAuth  means  that  web  apps  don’t  have  to  share   passwords  
  21. 21. For  Web  Apps  that  Expose  APIs   The  alternaHve  to  OAuth  is  an  unacceptable  security   risk  for  modern  web  apps.     The  other  alternaHve  is  some  sort  of  universal  single-­‐ sign-­‐on  mechanism.  
  22. 22. Recommenda;on   We  believe  that  all  web  applica:ons  that  expose  APIs  to   other  web  applica:ons  must  support  OAuth.  
  23. 23. For  APIs  Designed  for  Mobile  and  Na;ve  Apps:   OAuth  eliminates  the  need  to  store  a  password  on  a  mobile  device.     An  OAuth  token..  harder  to  guess  :ed  to  a  par:cular  applica:on  and  device   ..may  be  revoked  without  affec:ng  other  devices  and  apps  
  24. 24. For  APIs  Designed  for  Mobile  and  Na;ve  Apps   OAuth  makes  the  authenHcaHon  process  future-­‐proof     It’s  under  the  control  of  the  API  team         SSL,  mul:-­‐factor  authen:ca:on,  terms  of  service,  you  name  it   –  there  is  a  place  to  plug  it  in  without  touching  the  client  
  25. 25. Recommenda;on   We  believe  that  all  APIs  that  support  mobile  and  na:ve   apps  should  support  OAuth  …     ..and  encourage  or  require  it  for  mobile  and  na:ve  apps    
  26. 26. For  Server-­‐to-­‐Server  APIs   Having  a  separate  set  of  authenHcaHon  credenHals  for  each   applicaHon  is  a  nice  feature  of  OAuth…     But  for  server-­‐to-­‐server  use,  the  need  to  log  in  securely  using  a   browser  gets  in  the  way     Simply  assigning  a  unique  password  to  each  applicaHon  is  sufficient   (or  two-­‐way  SSL  is  another  good  but  cumbersome  approach)    
  27. 27. Recommenda;on   We  believe  that  OAuth  is  not  necessary  for  APIs  that  are   only  used  by  other  servers…     …but  once  those  APIs  are  useful  for  other  types  of   clients  –  and  they  usually  do  –  then  you  are  back  in   the  OAuth  game!    
  28. 28. But  I  Hate  OAuth!   p   Picture by g-mikee
  29. 29. OAuth  is  more  cumbersome  for  developers  than  plain   passwords.  
  30. 30. But  OAuth  is  a  lot  beLer  for  the  end  user.   No  password  sharing  between  web  apps   No  passwords  stored  on  mobile  devices     Using  OAuth  is  worth  the  effort.  
  31. 31. What  version   p   should  I  use?    
  32. 32. What  Version  of  OAuth  Should  I  Use?   1.0 Had  a  security  flaw.  No  one  should  be  using  it  now!       Stable  and  well-­‐understood.   1.0a Uses  a  signature  to  exchange  credenHals  between  client  and  server.   So…SSL  is  not  necessary,  but  geing  the  signature  right  is  tricky.       AcHvely  under  development  in  the  IETF   2.0 Slowly  but  surely  geing  stable  –  core  flows  unlikely  to  change  much   Supports  a  “bearer  token,”  which  is  easier  to  code  but  requires  SSL   OpHonal  specs  to  support  signatures,  SAML,  etc.  but  specs  not  yet  stable  
  33. 33. “Fl-­‐OAuth  Chart”  for  the  API  Team   Use OAuth 2.0 with bearer tokens Can your API require HTTPS? Use OAuth 1.0a
  34. 34. How  Should  I  Use  OAuth  2.0?   Just  a  big  random  number   BEARER TOKEN Requires  SSL   By  far  the  simplest  to  implement  –  USE  IT!         Like  OAuth  1.0a,  uses  signature  instead  of  SSL   MAC TOKEN SHll  changing      -­‐  WAIT!       Makes  sense  if  the  API  team  and  developers   SAML really  want  SAML   But  sHll  changing    -­‐  WAIT!  
  35. 35. How  Should  I  Use  OAuth  2.0?   Different  ways  to  get  the  token:     “Authoriza:on  Code”  –  designed  for  use  by  web  apps  <-­‐  important!   “Implicit  Grant”  –  designed  for  JavaScript-­‐rich  web  apps  <-­‐  also  important!       “Resource  Owner  Password  Creden:als”   “Client  Creden:als”   Bypass  many  parts  of  the  OAuth  flow   Re-­‐introduces  password  sharing   Basically  ways  to  make  “OAuth”  work  when  you  don’t  really  want  OAuth  
  36. 36. What  Version  of  OAuth  2.0  Should  I  Use?   I’m  not  sure  why  this  is  even  a  quesHon.       You  should  use  the  latest  one.  
  37. 37. What  are  Legs  and  How  Many  Does  OAuth  Have?   Since  there  is  a  user,  a  client,  and  a  server  in  OAuth,  some   3-LEGGED people  call  it  “three-­‐legged  OAuth”         Some  APIs  idenHfy  just  the  “client”  and  not  the  “user”   2-LEGGED Omen  this  is  done  using  SSL   But  an  OAuth  1.0  signature  may  be  used  instead   Technically,  “two-­‐legged  OAuth”  is  not  OAuth  at  all  
  38. 38. Why  is  OAuth  so   Hard  for   p   Developers?    
  39. 39. Why  is  OAuth  so  Hard  for  Developers?   The  “authenHcaHon  dance”  is  painful.     Signatures  are  painful.   They  are  now  op:onal  (and  up  to  the  discre:on  of  the  provider)  in  2.0   There  are  a  lot  of  libraries  –  use  them   Ge]ng  the  signature  algorithm  right  is  harder  than  it  looks  at  first!  
  40. 40. Why  is  OAuth  so  Hard  for  Developers?   Where  do  you  store  the  credenHals  on  the  client?   They  must  be  available  in  clear  text   Mobile  devices  can  break  them  into  pieces  ..  but  in  the  end   :me  and  physical  access  will  eventually  wear  down  anything     At  any  rate  storing  the  original  password  directly  is  worse!  
  41. 41. When  OAuth  is  a  Bad  Idea   Anything  that  is  not  done  on  behalf  of  a  human   Admin  tools,  server-­‐to-­‐server  communica:on,  …     Anything  that  requires  “commercial”  levels  of  trust   If  you  require  the  capabili:es  of  a  PKI  then  OAuth  is  not  that     One-­‐;me  tokens   OAuth  is  a  lot  of  machinery  to  make  one  API  call  
  42. 42. Other  Bad  Ideas   “We  have  our  own  version  of  OAuth”    
  43. 43. Other  Bad  Ideas   “We  invented  something  that’s  kind  of  like  Oauth”  
  44. 44. More  Recommenda;ons       DEVELOPERS Use  a  library   Think  about  using  a  proxy       Use  OAuth  2.0   Use  Bearer  Tokens   Use  “AuthorizaHon  code”  and  “implicit  grant”  only   API TEAM Use  the  latest  dram!   Default  to  SSL   Think  about  using  a  product   At  least  use  a  library  for  signatures  
  45. 45. Next Time Mapping  out  your  API  Strategy                             PragmaHc  REST:  API  Design  Fu                           10  PaLerns  in  Successful  API  Programs   What  to  Measure:  API  AnalyHcs   Is  your  API  Naked?    API  Tech  &    OperaHons   Does  your  API  need  PCI?  (Compliance)   Developers  Hate  MarkeHng:  Driving  API  AdopHon   OAuth:    The  Big  Picture     “Boss,  we  need  an  API”  (Sep  14)  
  46. 46. THANK  YOU       Ques:ons  and  ideas  to: @gbrail   @brianpagano