Google+ Developers Live: Cross-Platform Single Sign-On
Articles Blog

Google+ Developers Live: Cross-Platform Single Sign-On

Google+ Developers Live. My name is Chris Cartland, and
I’m a developer programs engineer working on the
Google+ platform. YANIV YAAKUBOVICH: And I’m
Yaniv Yaakubovich. I’m a product manager on
the Google+ platform. LEE DENISON: And I’m Lee. I’m also a developer programs
engineer on the Google+ platform in London. CHRIS CARTLAND: Yeah, thanks
for joining us via Hangouts all the way from London. Today is really exciting. We’re going to talk about
Cross-Platform Single Sign-On, which is something you may have
seen demonstrated in the I/O keynote this year. It’s a really cool feature. We’re going to first talk about
what it is, and then we’re going to actually show you
the code and how that fits into our sample application,
PhotoHunt. And we will show you all the
details of how to make sure that you’re doing right, and
you can do this in your application. So this is really exciting. First of all, Yaniv, can you
tell us a little more about what Cross-Platform Single
Sign-On really is? YANIV YAAKUBOVICH: Sure. We recognize that users don’t
just use one device to interact with your app. They switch between laptops,
tablet, and mobile devices on a daily basis. And we’re focused on making
desktop and mobile work better together so user will
have a seamless experience between platforms. With that, we’ve taken another
step in this direction, and we’re introducing the
Cross-Platform Single Sign-On, or as we call it, SSO. Cross-Platform SSO lets you
connect to users and more easily keep them engaged across
devices, removing all the frictions of consent
and authentication. Now, a user connects on one
device, and seamlessly, they’re connected to
any other device. Let’s look, for example, on the
case of a user that logs in to your web app to start
adding items to their shopping cart. But this user is actually not
completing the transaction, doesn’t check out. If this user already signed in
with Google+, when using our Cross-Platform Single Sign-On,
when they go to your web application, they automatically
sign in to Google without the need
to consent again or to authorize anything. And all of the data is available
for them to use, and they can check out from exactly
the same place that they were before in
your website. CHRIS CARTLAND: That’s
really great. So that would mean that they
could actually buy something more quickly with less friction
in that app– YANIV YAAKUBOVICH: Exactly CHRIS CARTLAND: –make
it easier to do what they want to do. That’s great. So yeah, I’d actually love to
see how this actually works. So if we can– Lee, I think you can
help us out here. First, can you explain a
little bit about what PhotoHunt is? And then once you’ve done that,
we can go into actually the code and how PhotoHunt’s
working to do this. LEE DENISON: Yeah, sure. So PhotoHunt is a sampler which
demonstrates the Google+ APIs on Android, iOS,
and the web. It’s a game. It’s a photo scavenger hunt
where players capture photos with their mobile devices
and cameras. And they submit them
to a daily feed. And then other players can vote
on their photos to find out which one is the best one. But more than our other sampler
applications, it’s really close to a real-world
implementation. So it is much closer to helping
you understand what the real world issues you might
face when you try and implement social login
in your app. So for example, it implements a
client-server architecture. So if you’ve done that in your
own app, then it’ll give you an idea of how to do that. It has both a signed-out and
a signed-in experience. So if you’re planning to do that
in your app, then you can see how that works. And also, it doesn’t a more
real-world kind of error handling flow as well,
particularly on the server side is a good way to
see how that works. So it has a server component,
which is implemented in Java. And we’re planning to add more
languages in the future. And it has client
implementations in JavaScript for the web and on iOS
and on Android. These are all available
on GitHub. And also, the documentation
is available on So if we take a look at the
architecture that you get when you set up a PhotoHunt instance,
then you can see that we get an Android client
and a JavaScript client. And each of them authenticate
independently with the Google+ APIs using Google+ sign-in. And so they can each make direct
calls to the Google APIs in their own right. And they can do things like
get the user’s profile information and get their social
graph and all the good things that you want to do. They also authenticate with
the PhotoHunt server. But that is a completely
PhotoHunt-specific API. So that’s nothing to
do with Google. It’s a PhotoHunt-specific API. But during that process, they
will pass over Google credentials, which the PhotoHunt
server can then use to also make calls to
the Google APIs on behalf of the user. So if you’re writing moments
server side or if you’re getting the social graphs server
side to contribute there, then you can
also do that. CHRIS CARTLAND: Yeah, so for
this application, users are going to authenticate either on
Android or on the web, and possibly two different places,
they may have to see a consent dialogue. And then that information gets
passed to the server, and then the server does all the
actual API calls to Google, or most of them. LEE DENISON: Right. Exactly. So for Single Sign-On, what
we’re really interested in is that conversation that goes on
between the clients and Google rather than the server
and Google. So let’s focus on that. When a user signs in with a
Google+ Sign-In, then it’s important that Google– if it’s for the very first time
for your service, then Google needs to show a consent
dialogue, which explains to the user the permissions that
your app is requesting to be able to access the Google
APIs and their data on their behalf. So that consent dialogue is
displayed natively as part of Google Play Services on Android
and is displayed as part of the sign-in
flow on the web. But with Google+ Sign-In, when
you consent to those permissions for a given app,
you do that to the project, regardless of what platform you
happen to be accessing on, which is great news for
the developers. So it means Android is
used for the user. So it means that if I sign in
for the first time on Android for this app, then I’ll
see the native consent dialogue there. But then if I subsequently
access the same service via the web, I won’t have
to consent again. And the same thing happens vice
versa, if you sign in first on the web. So that creates a seamless
experience for the user on Android because the
user has already authenticated to the device. So that means that they
don’t have to type in their user name. They don’t have to type
in their password. And because if they’ve signed
in already on the web, and they don’t even see the consent
dialogue, that means that they’re dropped straight
to a signed-in experience in your app without having to
click a single button. You get the personalized
experience. And also, as Yaniv said, if they
started anything on the web, that state will be
available to them immediately in the app. YANIV YAAKUBOVICH: And
this goes both ways. LEE DENISON: Yeah, and
it goes both ways. So if the user’s already signed
in for the first time on Android, in a browser, if
that’s their browser at home, they’re likely to be already
signed in to Google. And that means that when they
access the service in a web browser, and the Sign-In button
is displayed, it will attempt an immediate mobile
authentication. And because they’ve already
consented on Android, that will go ahead. And again, they’ll be signed in
without having to click a single button. And they get all the benefits
that way, as well. CHRIS CARTLAND: That’s
really great. And it’s a really neat thing
that we’re able to bring this together on Android and
the web and make those two more seamless. LEE DENISON: Yeah. Now, the great news for
developers is that you don’t need to make any special
changes. You don’t have to do anything
special in your app to actually implement
Single Sign-On. It’s taken care of for you. What I’m going to do is take
us through the Android code for PhotoHunt and explain what’s
going on behind the scenes to make Single
Sign-On happen. So in Android, as we know, this
is handled by the PlusClient, which
is our interface to Google Play Services. And typically, what we do is
we would tie our PlusClient life cycle to the life cycle
of our activity. Now, in PhotoHunt, because you
typically want the same Sign-In logic for every
activity, what you’re going to do is probably either implement
a base activity to collect that reusable
functionality together, or what we’ve done in PhotoHunt
is actually put it in a reusable fragment. So let’s take a look at
PlusClient fragment. So like I say, this ties the
PlusClient’s life cycle to the life cycle of the activity. So we can see that in the
onCreate method of this PlusClient fragment, we
initialize our PlusClient. And then we call connect. We use the PlusClient Builder
to create the PlusClient. And what we do here is we set
the scopes, which represent the permissions that your app
is asking of the user. And we also set the visible
actions, which is the app activities that your app
would like to write. Now, it’s really important
that the scopes and the activities that you set are the
same across all platforms. All the platforms that you
implement need to match, because if you ask for different
scopes on different platforms, then when you log
in on the web, say, after you’ve already logged in on
Android and you’re asking for different scopes, Google will
have to ask the user for their consent to them, because you’re
asking for a different set of permissions. So if you want SSO to work, you
really need to make sure that those scopes match across
all the platforms that you implement on. CHRIS CARTLAND: So like you said
before, you’re not really doing anything new to implement
Single Sign-On. We’re just checking to make sure
that you have things set up correctly so that right now
on this screen, we can see the setVisibleActivities
and setScopes. And those need to be the same
on Android and the web and across all your platforms. LEE DENISON: Yeah. So of course, when you’re
implementing on multiple platforms, you don’t get to
define that ahead of somewhere where you can use
it everywhere. It’s really a developer job. You’ve got to make sure that
those are the same across lots of different platforms. So yeah. So at the end of that onCreate
method, we call connect, just as we would regardless of Single
Sign-On And that does two things. It will attempt Sign-On
immediately, and it will attempt to fetch the sign-in
state of the user. And to do that, it needs a
connection to Google Play Services, which is the other
thing you would set up. And that call is asynchronous
and will ultimately come back to onConnected if the user has
approved their app anywhere, on any platform. And we’ve got a successful
connection to Google Play Services, then that’ll come
back in onConnected. And if it fails for some reason,
then it will come back in onConnectionFailed. So that’s no different
for Single Sign-On. So PlusClient, of course,
integrates with the Android Account Manager. And that means that it already
knows about the Google accounts on the device and
also whether they are authenticated in terms
of typing in user name and password. So all that we need to do is
decide which account we need to use and whether or not that
account has approved our app. Now, that gives us several
possible states that we can be in. So you can see here that
if the user has not– if none of the accounts on the
device have approved our app, then we’re going to get onConnectionFailed regardless, right? That might mean if they also
haven’t chosen the account, then we might show them
the Account Chooser. But whatever else happens, we’re
going to have to show them the consent dialogue. So that’s fine. That’s what users
would expect. But if they’ve authorized our
app on any platform, on the web or Android, then we can see
on the left-hand side that we’ve got a number of
options open to us. So in the common case, in the
case where there’s only one Google account on the device,
then that would be chosen. It would be the default
account for the app. And they would get authorized
immediately. And the next thing that happens
is that onConnected is called, and our app drops
into its signed-in state, which is great. If the user does actually have
more than one Google account on the device, then it gets a
little bit more complicated. But it’s still handled. So here, what happens is if
exactly one of those accounts has authed our app, then again,
we’ll get the Single Sign-On experience. It will choose that account
as the default account. And then we’ll get you on to
onConnected, which is great. If more than one of those
accounts has authorized our app, then we don’t know which
one the user needs to pick. So we have to at least
show them a chooser. We won’t show them a consent
dialogue once they pick, but we have to show them
the chooser. So either way, that’s
a pretty seamless experience for the user. CHRIS CARTLAND: Yeah, and
clearly, there is the case where you’ve never authorized. So you haven’t even signed on
once with the app, so you can’t do Single Sign-On
in that case. LEE DENISON: Exactly. So if you’ve never signed in,
and you are, then you’re going to get the onConnectionFailed
regardless. CHRIS CARTLAND: But once you’ve
done it once, you end up in the left column. And then it’s really just a
matter of whether the user has multiple accounts
on that device. And Google tries to make a good
decision, but sometimes you have to let the
user choose. LEE DENISON: And actually,
the same thing happens on the web as well. So if the user is signed into
their browser with multiple Google accounts, then they’ll
get an Account Chooser there as well. So the logic is the same
across all platforms. We handle that case with
multiple accounts, but the common case is one account,
and there it is. So the last thing I wanted
to talk about was when the user signs out. So here, if you’ve implemented
sign-in before, you know that what we do in sign-out is we
clear the default account. And that forces the Account
Chooser to appear when they sign in a second time. Now, Google Play Services
remembers whether or not for this app we have carried out
the Single Sign-On flow. So what you’d expect is that
when the user signs out, they’ll see that account user,
regardless of whether the Single Sign-On flow would’ve
caused one of them to be signed in. And that still works. So you have to remember
that Google Play Services remembers that. And particularly if you’re
debugging, it’s a good idea when you want to test Single
Sign-On to go in and clear the state in Google Play Services. So that will force the Single
Sign-On flow to happen again for the app. So yeah, that really
creates a seamless experience for the user. You, as a developer, are doing
exactly what you would have done before. You’re implementing onConnected
to be your signed-in experience. You’re implementing
onConnectionFailed to be your signed-out experience. And you really do exactly the
same, and Google Play Services takes care of everything
else for you. If the user is signed in as a
result of Single Sign-On, they will get that toast message to
say, welcome back to the app. And so they’re not surprised
by the fact that they’re signed in. But from your app’s perspective,
it just works exactly the same. So that’s all I have to
say about the Android implementation. Cartland, do you want to take
us through the JavaScript implementation? CHRIS CARTLAND: Yeah, great. Yeah, I’m going to briefly look
at the JavaScript for PhotoHunt as well. Oh, I guess we forgot to talk
a little bit about the onConnectionFailed. That is the same thing that
you would have had before. And that will help to get the
user through the rare case where they have multiple apps
that have authorized. LEE DENISON: Yeah. CHRIS CARTLAND: Great. So now, yeah, moving on
to the JavaScript. The first thing that you need
to make sure you’ve set up right is the Sign-In button,
which in PhotoHunt is done through gapi.signin.render. We have several fields
that we configure with the Sign-In button. And the ones I really want to
call out are the request visible actions and
the scopes. We want to make sure that those
are the same as the ones that Lee talked about in
Android, because, of course, if you have different scopes,
different permissions, we’re going to have to ask users
for the new permissions. But once we’ve set those up,
this is, again, the same Sign-In button that we had
before Single Sign-On existed. And the user will click
on that and authorize. If they authorized either now
on the web or in the Android flow that Lee just described,
then the callback will be fired with the authentication
and authorization information that you need. So this really has, actually,
no change at this point. PhotoHunt takes care of knowing
who the user is and then being the app, which
is really the key here. We’re trying to do all this work
so that as a developer and as a user, you can just
get to using the app. You don’t want to spend time
signing in and doing all the other work. You just want to get to
PhotoHunt where you can actually deal with stuff. So that’s the stuff there. YANIV YAAKUBOVICH: If you have
any more questions, we’re welcome to answer them on the
Stack Overflow account. Just use Google+ as your tag. You can also see all of those
examples that we discussed today on
or on our community on Google+
for developers. CHRIS CARTLAND: Yeah, great. So thank you so much for
joining us today. And thank you so much, Lee, for
staying up late in London to help us out with this. LEE DENISON: Welcome. CHRIS CARTLAND: And thank you,
everyone, for watching. We’ll see you next week. [MUSIC PLAYING]

One thought on “Google+ Developers Live: Cross-Platform Single Sign-On

  1. +Yaniv Yaakubovich +Lee Denison, +Chris Cartland

    I'm having problems implementing this. 
    The first call to PlusClient#connect() will always result in a connectionFailed if the execution comes from a fresh install.

    Even if the google account signed in another device with identical scope and permissions set, I will never get an immediate signin.

    I elaborated the question in:

    Could you help?

    Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top