slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Presentation outline PowerPoint Presentation
Download Presentation
Presentation outline

Loading in 2 Seconds...

play fullscreen
1 / 32

Presentation outline - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Presentation outline' - elton-fulton

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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
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 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
Moving Against Password Anti-Pattern
  • Users prize convenience
  • Security hard to gauge:
    • Client malware
    • Account recovery procedures
    • Site security
    • Strong passwords
user attitudes consequences
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
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.
  • 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
RP Integration with Google's IDP

Conservative display of federated sign-in option by Plaxo.

rp integration with google s idp1
RP Integration with Google's IDP

Bold (NASCAR type) integration via RPX

presenting idp options
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
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
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
Discovering User Provider Preferences
  • Automatic provider disclosure
    • Privacy vs. usability trade-off
  • Session presence discovery
  • Browser-based interface
    • Usability challenges
additional privacy considerations
Additional Privacy Considerations
  • PII in URLs
      • PAPE profile
      • Artifact mode? Transport encryption?
assertion trustworthiness
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
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
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 esachs@google com breno de medeiros breno@google com dirk balfanz balfanz@google com
Eric Sachsesachs@google.comBreno de Medeirosbreno@google.comDirk

Public Documentation (Google OAuth & Federated Login Research)