1 / 32

Presentation outline

Experiences Deploying OpenID for a Broad User Base Security and Usability Considerations Breno de Medeiros Identity Management 2009, September 29-30 . Presentation outline. Usability research: user attitudes Implementing lessons learned Security considerations.

elton-fulton
Download Presentation

Presentation outline

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Experiences Deploying OpenID for a Broad User BaseSecurity and Usability ConsiderationsBreno de MedeirosIdentity Management 2009, September 29-30 

  2. Presentation outline • Usability research: user attitudes • Implementing lessons learned • Security considerations

  3. Before We Begin: Some Terminology • This talk covers technologies for authentication, identification, as well as authorization/delegation. • Unless it is important to specify the context, I will refer to any of these as an Auth API. • The provider of such an API will be called Provider or: • Identity Provider (IDP): Emphasis on identify/authenticate • Service Provider (SP): Emphasis on authorize/delegate • A site integrating with such an API is a Consumer or Relying Party (RP)‏

  4. User Attitudes

  5. Build It and They Will Come ...

  6. User Attitudes: Password Sharing

  7. Social Sharing • Social sites need access to users' social graph • Impractical to re-enter social graph in new sites • Password harvesting to import social graph, settings, access APIs • Users trained to share passwords

  8. Moving Against Password Anti-Pattern • Users prize convenience • Security hard to gauge: • Client malware • Account recovery procedures • Site security • Strong passwords

  9. User Attitudes: Consequences • Users likely to share passwords with sites they trust • The more reputable the site, the less it is likely to benefit from implementing identity/authorization/delegation APIs as an RP • In order for an identification/authorization solution to succeed: • Provider should define rich authorization/delegation APIs • Provider should deploy smooth user experience • Otherwise, companies likely to be first-adopters of identity solutions are also least likely to benefit (market failure).

  10. Deployment Experiences

  11. Federated Login with Legacy Accounts • Relying Parties typically also support legacy login • How to surface Auth APIs w/o impacting legacy use? • In the following, I will show some usability research results on how to modify typical login boxes to accommodate Auth APIs.

  12. Login Box Transmutation

  13. Login Box Transmutation (2)‏

  14. Login Box Transmutation (3)‏

  15. Outcomes • Users have no difficulty the first time they visit the RP • On subsequent visit, user may be confused: • 'Do I have a password?' • UX should work even with incorrect choice by user • Still, most users go through an additional click to login • Further research is ongoing ...

  16. Example Education Page

  17. (Counter) Example

  18. (Counter) Example: 2

  19. RP Integration with Google's IDP Conservative display of federated sign-in option by Plaxo.

  20. Plaxo Onboarding

  21. RP Integration with Google's IDP Bold (NASCAR type) integration via RPX

  22. RPX Integration (User returns)‏

  23. Presenting IDP Options • NASCAR interfaces perform well, but do they adapt to changing membership composition? • Ideally, sites should discover the user's IDP automatically • OpenID provides a passive login approach, not supported by all IDPs • Facebook Connect provides API to detect if the browser has a session in Facebook. An OpenID extension add this as an experimental feature. • More on this later

  24. Other considerations • Further integration with Auth APIs • Google examples: Gmail + IMAP clients, Calendar + Sync, Google Earth, Picasa uploader, ... • Full Password-less auth support to combat password harvesting • Better developer tools

  25. Security and Privacy Considerations

  26. Global or Pairwise Identity? •  User perceptions: • Machine-generated identities as pairwise • Identifying account by email only may change perspective • Varying RP needs: • Social sites want global identifiers • GSA requires pairwise identifiers • User expectation matches RP's?

  27. Discovering User Provider Preferences • Automatic provider disclosure • Privacy vs. usability trade-off • Session presence discovery • Browser-based interface • Usability challenges

  28. Additional Privacy Considerations • PII in URLs • PAPE profile • Artifact mode? Transport encryption?

  29. Assertion Trustworthiness • Non-mandatory SSL usage • PAPE profile for Government • Delegation via unsigned documents • New XRD spec provides support for signatures

  30. Surviving IDP Account Takeover • Account compromise signals • Multiple failed login attempts are useful signal. RP loses this in the federated login scenario • Credential reset capability • If RP detects malicious behavior, how to communicate issue to IDP? • How to refresh user credentials?

  31. Single Sign-off • Today: RPs may 'ping' IDP periodically to confirm presence of session • Scalability and usability issues • Single sign-on solution is complex • Usability issues are not well understood

  32. Eric Sachsesachs@google.comBreno de Medeirosbreno@google.comDirk Balfanzbalfanz@google.com Public Documentation (Google OAuth & Federated Login Research)  https://sites.google.com/site/oauthgoog/

More Related