OAuth based reference architecture for API Management

4,718 views

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
4,718
On SlideShare
0
From Embeds
0
Number of Embeds
122
Actions
Shares
0
Downloads
212
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OAuth based reference architecture for API Management

  1. 1. OAuth  2.0  Reference  Model   for     API  Management   Sumedha  Rubasinghe   Senior  Architect,  WSO2  API  Manager  Team  
  2. 2. About  WSO2   ๏  ๏  Global  enterprise,  founded  in   2005  by  acknowledged  leaders  in   XML,  web  services    technologies,   standards    and  open  source   Provides  only  open  source   pla:orm-­‐as-­‐a-­‐service  for  private,   public  and  hybrid  cloud   deployments   ๏  ๏  *   All  WSO2  products  are  100%  open   source  and  released  under  the   Apache  License  Version  2.0.   Is  an  AcIve  Member  of  OASIS,   Cloud  Security  Alliance,  OSGi   Alliance,  AMQP  Working  Group,   OpenID  FoundaIon  and  W3C.   ๏  Driven  by  InnovaIon   ๏  Launched  first  open  source  API   Management  soluIon  in  2012   ๏  Launched  App  Factory  in  2Q   2013   ๏  Launched  Enterprise  Store  and   first  open  source  Mobile  soluIon   in  4Q  2013  
  3. 3. What  we  Deliver   *  
  4. 4. What  we  will  cover...   ●  Main  concepts  in  OAuth  2.0  model     ●  How  WSO2  supports  OAuth  2.0  based  API  Management?     ●  OAuth  2.0  based  extensions  in  WSO2  API  Management   soluIon     *  
  5. 5. Web  (based)  APIs   ●  hXps://www.facebook.com/sam.jason/photos   ●  hXp://api-­‐public.ne:lix.com/catalog/Itles/movies/60021896   ●  many  more..     *  
  6. 6. Pre  OAuth  Era  ..   How  do  I  know  for  sure?   *  
  7. 7. Pre  OAuth  Era  ..   *  
  8. 8. Pre  OAuth  Era  ..   No  Control  over  password   storage.   Complete  access  to  user   account.   *   ApplicaIons  can  be   compromised.   Changing  password  can  break   many  apps.   Requires  password  reset  to   revoke.  
  9. 9. OAuth  2.0  -­‐  in  a  nutshell..   “The  OAuth  2.0  authorizaIon  framework  enables  a  third-­‐party   applica2on  to  obtain  limited  access  to  an  HTTP  service…”     -­‐OAuth  2.0  SpecificaKon,  hLp://tools.ieO.org/html/rfc6749   *  
  10. 10. WSO2  API  Manager   ●  Complete  API  Management  Pla:orm   ○  ○  ○  ○  ○  ○  ○  ○  API  Publishing   API  Store   SubscripIon  Mgt   Token  Management   ThroXling   StaIsIcs   Scalable  Deployment   OAuth  2.0  based   ●  Apache  v2  Licensed     ●  Build  on  top  of  proven  WSO2  components   *   ○  Enterprise  Service  Bus   ○  IdenIty  Server   ○  Governance  Registry   ●  hXp://docs.wso2.org/display/AM160/WSO2+API+Manager
  11. 11. OAuth  2.0  -­‐  DefiniKons   *   ●  Resource  Owner   ○  EnIty(end  user)  capable  of  granIng  access  to  a  resource   ○  FB  user  (enIty)  -­‐>   hXps://www.facebook.com/search/me/friends  (resource)     ●  Resource  Server  (hXps://www.facebook.com)   ○  Server  hosIng  protected  resources   ○  Capable  of  accepIng  and  responding  to  resource  requests     ●  Client  (FB  applicaIon)   ○  ApplicaIon  making  requests  to  access  protected  resources     ●  Authoriza2on  Server  (can  be  same  as  Resource  Server)   ○  Server  issuing  access  tokens  to  the  client  
  12. 12. OAuth  2.0  Protocol  Flow   hLp://tools.ieO.org/html/rfc6749   *  
  13. 13. AuthorizaKon  Grants   *  
  14. 14. AuthorizaKon  Code   ●  End  user  visits  auth  page   ○  response_type=code Web  Server  Apps   ●  End  user  is  redirected  to  your  site  with  auth  code   ○  http://yoursite.com/?code=xxxxxx ●  Web  Server  exchanges  Auth  Code  for  an  Access  Token   ○  POST /token code=xxxxxx&grant_type=authorization_code *  
  15. 15. AuthorizaKon  Code   *  
  16. 16. AuthorizaKon  Code   *  
  17. 17. Access  Token  from  Auth  Code   hLp://docs.wso2.org/display/AM160/Token+API   *  
  18. 18. Access  Token  Response   *  
  19. 19. Implicit  Grant   ●  Browser  based  apps   ■  no  server  side  code   ■  browser  makes  API  requests  directly     ●  User  visits  a  page   ○  response_type=token Browser  based  Apps   ●  User  is  redirected  to  your  site  with  access  token   ○  http://yoursite.com/#token=xxxxxx ●  Token  is  only  available  to  browser  (only  in  fragment)   *  
  20. 20. Implicit  Grant  -­‐  Syntax   Browser  based  Apps   hLp://docs.wso2.org/display/AM160/Token+API   *  
  21. 21. Password  Grant   Trusted  ApplicaKons   ●  Only  by  trusted  clients   ○  Apps  &  APIs  -­‐  by  same  enterprise  /First  party  Apps   hLp://docs.wso2.org/display/AM160/Token+API   *  
  22. 22. Client  CredenKals   ApplicaKons   ●  ApplicaIon  level  access   ●  ApplicaIon  has   ○  client_id  (consumer  key)   ○  client_secret  (consumer  secret)     ●  Server  uses  client_id  &  client_secret  to  obtain  access  token   ○  POST  /token   grant_type=client_credenIals&client_id=XXXX&client_secret= YYYY   *  
  23. 23. Client  CredenKals   hLp://docs.wso2.org/display/AM160/Token+API   *  
  24. 24. Mobile  ApplicaKons   ●  Use  ‘implicit’  grant  type     ○  (similar  to  browser  based  apps)     ●  Mobile  App  directly  does  API  calls     ●  No  client  (mobile  app)  secret     ●  NaIve  App  -­‐>  Browser  based  call   *   Mobile  Apps  
  25. 25. Facebook  Login   hXps://developers.facebook.com/docs/facebook-­‐login/     *  
  26. 26. Grant  Type  Summary   ●  authorizaKon_code   ○  Web  Server  based  applicaIons     ●  implicit   ○  Browser  based  applicaIons,  Mobile  Apps     ●  password   ○  username/password  based  access     ●  client  _credenKals   ○  ApplicaIons  (with  no  need  of  user  level  authorizaIon)   *  
  27. 27. Extensions  to  Grant  Types   ●  SAML2  Bearer  Tokens  -­‐>  OAuth2   *  
  28. 28. Accessing  APIs   Query  Parameter   Access  token  in  HTTP  Header   *  
  29. 29. Access  Token  Lifecycle   ●  AcIve   ●  Revoked   ●  Expired   ●  In-­‐AcIve   *  
  30. 30. Refreshing  an  expired  token   hLp://docs.wso2.org/display/AM160/Token+API   *  
  31. 31. Bearer  Tokens   ●  Security  ConsideraIons   ○  Replies  on  transport  level  security  (HTTPS)   ○  No  cryptographic  verificaIon       ●  Security  RecommendaIons   ○  Use  HTTPs  (always)  &  verify  SSL  CerIficates   ○  Protect  Bearer  tokens   ○  Choose  token  lifeIme  wisely   ○  Do  not  persist  tokens  unnecessarily     *  
  32. 32. MAC  Tokens   ●  Provides  cryptographic  verificaIon  of  request   *  
  33. 33. LimiKng  Access  through  ‘scope'   ●  ‘scope’  -­‐>  specifies  what  needs  be  done  with  the  access  token     ●  Specified  @  the  point  of  obtaining  access  token     ●  space  delimited,  comma  delimited  string     ●  eg:  Facebook  Extended  Permissions   ○  hXps://developers.facebook.com/docs/reference/login/ extended-­‐permissions/     *  
  34. 34. “scope”  -­‐  Facebook  Example   hXps://developers.facebook.com/docs/reference/login/extended-­‐permissions/   *  
  35. 35. “scope”  -­‐  Facebook  Example   *  
  36. 36. “scope”  -­‐  Facebook  Example   *  
  37. 37. “scope”  -­‐  Token  Request  Syntax   hXps://www.facebook.com/dialog/oauth? client_id=APP_ID&redirect_uri=APP_URL&scope=read_friendlists ,read_mailbox   *  
  38. 38. Extensions  based  on  OAuth  Model   ●  API  InvocaIon  StaIsIcs  CollecIon   ●  Access  ThroXling   *  
  39. 39. WSO2  API  Manager   *  
  40. 40. SubscripKon  Management   *  
  41. 41. Token  Management   *  
  42. 42. Resource  Level  AuthorizaKon   *  
  43. 43. Tier  based  ThroLling   *  
  44. 44. StaKsKcs   *  
  45. 45. Business  Model   *  
  46. 46. Contact  us  !  

×