OAuth 2.0 with Pet Care House
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

OAuth 2.0 with Pet Care House

on

  • 2,200 views

OAuth 2.0 with Pet Care House

OAuth 2.0 with Pet Care House

Statistics

Views

Total Views
2,200
Views on SlideShare
1,284
Embed Views
916

Actions

Likes
1
Downloads
35
Comments
0

2 Embeds 916

http://blog.facilelogin.com 897
http://unepiscopal13.ziphelo.com 19

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

OAuth 2.0 with Pet Care House Presentation Transcript

  • 1. Prabath SiriwardenaSenior Architect & Chair, Integration MC
  • 2. Third-­‐party  applications  are  required  to  store  the  resource  owners  credentials  for  future  use,  typically  a  password  in  clear-­‐ text.  
  • 3. Servers  are  required  to  support  password  authentication,   despite  the  security  weaknesses  created  by  passwords.  
  • 4. Third-­‐party  applications  gain  overly  broad  access  to  the  resource  owners  protected  resources,  leaving  resource  owners   without  any  ability  to  restrict  duration  or  access  to  a  limited   subset  of  resources.  
  • 5. Resource  owners  cannot  revoke  access  to  an  individual  third-­‐party  without  revoking  access  to  all  third-­‐parties,  and  must  do   so  by  changing  their  password.  
  • 6. Compromise  of  any  third-­‐party  application  results  in  compromise  of  the  end-­‐users  password  and  all  of  the  data   protected  by  that  password.  
  • 7. •  Complexity  in  validating  and  generating  signatures.  •  No  clear  separation  between  Resource  Server  and   Authorization  Server.  •  Browser  based  re-­‐redirections.  
  • 8. •  An  entity  capable  of  granting  access  to  a  protected   resource.    •  When  the  resource  owner  is  a  person,  it  is  referred  to  as   an  end-­‐user.  
  • 9. •  The  server  hosting  the  protected  resources,  capable  of   accepting  and  responding  to  protected  resource  requests   using  access  tokens.  
  • 10. •  An  application  making  protected  resource  requests  on   behalf  of  the  resource  owner  and  with  its  authorization  
  • 11. •  The  server  issuing  access  tokens  to  the  client  after   successfully  authenticating  the  resource  owner  and   obtaining  authorization  
  • 12. Client  Credentials  Authorization  Code   Resource  Owner  Password  Credentials   Implicit  
  • 13. Scope  OAuth  Handshake  
  • 14. Scope   Scope  is  defined  by  the  Authorization  Server.    Scope  indicates  what  resource  client  wants  access  and  which   actions  he  wants  to  perform  on  that.     The  value  of  the  scope  parameter  is  expressed  as  a  list  of   space-­‐delimited,  case  sensitive  strings.         The  strings  are  defined  by  the  authorization  server.     OAuth  Handshake  
  • 15. Confidential  Client  Type     Web  Application   OAuth  Handshake  
  • 16. BasicAuth   client_id  /  client_secret   Client  Authenticates  to  AuthZ  Server   OAuth  Handshake  
  • 17. Authorization  Grant  Request  •   response_type  :  REQUIRED.    Value  MUST  be  set  to  "code".  •   client_id  :  REQUIRED.    The  client  identifier.  •   redirect_uri  :  OPTIONAL.    Where  to  be  redirected  by  the  Authorization  Server.  •   scope  :  OPTIONAL.    The  scope  of  the  access  request.  •   state  :  RECOMMENDED.    An  opaque  value  used  by  the  client  to  maintain  state   between  the  request  and  callback.   OAuth  Handshake  
  • 18. Authorization  Grant  Response  •   code:  REQUIRED.  The  authorization  code  generated  by  the  authorization  server  •   state  :  REQUIRED  if  the  "state"  parameter  was  present  in  the  client  authorization   request.   OAuth  Handshake  
  • 19. Access  Token  Request  •  grant_type  :  REQUIRED.    Value  MUST  be  set  to  "authorization_code".  •  code  :  REQUIRED.    The  authorization  code  received  from  the  Authorization  Server.  •  redirect_uri  :  REQUIRED,  if  the  "redirect_uri"  parameter  was  included  in  the   authorization     OAuth  Handshake  
  • 20. Access  Token  Response  •  access_token  :  REQUIRED.    The  access  token  issued  by  the  authorization  server.  •  token_type  :  REQUIRED.    The  type  of  the    token.  Value  is  case  insensitive.  •  expires_in  :  RECOMMENDED.    The  lifetime  in  seconds  of  the  access  token   OAuth  Handshake  
  • 21. Scope  OAuth  Handshake  
  • 22. Public  Client  Type     User  Agent  based  Application   OAuth  Handshake  
  • 23. Anonymous  Clients  OAuth  Handshake  
  • 24. Authorization  Grant  Request  •   response_type  :  REQUIRED.    Value  MUST  be  set  to  ”token".  •   client_id  :  REQUIRED.    The  client  identifier.  •   redirect_uri  :  OPTIONAL.    Where  to  be  redirected  by  the  Authorization  Server.  •   scope  :  OPTIONAL.    The  scope  of  the  access  request.  •   state  :  RECOMMENDED.    An  opaque  value  used  by  the  client  to  maintain  state   between  the  request  and  callback.   OAuth  Handshake  
  • 25. Access  Token  Response  •  access_token  :  REQUIRED.    The  access  token  issued  by  the  authorization  server.  •  token_type  :  REQUIRED.    The  type  of  the    token.  Value  is  case  insensitive.  •  expires_in  :  RECOMMENDED.    The  lifetime  in  seconds  of  the  access  token  •  scope  :    OPTIONAL,  if  identical  to  the  scope  requested  by  the  client,  otherwise   REQUIRED.  •  state  :  REQUIRED  if  the  "state"  parameter  was  present  in  the  client  authorization   request   OAuth  Handshake  
  • 26. Scope  OAuth  Handshake  
  • 27. Confidential  Client  Type     OAuth  Handshake  
  • 28. BasicAuth   OAuth  Handshake  
  • 29. Authorization  Grant  Request  Since  the  client  authentication  is  used  as  the  authorization  grant,  no  additional   authorization  request  is  needed.     OAuth  Handshake  
  • 30. Access  Token  Request  •  grant_type  :  REQUIRED.    Value  MUST  be  set  to  ”client_credentials".  •  scope:  OPTIONAL.    The  scope  of  the  access  request.  Note  :  The  client  needs  to  pass  BasicAuth  headers  or  authenticate  to  the  Authorization  Server  in  other  means.     OAuth  Handshake  
  • 31. Access  Token  Response  •  access_token  :  REQUIRED.    The  access  token  issued  by  the  authorization  server.  •  token_type  :  REQUIRED.    The  type  of  the    token.  Value  is  case  insensitive.  •  expires_in  :  RECOMMENDED.    The  lifetime  in  seconds  of  the  access  token   OAuth  Handshake  
  • 32. Scope  OAuth  Handshake  
  • 33. Confidential  Client  Type     OAuth  Handshake  
  • 34. BasicAuth  OAuth  Handshake  
  • 35. Authorization  Grant  Request   The  method  through  which  the  client  obtains  the  resource  owner        credentials  is  beyond  the  scope  of  this  specification.    The  client        MUST  discard  the  credentials  once  an  access  token  has  been  obtained   OAuth  Handshake  
  • 36. Access  Token  Request  •  grant_type  :  REQUIRED.    Value  MUST  be  set  to  ”client_credentials".  •  username  :  REQUIRED.    The  resource  owner  username,  encoded  as  UTF-­‐8.  •  password  :  REQUIRED.    The  resource  owner  password,  encoded  as  UTF-­‐8.  •  scope:  OPTIONAL.    The  scope  of  the  access  request.   OAuth  Handshake  
  • 37. Access  Token  Response  •  access_token  :  REQUIRED.    The  access  token  issued  by  the  authorization  server.  •  token_type  :  REQUIRED.    The  type  of  the    token.  Value  is  case  insensitive.  •  expires_in  :  RECOMMENDED.    The  lifetime  in  seconds  of  the  access  token   OAuth  Handshake  
  • 38. Runtime  
  • 39. Bearer   MAC   Runtime  
  • 40. Bearer   MAC   Bearer  Any  party  in  possession  of  a  bearer  token  (a  "bearer")  can  use   it  to  get  access  to  the  associated  resources  (without   demonstrating  possession  of  a  cryptographic  key).   Runtime  
  • 41. Request  with  Bearer  GET  /resource/1  HTTP/1.1  Host:  example.com  Authorization:  Bearer  “access_token_value”   http://tools.ietf.org/html/draft-­‐ietf-­‐oauth-­‐v2-­‐bearer-­‐20   Runtime  
  • 42. Bearer   MAC   MAC   HTTP  MAC  access  authentication  scheme   Runtime  
  • 43. Request  with  MAC  GET  /resource/1  HTTP/1.1  Host:  example.com    Authorization:  MAC  id="h480djs93hd8",                                                                                        nonce="274312:dj83hs9s",                                                                                        mac="kDZvddkndxvhGRXZhvuDjEWhGeE="   http://tools.ietf.org/html/draft-­‐ietf-­‐oauth-­‐v2-­‐http-­‐mac-­‐01   Runtime