320 likes | 421 Vues
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.
E N D
Experiences Deploying OpenID for a Broad User BaseSecurity and Usability ConsiderationsBreno de MedeirosIdentity Management 2009, September 29-30
Presentation outline • Usability research: user attitudes • Implementing lessons learned • Security considerations
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)
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
Moving Against Password Anti-Pattern • Users prize convenience • Security hard to gauge: • Client malware • Account recovery procedures • Site security • Strong passwords
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).
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.
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 ...
RP Integration with Google's IDP Conservative display of federated sign-in option by Plaxo.
RP Integration with Google's IDP Bold (NASCAR type) integration via RPX
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
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
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?
Discovering User Provider Preferences • Automatic provider disclosure • Privacy vs. usability trade-off • Session presence discovery • Browser-based interface • Usability challenges
Additional Privacy Considerations • PII in URLs • PAPE profile • Artifact mode? Transport encryption?
Assertion Trustworthiness • Non-mandatory SSL usage • PAPE profile for Government • Delegation via unsigned documents • New XRD spec provides support for signatures
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?
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
Eric Sachsesachs@google.comBreno de Medeirosbreno@google.comDirk Balfanzbalfanz@google.com Public Documentation (Google OAuth & Federated Login Research) https://sites.google.com/site/oauthgoog/