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

Before We Begin: Some Terminology This talk covers technologies for authentication, identification, as well as authorization/delegation. o 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: o Identity Provider (IDP): Emphasis on identify/authenticate o Service Provider (SP): Emphasis on authorize/delegate A site integrating with such an API is a Consumer or Relying Party (RP)‏

User Attitudes

Build It and They Will Come...

User Attitudes: Password Sharing

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

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

User Attitudes: Consequences Users likely to share passwords with sites they trust o 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: o Provider should define rich authorization/delegation APIs o Provider should deploy smooth user experience Otherwise, companies likely to be first-adopters of identity solutions are also least likely to benefit (market failure).

Deployment Experiences

Federated Login with Legacy Accounts Relying Parties typically also support legacy login o 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.

Login Box Transmutation

Login Box Transmutation (2)‏

Login Box Transmutation (3)‏

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

Example Education Page

(Counter) Example

(Counter) Example: 2

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

Plaxo Onboarding

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

RPX Integration (User returns)‏

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

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

Security and Privacy Considerations

Global or Pairwise Identity? User perceptions: o Machine-generated identities as pairwise o Identifying account by only may change perspective Varying RP needs: o Social sites want global identifiers o GSA requires pairwise identifiers o 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 o PAPE profile o Artifact mode? Transport encryption?

Assertion Trustworthiness Non-mandatory SSL usage o PAPE profile for Government Delegation via unsigned documents o 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 Sachs Breno de Medeiros Dirk Balfanz Public Documentation (Google OAuth & Federated Login Research)