sso—why does it suck so often?

More and more, SSO “out in the wild Internet” is seen as signing into a service with your credentials that are managed by some other company (identity provider). The less information you require to create an account (using data users have already filled out), the less drop-off you have for sign-up numbers. Building your own level of security well is difficult. Focus on what the user is expecting you to need/ask, and work with the data transparently.

[ SXSW Bios ] #sxsw #sso (Archive)

Brief

Single sign-on was a great promise: let the big identity providers handle authentication/identity, and your website gets all the benefits of a streamlined registration process for free! Anyone who has ever tried to implement it however, knows it never really works that way. In the real world, it’s a lot more messy: especially when you add in mobile, multiple providers and mixing it up with an existing account system. We’ll discuss best practices for making it work, handling the gnarly edge cases with security and identity issues, and how to make sure the user experience is as painless as possible. Panel will include platform representatives from Facebook, Twitter, and Google.

Notes

More and more, SSO “out in the wild Internet” is seen as signing into a service with your credentials that are managed by some other company (identity provider). The less information you require to create an account (using data users have already filled out), the less drop-off you have for sign-up numbers. Building your own level of security well is difficult. Focus on what the user is expecting you to need/ask, and work with the data transparently.

Key Benefits

  • Develop apps without having to build your own log-in system/security.
  • Make a pain-free sign-up/registration process for your app.
  • Get information that users have already entered instead of asking them for it again.
  • Create a more immersive experience.
  • Stop storing passwords.

Differentiators

  • Community-focused: Facebook
  • Public platform: Twitter
  • Social-neutral/enterprise: Google

 Questions

What happens when the identity provider changes their methods? Can I trust the data? Can users trust me with their data (especially since it seems that services always want access to more information on my Facebook/twitter/Google profiles than I feel they need to just set up an account)? Where is the safe line: SSO for logging in (access), account setup (authorize), and SSO for enhanced service (personalize)?

Is there a SSO aggregator service to pull from these social identity providers and merge into a single API? Is that the Browser itself? A device? OAuth? OpenID?

Enterprise is a mess (although Google can be a tool).

Identity

Some elements come along “for free” when an identity is provided to a service, but what are the best practices about how to store/retain provided identity information. But when to share identity and when not to is incredibly complex.

Permission

Users want convenience and control. So where is the sweet spot? Progressive permission (Facebook) lets a developer ask for data in small chunks when appropriate instead of scaring off users with the wealth of data a “full experience” with your app would require. When you ask for data, show the user immediately where you are using it (or perhaps don’t ask for that data at that point in time).

OpenID

Where is the promise of OpenID? The pattern now is that I pick between a few very powerful social networks and I trust them with this service. Is this a good model for the internet? Protocols like OAuth 2.0 spun out of OpenID.

Best Practices