10 themes in social login

This started as "N things you didn’t know you could do with Google+ Sign-in" It's my talk from Over The Air 2013 about the evolution of social login and the ways in which we're propagating identity across and between devices, browsers, apps and services. #ota13

Transcript

1. 10 themes in social
   login
   Social login (including Google+ Sign-in) is starting to exhibit common themes
   

   View Slide

2. 2
   www.oshineye.com/+
   I’m Ade Oshineye and I can usually be found on Google+ or behind a camera.
   I’ll be your Google+ Developer Advocate for the next 45 minutes.
   

   View Slide

3. N things you didn’t know you
   could do with Google+ Sign-in
   Ade Oshineye
   Senior Developer Advocate
   I was originally going to approach this topic by listing interesting uses of Google+ sign-in but I’ve decided to
   approach it conceptually instead.
   

   View Slide

4. 10 themes in social
   login
   Social login (including Google+ Sign-in) is starting to exhibit common themes
   

   View Slide

5. 5
   Ian Barber
   This is Ian Barber. He gave a talk earlier today that was the practical introduction to social login. This talk is a
   conceptual overview.
   

   View Slide

6. 6
   Identity Matters More On Mobile
   Mobiles are the personal devices we have
   It’s harder to input usernames/passwords on them
   

   View Slide

7. 7
   More dead-ends
   Embedded web-views are death for user journeys (since they tend to have an empty cookie jar and no notion of the
   user’s identity) but they’re prevalent on mobile devices.
   If you’re particularly unlucky then users won’t be able to create accounts on mobile.
   If they’re mobile-only users then your app just got uninstalled.
   

   View Slide

8. 8
   More contexts
   Offline is a context that’s especially important on mobile. It’s very easy to create situations where the user needs to
   be online in order to get information that’s most useful to them offline...such as the password for the wifi network.
   

   View Slide

9. 9
   More options
   Real-world interaction with mainstream users means that in some cases PINs are better than typing in a username/
   password
   

   View Slide

10. 10
    Device Authentication
    Touch ID, Moto X Bluetooth unlocking and Face ID are all examples of authentication at the device level.
    

    View Slide

11. 11
    Operating System Authentication
    Chrome OS is just the latest in a line of operating systems that require the user’s identity.
    The difference is that Chrome OS propagates that identity into the Cloud.
    

    View Slide

12. 12
    Browser Authentication
    If you’re using Chrome then you’re increasingly likely to be signed-in to your browser in order to benefit from
    features like Tab and Password sync. It’s looking like this is going to become a standard part of every browser.
    

    View Slide

13. 13
    Do you know this man?
    

    View Slide

14. 14
    Paul “WebIntents” Kinlan
    Paul worked on WebIntents: an attempt to bring Android-style intents to the web. Sadly that work hasn’t gained
    traction.
    

    View Slide

15. 15
    Intents in more places
    At the same time Android intents are growing ever-more powerful and useful.
    

    View Slide

16. 16
    Browsers are going native
    Web apps are starting to hook into native apps that comprise the same service. The web apps are deeplinking into
    their native apps and the native apps are using x-callback-url to talk to other apps which includes the web browser.
    

    View Slide

17. 17
    Native apps are absorbing the web
    Native apps like Soundcloud and Instapaper are using the pasteboard on iOS to offer crude inter-app linking which
    triggers when the user just copies a link that matches their domain.
    

    View Slide

18. 18
    Identity Propagation
    Identity can flow device to operating system to apps to other apps including browsers and from there into the web.
    

    View Slide

19. 19
    Life without identity propagation
    Yet another embedded webview where the user is going to be asked to enter username and password.
    

    View Slide

20. 20
    Life without identity propagation
    These dead-ends become even more expensive as more users adopt 2-factor authentication.
    

    View Slide

21. 21
    0th-party identity propagation
    Google is still working on propagating identity between its own services. Try going to google.com then google.ca and
    you’ll see that (unless you’re Canadian) that, as of September 2013, your identity doesn’t propagate between all
    Google domains. This is work that has to be done for all domains and all services to ensure users get a unified
    Google experience.
    

    View Slide

22. 22
    1st-party identity propagation
    In this example we see identity propagating from Chrome to a Google web-app. The user is signed-in to the browser
    but not to the web app so the browser is offering to solve this problem by propagating identity rather than autofilling
    the password field.
    

    View Slide

23. 23
    iOS apps & shared keychains
    More and more of Google’s apps are using shared keychains on iOS so that users of our 21 different iOS apps don’t
    have to sign-in 21 times. Facebook does the same thing with Facebook, Messenger, Poke and Camera.
    

    View Slide

24. 24
    Minimum Viable IDP
    The identity provider market has become increasingly competitive
    

    View Slide

25. 25
    1 Valuable accounts (SMS verification, anti-spam, etc)
    2 Security (salting, hashing, multiple factors, etc)
    3 Rich profiles (photo, social/interest graph, etc)
    4 Ubiquitous APIs (web, native, client libraries, languages, RTL, etc)
    5 Escape hatches (disconnect, email address, etc)
    6 Business model (what’s in it for the IDP? why will they stick around?)
    Minimum viable IDP
    Since the launch of Google+ Sign-in we’ve learned a lot about what Relying Parties (RPs) and users demand before
    they’ll consider adopting an IDP. These are the features that are necessary but not sufficient for an IDP to be
    competitive. Points 1 and 3 imply that the IDP has to have lots of the right users for the RP.
    

    View Slide

26. 26
    Social Login
    

    View Slide

27. 27
    Social login has crossed the chasm
    If you know Geoffrey Moore’s Crossing The Chasm then you’ll know that the BBC are on the other side of the chasm.
    Social login is now the safe and mainstream option.
    

    View Slide

