[MUSIC PLAYING]
CHRIS CARTLAND: Welcome to 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
developers.google.com/+.
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 Sign-In 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 developers.google.com/+ 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]