Tip:
Highlight text to annotate it
X
JOANNA SMITH: Hey, everybody, and welcome to "Google+
Developers Live--
Come Auth with Us." I'm Joanna Smith, and I'm a developer
programs engineer for Google+.
SILVANO LUCIANI: And I'm Silvano Luciani, and I'm as
well a developer programs engineer on Google+.
And this week, we are exceptionally coming to you
from our studio in New York City, where we are for our
Google+ Sign-In boot camps.
JOANNA SMITH: We're very excited to be on our global
tour for these Sign-In boot camps, but even more exciting
is that today we actually get to have our special guest with
us live, breathing here in the room, and not by Hangout.
So everyone please welcome our Google+ developer expert Allen
Firstenberg.
ALLEN FIRSTENBERG: Hi, Joanna.
It's great to be here.
Thank you very much.
It's great to see you guys in the New York office.
Glad to see you over on this side of the country.
And I'm Allen Firstenberg, I'm a Google
developer expert with Google+.
And I'm glad to be helping out on today's show.
JOANNA SMITH: Fantastic.
So last week we showed you how easy it is to add Google+
Sign-In to your website using JavaScript.
And basically what you can do is by adding Google+ Sign-In,
you bring the power of Google to your site.
And when a user is signed in, you get this OAuth token so
that you can make calls on their behalf to the API while
they're active in your site.
But that's when you're using client-side.
But there's more to it, and to better understand your user
and what's right for you, we're going to go over the
different possible flows for authentication.
So there's three of them, right?
SILVANO LUCIANI: Yes, Joanna.
Spot on.
We have three different options, and today we are
going to do a work through of all the
three different options.
And we will use different tools.
We will use a sample-- it's a very small sample--
we will use the Google OAuth 2.0 Playground, and we will
show you some of the source code from one of our
quick-starts--
the PHP quick-starts.
JOANNA SMITH: So what do you think, Allen?
How's that sound?
ALLEN FIRSTENBERG: I think it sounds good.
I think one of the important things that people should take
away from this is that what we're covering today isn't
just applicable to Google+ Sign-In, it's applicable to
everything across the board of all of Google's APIs.
So if you understand the OAuth flow from this, you'll be able
to apply it in a wide variety of other tools that are
available from Google.
JOANNA SMITH: That's a really good point.
Thank you.
Sometimes it's hard for us to remember that for developers
there's more than just our API.
So it's good to have reminders of that.
So let's get started with the client-side flow.
And this is what we showed you guys last week in particular.
And when you're using our Google+ Sign-In button, you
basically get this flow for free.
And it's really simple and straightforward.
But the key to remember is that when you're using
client-side authentication, you're able to get an access
token that allows you to make calls on behalf of the user
while they are active in your app.
And that's the key piece-- as long as they're in your app,
you're good to go.
SILVANO LUCIANI: So we can show an example.
It's our big red Sign-In button.
We showed you last week how to place it in your web page and
how to integrate it in your website.
What we want to show you this week is what
is the OAuth result.
What is the object that it's returned after--
when the Sign-In call back is called after
a successful login.
So when I click Sign-In, in this case we are seeing our
familiar content dialogue.
It's full screen.
It went already to that page because I'm full
screen on my monitor.
When I click Accept, I'm back to my app.
And what I'm doing in this sample is just dumping the
content of the object that is returned to our call back.
That's a lot of stuff, as you can see in there.
But I want to focus on just two values.
The first one I want to focus on is the access token.
So this one.
And as you can see, this is what the client library will
use to sign the request that you do to our API.
This token will be valid for one hour.
When you use this flow, what happens is that we have a
Sign-in mode that is called Immediate Mode, which means
that if you already gave content--
if the user has already given content to your app--
when the user will be back.
If their access token has expired, we will go to an
automatic flow.
We will give you another access token, and then you
will be able to start again making requests to the Google+
API, or any other API, as Allen pointed.
The second thing I want to show you is the code.
So this code, remember about this because we will see this
in a while in the other two flows that we
will present to you.
ALLEN FIRSTENBERG: So I think one of the important things to
understand about when you're going to be using this sort of
thing is primarily when you're working with the JavaScript
libraries, and you're restricting all of your access
from the client where you want to be displaying things from
JavaScript, controlling things from JavaScript, and you're
essentially going to be letting the user connect
directly from the page that's presented back to Google's
servers and contacting the Google servers for that data.
So I think this is where you're going to be seeing the
most use for this particular flow.
SILVANO LUCIANI: True.
JOANNA SMITH: So Allen, you use client-side a lot, right?
ALLEN FIRSTENBERG: It's primarily most of what I do
these days is I tend to create a lot of JavaScript mock-ups
and keep all of the work inside JavaScript itself,
bothering my server as little as possible.
JOANNA SMITH: And do you do that because it's simpler or
faster, or is it just your favorite?
ALLEN FIRSTENBERG: It depends.
It really depends on the project that I'm working on at
any given time.
So most of the work that I'm doing these days pretty much
is staying within the client-side.
There is no need to talk to my server.
My server doesn't need to get a lot of information, doesn't
need to control a lot of what the user is doing.
I just want the user to be communicating with Google as
much as possible, as directly as possible.
JOANNA SMITH: That makes sense.
ALLEN FIRSTENBERG: And
communicating with me far less.
JOANNA SMITH: OK.
That makes a lot of sense.
And so that was client-side, which you've now
seen several times.
But the second flow we wanted to talk to you about is the
server-side flow for web server applications.
And these may access a Google API while the user is present
in the application or after the user has left.
And that's what's really beneficial about the
server-side flow is that you get this additional refresh
token, and so you have the ability to [? meet ?]
somewhere else.
But it requires that the server is able to keep a
secret, and that's what's really key here.
SILVANO LUCIANI: Yeah, keeping the client's secret secret.
A non-secret client's secret doesn't sound very good.
To show you some of the details, we are going to use
this wonderful tool, which is the OAuth 2.0 Playground,
which will allow you to inspect all the different
steps of the different OAuth flows.
And by using this gear, you can configure the type of
OAuth flow that you want to inspect.
JOANNA SMITH: [INAUDIBLE].
SILVANO LUCIANI: In this case, it will be the
server-side for us.
And the thing that we want to show to you is how you will
get the refresh token.
And the refresh token is a long-lived token.
It will actually never expire until the user revokes the
token or disconnects your app.
And what you can do with the refresh token is request a new
access token when the access token that you're using has
expired, which means after one hour.
So in the first step, we are asked to select and
authorize an API.
And given that our + API is way down the list, I already
added the scope.
But this shows you that you can actually try this with
your own custom scopes.
So when I click Authorize API, I'm redirected to the full
screen authorization server.
In this case, it's important to understand that for the
server-side flow this will always happen.
And that's the reason why when you configure this type of
flow, you will also need the redirect URI.
Because after this redirect to the Google authorization
server, the Google authorization server will
redirect back the user to your app, to the redirect URI that
you have specified in the configuration of the project
on the API consult.
And after I click Accept, in this case, we go back to the
OAuth Playground with this because that's what is
configured as redirect URI for this project.
Now if you can see, in the URL it's not very big, but the
last part is a code which is similar to the code that I was
showing to you before returned by the Sign-In button.
We can use this code to make an exchange with the Google
authorization server and get back a new pair of an access
token and the refresh token.
The code is here as well, and it's more visible.
And I can do the exchange by clicking
this big blue button--
Exchange Authorization Code.
When I do it, if you want you can analyze on the right side
what the request was and what the response is.
But the most important thing is that I got this pair--
access token and refresh token.
Now, it's important to understand that you will get
the refresh token only once and only after the user has
given consent to your application.
So given that you are doing these because you want offline
access to the user data, you need to store it along with
the user data in your database or wherever you store data for
your application and don't lose it.
If you lose it for any reason, you can force the user to
reauthenticate using the approval prompt parameter and
setting it to false, but this will cause the consent
dialogue to be displayed again to the user,
which could be confusing.
Now, I can use the List Possible Operations to get all
the operations that the Google+ API, which is the one
that we authorized in this demo, available.
The other thing that I can do is go back to step two.
Let me close this.
Go back to the second step.
And there's another gray button, which is Refresh
Access Token.
And if I click it, you can see what happens when you want to
actually use a refresh token to get a new access token that
will last another hour.
ALLEN FIRSTENBERG: And I think one of the things that's
important to understand about this is when you would use
this over the client-side one.
And primarily I use this the most under one of two
circumstances.
The first is when what I'm doing on the client-side isn't
very much related to what's going on with Google itself.
So if my client is almost exclusively talking to my
server, or if I'm getting some static information back from
the server, this is when I would be doing it.
My server's doing all of the heavy lifting.
The other case when it's doing it is when I don't have a
client at all.
When basically I need my server to be able to do things
on my behalf.
So looking outside Google+, for example, I might be
wanting to write something into a spreadsheet that's in
Google Drive.
Or I might want to be creating Google Drive documents for me
to look at later.
Or using the new API, I might be wanting to create new
moments and have those moments show up as part
of my Google+ history.
These are cases where there's no direct client interaction,
so the server needs that refresh token and needs to be
able to use that refresh token at any time.
JOANNA SMITH: That's true.
And the other thing is, this OAuth Playground has been
available on our documentation, and it's a
really great resource for you to follow the flow.
So if you're ever a little confused about OAuth and its
complexities, definitely take a moment to really step
through and see everything that happens at each stage,
because this is honestly how I learned OAuth when I first
started at Google, and I think it'll be really
good for you too.
SILVANO LUCIANI: Same for me.
JOANNA SMITH: [LAUGHS]
And so the third flow we wanted to talk to you about is
what we call the one time code flow.
And it uses this same authorization code to exchange
to the server to get that access and refresh token back.
But what's really key here is that you can actually receive
the code on the client like we saw earlier, and you can pass
that code securely to your server in order to do the
exchange for the token so that you don't have to pass a user
authentication token around, which could
be unsafe or insecure.
SILVANO LUCIANI: So yeah, we have a diagram on our
developer's documentation on developers.google.com.
And this is a scheme of what Joanna just told you.
So what happens when you use the Google+ Sign-In, as I
showed you before, you get an access token, but
you also get a code.
And you can use that code to perform the exchange.
I will show you now how to do it using one of our
quick-starts that you can find in our Google+
repository on GitHub.
As you might already know, there's quick-starts for many
different languages.
So there's two key things here.
What I'm showing to you now is from the index.html of our
quick-start, which is where we rendered the button.
And then we have some JavaScript asynchronous call
to a simple backend API implemented in PHP.
So what happens in this connect server function is
that we are posting to our server the code that we
obtained from the Sign-In button that was in the object
that is returned to the callback
of the Sign-In button.
One important thing that we are doing is to avoid
cross-site request forgery, when we rendered this page
from the server-side, we created this state which is a
random value.
We rendered the random value in the parameters of this
invocation, and we save it in the session so that when we
receive this request on the server, we can compare the
value with what we stored in the session.
And you should do it, probably, in the database.
If they are the same value, then we can see that this is
our request.
Otherwise, something fishy might have happened.
If we go to see what happens on the server-side in our PHP
API, we can use the Google API client for PHP.
We just have to initialize it with some standard parameter.
At this point, this function--
the connect function--
is where we post the code.
And what happens here is that when we receive the code, we
make the exchange with the Google token endpoint, and
then we make some verification on the token.
We check that the audience of the token is our app so that
this token is actually intended to be for our
application.
And we check that the user that is tied to the access
token is actually the user that is trying to
login to our app.
And then we are good to go.
Otherwise, if we found some problems, some errors, we
return some meaningful error about what happened and what
went wrong in this exchange.
ALLEN FIRSTENBERG: And I think it's important to point out
that these checks are really very, very important.
One other way that a lot of people have talked about doing
this sort of thing is handing the access code from the
client to the server.
And that's just a bad, bad way to do it.
Using this separate code and then doing these additional
checks on the server side is much more
secure, much more reliable.
And it really kind of drives home the point that Google is
trying to create code and create flows that are meant to
protect developers and users combined.
I think one of the great things about this particular
flow and the way this one works is that in the end, both
the client and the server have access to a user's
information, can communicate with Google
on the user's behalf.
So you can have some of the JavaScript stuff using the
JavaScript APIs to talk directly to Google, and the
server ends up with the code, ends up with the ability to do
the refresh token, ends up with the ability to do things
on the user's behalf if that's what you're trying to do.
So that's an important dual feature.
It's really pretty powerful that you're allowing this sort
of thing and allowing it securely.
SILVANO LUCIANI: Yeah.
And one important thing that I forgot to mention on the
security point of view is that this token
is a one time token.
So you can use it only for one exchange.
And it will expire pretty soon.
So do the exchange fast.
Because otherwise, you won't be able to use it.
ALLEN FIRSTENBERG: Where pretty soon is on the order of
less than a minute or two?
Less than that, if I remember correctly.
SILVANO LUCIANI: I didn't give a-- yeah, yeah.
Less than a minute.
I don't remember the exact.
But yeah, I usually do it immediately.
So yeah.
JOANNA SMITH: And so those are our three flows.
And it really helps to be able to decide for yourself as a
developer if you want to focus primarily on client-side,
primarily on server-side, or if you feel like you really do
want to make calls on both sides of your application on
behalf of the user.
And hopefully with a little bit of this discussion, you'll
be able to figure out which one's right for you.
But of course if you want to learn more, definitely check
out our documentation at developers.google.com/plus,
because that's where we put everything, including that
really helpful diagram to track the flow.
SILVANO LUCIANI: Yes.
And as I showed you, our project's on GitHub.
You can find the quick-starts with our showings
on different approach--
pure client-side with the JavaScript, mix the one time
code exchange with the Python, Java, PHP, Ruby, and C#.
And then there's also PhotoHunt, which is an
end-to-end sample application.
So it's giving you an example of a more complex
authentication scenario that involves also like mobile
clients for Android and iOS.
JOANNA SMITH: And of course, if you have any questions, let
us know in our Google+ Developers community.
I check that every single day to see what's going on and if
anyone's looking for some help.
And of course, we have Stack Overflow with our Google+ tag,
which we also check daily.
And then the final resource is our Issue Tracker.
And if you find a bug, or if you have a feature request, go
ahead and check there or file a new one.
But if you find one that you like, star it, because I use
those stars every week when I triage those issues, and the
stars are what tell us what's important and which things we
need to move into our internal bug system and which feature
requests need to be sent along to PMs.
So definitely take the time to star an issue that you find
important, because that's going to be really key.
ALLEN FIRSTENBERG: Yeah.
I know I always hang out on Stack
Exchange and Stack Overflow.
So issues that show up there--
I enjoy reading them.
I enjoy getting the perspectives of other
developers on what you're trying to do.
And for that I always turn to our Google+ Developers
community on Google+ itself.
We've had a lot of good exchanges there.
Always good to hear how other people are using this and also
the problems that you're having, because that helps me
and it helps the team improve the documentation and improve
the resources for all of us.
JOANNA SMITH: Definitely.
If you aren't getting what you need to out of our
documentation, you need to be letting us know because our
whole job is to help developers succeed, and that's
what we really care about.
So definitely speak up about good and bad things.
It really helps us out.
And that's our show for today.
But before we go, I just want to take a moment to thank
Allen for coming up and being here with us.
It's great to be able to talk to our GDEs.
And of course our other two GDEs are Abraham Williams and
Gerwin Sturm.
And they're incredibly useful resources, so if you see them
hanging out on the internet definitely give their words
some weight, because they matter.
ALLEN FIRSTENBERG: They do.
JOANNA SMITH: And thanks for being here.
ALLEN FIRSTENBERG: I'm glad I could be here.
Thanks for having me and thanks for all the support you
guys give to all of the developers out there.