28. 28
    Multi-sided market: technologies
    This is as good as the traditional NASCAR gets. Social login is a multi-sided market where success comes from
    satisfying the needs of IDPs, RPs and users.
    

    View Slide

29. 29
    Multi-sided market: IDPs
    There are more viable IDPs than you think.
    

    View Slide

30. 30
    Multi-sided market: IDPs
    Becoming your own IDP is still a viable option in a niche but you have to be aware that you’re likely to be the IDP of
    last resort.
    

    View Slide

31. 31
    Multi-sided market: niches
    Codes work: WhatsApp has 250 million 30DAU
    Phone numbers fail (they’re not cross-platform and don’t work well internationally) unless they augment an existing
    IDP
    

    View Slide

32. 32
    Red Queen hypothesis
    IDPs have to keep finding ways to give more value to RPs and users just to stay at their current level of
    competitiveness. RPs (like Magisto which combines Youtube and Drive) can build new kinds of services with the data
    they obtain from the IDP.
    

    View Slide

33. 33
    Loyalty scheme based on Youtube APIs
    RPs can do interesting things with APIs that are unlocked by an IDP. In this case Warner Bros France uses Google+
    Sign-in and Youtube’s V3 APIs to build a loyalty scheme that for those who watch certain Youtube videos.
    

    View Slide

34. 34
    Explaining what you’ll do
    RPs can also innovate in the ways they present the sign-in experience and explain what they’re going to do with the
    access they obtain
    

    View Slide

35. 35
    Service Authorisation
    We’re moving away from the model where the user authorises a single app on a single platform
    

    View Slide

36. 36
    Connect on all devices and platforms
    When I authorise Soundcloud or Deezer in one place I do it in all the touchpoints they have with me now and in the
    future. If I get a new device at Christmas I can sign-in to Google and visit Soundcloud or Deezer and be automatically
    authenticated.
    

    View Slide

37. 37
    Web to Android installs and SSO
    Features like Interactive Posts build on top of deep-links to create cross-platform buttons that install apps (on iOS
    and Android), take the user through a sign-in flow and then take the user to the desired context.
    

    View Slide

38. 38
    Uniformity and stranded users
    If you use social login then it’s important that you use it consistently everywhere or you’ll strand users when they
    arrive at a platform where you aren’t yet using a particular IDP. In this case I’m unable to sign-in on iOS since I can’t
    be sure that Soundwave won’t create a brand new account if I sign-in with Facebook rather than Google+.
    

    View Slide

39. 39
    Consequences Of Service
    Authorisation
    

    View Slide

40. 40
    Google+ Platform
    Platforms have to reach across devices and ecosystems
    

    View Slide

41. 41
    Youtube and content creators
    The end-user features of your product have to nudge the user to do things that will work well across platforms and
    devices. Youtube nudges you to use a cover image that works well in multiple contexts.
    

    View Slide

42. 42
    Consequences
    Cross-platform versus multi-platform
    The same user is likely to be using your app on multiple platforms at the same time. This is different to just porting
    your app to different platforms. Now they have to interoperate as part of the same user journey.
    

    View Slide

43. 43
    Consequences
    Cross-device versus multi-device
    The same user is likely to be using your app on multiple devices at the same time. Now you have to think about the
    different devices can cooperate to help the user achieve their goals.
    

    View Slide

44. 44
    Consequences
    Cross-app versus multi-app
    The same user is likely to be using multiple apps from your company or service. You’ll have to think about how user
    journeys can span those apps and what to do if the underlying platforms don’t offer sufficiently primitives to do what
    you need.
    

    View Slide

45. 45
    Consequences
    Web or Native
    versus
    Web and Native
    The Web or Native argument is obsolete. Today you have to do both and both have to work together to help the user
    achieve their goals.
    

    View Slide

46. 46
    Games Are The Pioneers
    If you want to see the feature then start playing games
    

    View Slide

47. 47
    Games before Play Games
    Before Google Play Games it was possible to build cross-device and cross-platform games but you had to do
    awkward things like generate codes and pass them between devices. We’re going to be moving to a world where your
    identity (via social login) is going to be your ticket into any game on any device or platform.
    

    View Slide

48. 48
    Play Services and Play Games
    Google Play Services: on roughly a billion Android devices. Rolls out every few months and new functionality hits
    100% of devices in a matter of weeks. Google+ Sign-in is part of it.
    Google Play Games is also part of it.
    

    View Slide

49. 49
    Let’s Play
    It uses the standard OAuth2/OpenIDConnect flow you’ve seen everywhere else but with new scopes for games.
    

    View Slide

50. 50
    The achievement cycle
    You start a game, sign, play, share to your social/interest graph and even if you’re a bad player you can still get
    achievements. In this example I got the Are You Even Trying Achievement for scoring 0. The resulting post : https://
    plus.google.com/105037104815911535953/posts/F9mGGfXqZBc triggered a conversation that got several other
    people to play the game.
    

    View Slide

51. 51
    Games are intrinsically social
    Games don’t need to gamified. Without social login the high-score table is just your name repeated. With social login
    it becomes possible to compare myself to people I know and that makes the game more engaging.
    

    View Slide

52. 52
    Let’s Play Everywhere
    Jewels2 is an iOS game that uses Google Play Games and Apple’s Game Center because users want to play with all
    their friends not just their friends who have the same device or chose the same gaming network. That’s why Play
    Games works on Android, iOS and Web as well as exposing ReSTful APIs that let you use it anywhere you can make an
    HTTP call.
    

    View Slide

53. 53
    Where are we going?
    In the past a group of people could sit around a table and play a game without needing to make sure they were all
    using the same device, platform and browser. Hopefully in the future we’ll be able to get back to that even if we’re
    not all physically at the same table.
    

    View Slide

54. View Slide