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

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. 

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. 

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

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. 

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

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. 

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. 

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

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

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. 

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. 

13 Do you know this man? 

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. 

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

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. 

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. 

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

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

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

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. 

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. 

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. 

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

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. 

26 Social Login 

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. 

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. 

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

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. 

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 

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. 

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. 

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 

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

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. 

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. 

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+. 

39 Consequences Of Service Authorisation 

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

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. 

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. 

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. 

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. 

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. 

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

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. 

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. 

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

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. 

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. 

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. 

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. 

54