Tip:
Highlight text to annotate it
X
NICHOLAS GARNIER: Hello, everybody.
My name is Nicholas.
BURCU DOGAN: And I'm Burcu
NICHOLAS GARNIER: We are from the Google Drive Developer
Relations team, live from Zurich.
And we are here today to talk to you about cross-client
authorization on Android and the web.
So Burcu, could you basically explain to us in what this is
interesting to the user?
Who should use that?
BURCU DOGAN: Yeah, most the time, your projects may have
more than two components, the web and the mobile.
So the authorization experience between cross is
different applications always is troubling.
So we listened to developer feedback.
And we wanted to improve the experience for the users.
And back in May, we introduced two features that will
actually help you a little bit more.
NICHOLAS GARNIER: So can you just give me a few examples of
architectures, basically, that developers have where they
should use this?
For example, they have an Android app and a server side
component, they need to talk.
BURCU DOGAN: Yeah, for example.
You want to delegate some task to the server side such as
processing data on the server side into the mobile
application.
So in this case, your web server needs to be authorized
as well as your mobile app.
But just imagine that your user discovered the app on a
store, and downloaded it, and authorized it, and haven't
touched to the web component.
NICHOLAS GARNIER: Yeah, haven't authorized
yet from the web.
BURCU DOGAN: Yeah.
So what you basically can do is to just retrieve an access
token, which is likely to live not for long,
just an hour or so.
So if you would like to delegate some work, some
background, offline work to the service itself, it's
basically not so possible.
I have seen some bad implementations that people
were trying to exchange the access token
with the web server.
But from a security point of view, it's not good.
And also, the tokens are not living long.
NICHOLAS GARNIER: Yeah.
So basically, this is for developers that have both a
web component-- it could be a separate app or just a
server-side backend to run some process--
and also, for example, an Android app.
And those two need to authorize in a very nice,
UX-friendy way, basically.
BURCU DOGAN: Yeah.
True.
NICHOLAS GARNIER: Is that correct?
And you also want to avoid just passing a simple access
token, which you could have done before, using the regular
play services authorization.
BURCU DOGAN: Yeah.
NICHOLAS GARNIER: Right.
BURCU DOGAN: This was one of the features.
The other feature we have released was, we resolve the
user's identity with no sign-in on the Android app, if
you are authorized for the web component.
Just imagine, in this case, that you have a web app, and
the user is given the right permissions.
And once he wants to switch back to the mobile app, he
needs to go through, again, the authorization.
NICHOLAS GARNIER: So you want to avoid the user
to authorize twice--
once on the web app, and then they want you to try your
Android app.
And they have to authorize again.
BURCU DOGAN: Again.
NICHOLAS GARNIER: So this is a way to have the user already
authorized, right?
BURCU DOGAN: Yeah
NICHOLAS GARNIER: So maybe we could have a look on your
computer in details the documentation, so we could
explain how this works, basically.
BURCU DOGAN: Yeah, sure.
Let's go through our documentation first.
NICHOLAS GARNIER: So first, let me explain to the
developers here who are watching us.
The documentation can be found in a few places.
We are from the Google Drive SDK team.
So we have written a Google Drive-specific documentation
on the Google Drive SDK, online doc.
You can go there.
It's fairly generic, so you could apply this to more--
BURCU DOGAN: Other Google APIs, basically.
NICHOLAS GARNIER: Other Google APIs.
BURCU DOGAN: With different scopes.
NICHOLAS GARNIER: Yes, with different scopes, just by
simply applying different scopes.
But there's also a documentation on the Android
documentation itself, which doesn't contain a lot of code
samples, which is why we have augmented it by releasing this
documentation here.
So maybe you could show us where that page is?
BURCU DOGAN: It's under authorized requests.
And we have this section, Choose a Platform, where we
will go to the Android one.
And there's a new section called Cross-Client Identity.
And this basically explains implementation
for both of the features.
So let's first start with how to retrieve a code for the
server, so the server can get offline access.
NICHOLAS GARNIER: Yeah.
So this is basically when the user goes on the Android
application first and you want to authorize your server side
to be able to do either, for example, long-term processing
because in the--
before we even launched that feature, the Play services
only allowed you to fetch an access token, which is only
valid for one hour.
So you could have passed this to your server side.
But as we'll see in just a second, this feature now
allows you to pass longer-term tokens, for example, the
refresh token.
It allows your server side to fetch a refresh token, which
grants unlimited access in time to your server side
components.
BURCU DOGAN: So if you're an Android developer already, you
should be familiar with how to get an access token.
Actually, all of the tokens are bundled in this
[INAUDIBLE] core.
So we take care of how--
[?
NICHOLAS GARNIER: With the Android Play services.
BURCU DOGAN: Yeah, Play services.
So what we provide to you is this utility interface to get
an access token.
So instead, what you were basically doing here was--
NICHOLAS GARNIER: So let me just explain.
Before, if you're already using the Play services to
authorize, you would simply pass the scopes, the OS2
scopes of the APIs that you needed access to, for example,
the Google Drive API, the Google+ API, et cetera.
BURCU DOGAN: So yeah, you were providing the
account and the scopes.
And you were retrieving an access token.
NICHOLAS GARNIER: Yeah.
BURCU DOGAN: In this case, what we have done, instead of
just passing the scopes, you need to pass another magic
string, let's say.
And we will just give you a code, instead
of an access token.
NICHOLAS GARNIER: Yes.
So basically, you've
highlighted this on the screen.
BURCU DOGAN: I've highlighted it.
And you need to format the scope, like OAuth2 column
server, client ID.
And you need to append your web apps client ID here, which
is basically in this format.
And it's available on--
NICHOLAS GARNIER: Typically, in this format.
So one very important point for developers.
Your two client IDs, the Android client ID and also
your web client ID, need to be in the
same API console project.
This is how we detect that those two
client IDs are linked.
BURCU DOGAN: That's right.
And still, you need to pass the list of scopes again.
NICHOLAS GARNIER: A list of scopes.
Yeah.
So I see, up there in red, could you highlight it?
BURCU DOGAN: Yeah.
NICHOLAS GARNIER: There is currently a little limitation.
BURCU DOGAN: We have a warning here.
We currently require +log-in to be included in the scope.
NICHOLAS GARNIER: Yeah.
So one of the scopes need to be the +log-in scopes, for
this authorization feature to work.
This is currently, basically, mandatory in the current
implementations of the system.
BURCU DOGAN: Yeah.
Otherwise, you will not be able to retrieve a code.
That's true.
NICHOLAS GARNIER: All right.
And then the API should basically allow you to get--
BURCU DOGAN: A code.
NICHOLAS GARNIER: An authorization code, which you
can pass to your server side.
And the server side will exchange, using the--
BURCU DOGAN: Yeah.
It's like you will continue the flow by retrieving here,
by just making a [? post ?] request, as regular, and
retrieve it.
NICHOLAS GARNIER: Yeah.
This is regular.
OAuth2, by the way.
You exchange the authorization code for a refresh token and
an access token.
BURCU DOGAN: So there's one thing I need to tell.
Instead of passing the redirect URL--
NICHOLAS GARNIER: So typically, with
the regular web flow--
let me explain.
BURCU DOGAN: Just ignore--
NICHOLAS GARNIER: One of the parameters here that you need
to pass in the request is your redirect URI.
Except here, there's no redirect URI, since it's all
done on Android using a native interface.
So you basically simply skip it in the request.
That's what I see.
BURCU DOGAN: Yeah.
NICHOLAS GARNIER: And this should work.
You exchange the authorization code and get your refresh
token, basically.
BURCU DOGAN: Yeah.
So they will basically retrieve [INAUDIBLE]
access and [INAUDIBLE].
So the server side can make its request
on behalf of itself.
NICHOLAS GARNIER: Mm-hm.
BURCU DOGAN: Yeah.
NICHOLAS GARNIER: Cool.
BURCU DOGAN: So, yeah.
NICHOLAS GARNIER: Is there anything else that
the user can do?
BURCU DOGAN: Of course.
So let's switch back to the other feature.
NICHOLAS GARNIER: I knew you were going to say that.
BURCU DOGAN: So in this case, let's take a look how to
resolve user identity without sign in.
It's again a magic string.
Instead of passing the regular scope--
NICHOLAS GARNIER: In which case should developers use
this feature again?
BURCU DOGAN: So you want to know--
NICHOLAS GARNIER: This is a bit different from the one we
just talked about.
BURCU DOGAN: Yeah.
So you want to know who the user is.
You want to know what's the user's email address.
You need to identify the user somehow on your server.
NICHOLAS GARNIER: So you need to identify using the server.
That's, for example, if you are sending data that you need
to save for your user.
And you want to pass also, in a secure way, the identity of
the user, so that your server side can save that data for
the right user.
Is that it?
BURCU DOGAN: Mm-hm.
NICHOLAS GARNIER: OK.
BURCU DOGAN: So in order to, again, pass in the regular
scope string, we have, this time, this string, which is
all this column, server, again, the client ID.
NICHOLAS GARNIER: So basically, this works the same
way that we've just seen?
By using the Play services?
BURCU DOGAN: Yeah.
You still need to uncall Google Auth [INAUDIBLE]
token, the same interface.
And it will basically--
NICHOLAS GARNIER: But you just pass a different magic string.
OK.
BURCU DOGAN: So, yeah.
NICHOLAS GARNIER: So what does this give you?
BURCU DOGAN: What it gives us is a JSON web token.
It's actually different [INAUDIBLE].
And you need to pass it to your web servlet.
NICHOLAS GARNIER: It's encrypted?
BURCU DOGAN: Yeah, it's encrypted.
I'm sorry.
You need to pass it to your server.
And your server needs to decrypt it again.
And it basically has these attributes, ISS, OUD, AZP, and
the user's email.
NICHOLAS GARNIER: OK.
Cool.
So this is basically an encrypted token containing the
user email, which then you can use to
identify your developer.
BURCU DOGAN: That's it.
NICHOLAS GARNIER: So yeah, I just wanted to point out
developers to compare this to what was already existing
before we launched this.
Basically, in the past, you could have done this by
passing an access token that gives you access to the user
info API, for example, or [? our open ?]
[? AD ?] endpoints.
This is basically nicer, because the server side is
going to save one fetch request.
BURCU DOGAN: Yeah.
NICHOLAS GARNIER: You can simply get the GWT in your
request, decrypt it.
There is no external request.
Your server side is going to know already, right away, what
the email of the user is.
Whereas, if you pass an access token to your server side, you
would have had to fetch--
which is also quite secure-- but it would have had to fetch
the user identity.
BURCU DOGAN: So it's an additional request.
NICHOLAS GARNIER: It's an additional request.
And also, probably also, verify the access token
itself, see if it's actually been issued by the app, to
avoid forged requests.
So this is a very nice way to do this.
BURCU DOGAN: Yeah.
But you need to be careful.
First of all, you have to make sure that you are transmitting
this token on HTTPS, instead of HTTP.
And you to make sure that ISS is [INAUDIBLE] so google.com
is easy to fake.
So you have to make sure that [INAUDIBLE] is declined on
your web app.
And the other one is the client ID of your Android app.
And then you can trust that user email is actually
[INAUDIBLE]
Google endpoints [INAUDIBLE].
NICHOLAS GARNIER: Cool.
BURCU DOGAN: Yeah.
NICHOLAS GARNIER: But this is a nice tool, so you avoid a
few requests.
So you're able to do this a lot faster and develop more
efficiently on your backend.
BURCU DOGAN: So we actually have a sample that already
implements a [INAUDIBLE].
NICHOLAS GARNIER: Yeah.
So this is our GitHub repository of the Google Drive
team, basically.
BURCU DOGAN: So we have examples or--
NICHOLAS GARNIER: [INAUDIBLE] samples and--
BURCU DOGAN: Libraries.
NICHOLAS GARNIER: Yeah.
BURCU DOGAN: And so we published [? +client ?]
to Android almost a week ago, maybe.
So it basically demonstrates two cases.
Let's quickly go through the code.
NICHOLAS GARNIER: So this sample is a bit more complete
to what you'll find in the documentation, which skips a
lot of [INAUDIBLE], just shows you the bare bone of the code.
This is almost like a working--
BURCU DOGAN: Example
NICHOLAS GARNIER: Example of the usage of these two
features that we've just seen.
BURCU DOGAN: So as I mentioned, in order to get a
token, you need to [INAUDIBLE]
to a user account name.
In this case, what I'm doing, firstly, in the sample, is I'm
starting an activity to pick a user here.
So there should be multiple users on the phones.
A user can switch back and forth
between different accounts.
So once a user has picked one, we are here.
And this callback, what I'm doing is actually starting two
asynchronous tasks to retrieve first the exchange code and
the JSON web token.
So let's go what we're doing here and see
what we're doing here.
So in order to retrieve a code, what we do is just
formatting this code in the format
that I mentioned before.
So instead of an access token, what it will do is to retrieve
a code, right?
NICHOLAS GARNIER: Authorization code, yeah, [?
to know what to authorize your code. ?]
BURCU DOGAN: By the way, your user is not--
having given you enough permissions before, it will
show a user recoverable auth exception.
NICHOLAS GARNIER: Yeah.
So this is if the user has never granted that
authorization to the app, neither on the web version of
your web app?
BURCU DOGAN: Yeah, yeah.
NICHOLAS GARNIER: Nor on the Android version.
BURCU DOGAN: And for the scopes, you have passed.
NICHOLAS GARNIER: For that exact list of scopes.
BURCU DOGAN: Yeah.
So what you can do here is that this exception is an
[? intent. ?]
So regularly it's the same while you're trying to
retrieve an access token, right?
If the user hasn't given you enough permissions, you start
a new activity for the dialog.
NICHOLAS GARNIER: Yeah.
Basically, the user will get a nice native authorization
dialog on their Android device where they can simply approve
or reject the authorization that the app is asking for.
BURCU DOGAN: That's true.
So once a user has given access, I'm going to check if
the user has really given access to us or not.
So in this case, if it's yes, I'm actually
retrying the same request.
So in this case, instead of this exception, I will be able
to retrieve the code.
And what I'm basically doing here is just, put it on the
application's UI.
But you need to pass it to your web server.
NICHOLAS GARNIER: Yeah.
That's when you do an HTTP request to send it to your
server side, which will exchange it, basically.
BURCU DOGAN: Yeah.
I know another case in order to retrieve a JSON web token,
what you do is to format the scope.
In this case here, I'm highlighting it.
NICHOLAS GARNIER: Yeah.
And again, catching the exception with this.
If it's never been approved before, if the authorization
has never been granted before, and it probably works the same
way as that.
Correct?
BURCU DOGAN: Yeah.
NICHOLAS GARNIER: OK.
BURCU DOGAN: So yeah, it will return back
to this line again.
And I will be retrying again.
So yeah.
And it will retrieve a JSON web token.
And you can pass it to your web server.
And your web server can resolve the
identity of the user.
NICHOLAS GARNIER: Yep.
BURCU DOGAN: Yeah?
NICHOLAS GARNIER: Cool.
So yeah.
Maybe we're done with the documentation.
BURCU DOGAN: This quick sample code.
NICHOLAS GARNIER: And the simple code here.
So basically, let's talk about, in general, what is it
good for, what are the advantages of using that
feature against what was possible before.
So in my understanding--
and you can let me know if you agree--
this is very nice, because it's going to provide a
completely Android native experience to your users,
while still keeping two client IDs in sync.
So what developers were doing before, previously to this,
some were using a web view on their Android app to start an
OAuth2 flow using the [INAUDIBLE] of their web apps
to have a common client ID, which wasn't very nice,
because the user had to log-in again inside the web flow.
There, you'll get a very, very nice native experience because
of those native pop-ups.
The user is already signed in to his Android machine.
He can very, very quickly approve.
And he will still get auto-approval on the website,
if you have also web components.
BURCU DOGAN: Yeah.
It's a seamless experience for the user, first of all.
And we enabled [INAUDIBLE]
was basically not available before.
So yeah, that's basically it.
And Google used a sample, so we're actually looking for
developer feedback.
These two tokens are a little bit more experimental.
And maybe, in the future, we can expand the OAuth2 spec.
NICHOLAS GARNIER: Yeah.
It's basically like a workaround around the OAuth2
specs, because OAuth2 has never really defined a way to
do cross-client authorization.
BURCU DOGAN: That's true.
NICHOLAS GARNIER: So this is our implementation,
our way to do it.
We hope you like it.
If you'd like to give us some feedback, please have a look
at our code sample on our Github Google Drive page.
You can leave comments there, I guess.
BURCU DOGAN: Yeah.
You can file issues, if there's a problem.
And you can contribute back.
NICHOLAS GARNIER: Yeah.
We'll be happy to hear what you have to say about this.
All right.
Is there anything else that you'd like
to talk about, Burcu?
BURCU DOGAN: I think that's it.
NICHOLAS GARNIER: OK, cool.
Then thanks, very much, guys, or everybody.
BURCU DOGAN: Thanks, for watching.
NICHOLAS GARNIER: Guys and girls, for watching.
And we hope to see you another time.
So it was Nicholas and Burcu, live from Zurich.
All right, bye-bye.
BURCU DOGAN: Bye.
[MUSIC PLAYING]