Hi everyone, and welcome to today's Google Developers Live
for Google Drive.
Today I'm going to talk about a very, very small change that
was made to Auth in Google Drive.
And it's just one little check box in our SDK settings.
But it actually has really big implications for how you
develop your application.
So I want to switch over to our SDK settings here.
This is the APIs console.
And if you've built a Drive app that does open with or
create from the Drive UI, you've been in here before and
you're familiar with it.
But one thing that changed probably about a month back is
this Authentications section.
Before, this little check box that says, "Automatically
initiate the OAuth to flow" was not present, and this
section was always enabled for applications.
What this did is when a user clicked Open With or clicked
on a file or clicked Create in the Drive menu, Drive would
automatically initiate the OAuth flow on behalf of your
application.
It did some really good things as a result.
It solved one really important problem for developers, which
is handling multiple user accounts.
Since we already knew which user was logged in, which
Drive account it was, we were able to automatically route
that Auth flow for the correct user.
So you didn't have to worry about that.
But it did have some negative side effects, too.
So one of them was, it's pretty tedious to
configure all this.
There's a little bit of duplication.
You can see here we have to copy our client ID.
This is from the API access section.
We needed to list all the scopes that our app used.
By default, it included the drive.file.scope.
But if you needed access to the user's profile or their
email address, for example, you had to copy these in here.
But you also needed to list these in your code as well,
because most apps had use cases where they needed to
initiate the OAuth flow themselves.
So you just had a lot of copying and
pasting back and forth.
And every time you added a new scope, you wanted to make sure
that you kept these in sync.
There were also some other complications with the
Redirect URI, specifically again some duplicate
configuration.
Because Drive was initiating the flow, it was setting the
redirect URIs to your Open URL, or if you had Create, you
had a Create URL.
And for example, if you wanted to have a separate action for
these two different events, we now had two different redirect
URIs that we could possibly receive.
And hey, look at that.
An unexpected error.
That is really unexpected.
So anyway, you had these two different redirect URIs.
You would also have to copy those into the API access and
register them.
And then in your code, of course, you would need to have
those configured and then switch depending on which one.
It made handling OAuth in Drive a little bit more
tedious and error prone than it really needed to be.
So what changed?
Basically, what we added is an option to disable this for
applications.
And by default for new applications, Drive-initiated
OAuth is disabled.
What this means is that your application, if you're writing
a new Drive app, you are in complete control over how
OAuth works within your application.
I did mention earlier that the previous mechanism had solved
one important problem, which is multi-login.
To help you handle that now when you're initiating the
flow yourself, we added a new parameter into the JSON state
parameter that Drive gives you.
And it's obviously called User ID.
And this user ID can then be used by your application to
give us a hint when we prompt the user for authorization
which account we should be authorizing with if they
happen to be logged in with multiple accounts.
One word of warning.
This User ID is not the user's regular user ID.
For privacy reasons, it's obfuscated differently than we
would obfuscate other user IDs, because at the point when
we're giving this to your application, the user may not
have approved your app.
They may have just installed through the Chrome Web Store,
which doesn't have the same set of approvals that you
would have on the OAuth screen.
So until the user has fully consented to giving
information to your application, what you receive
about who the user is is an opaque ID.
It's obfuscated differently than other IDs that you may
see for that user in the Drive API or in, say, the user
profile or Google+ APIs, so you can't really use that as a
way to correlate user activity.
But you can use it, and you should use it, as a hint when
initiating the OAuth flow so that the correct account is
used and authorized for your application.
So why did we make these changes?
Well, one was, I mentioned earlier the previous mechanism
was just very tedious, a lot of duplicate configuration, a
lot of things that you can get wrong when setting up your
application.
But the bigger implication was it was actually very difficult
to create a Drive application that was pure client-side.
So for example, if you wanted to do a pure JavaScript client
application, or doing a Chrome-packaged app, because
we were always requesting--
always initiating an OAuth flow that was designed for
server-based web applications and included things like
offline access, it just made it very difficult to do a pure
client-side.
You always had to have that little bit of server code
running in order to handle this login case.
It wasn't too bad, but now you can actually use a JavaScript
client library, for example, and keep the authorization
flow completely within the web browser.
The other thing is it gives you a little bit more
flexibility in terms of what you need from OAuth.
For example, with the previous mechanism, because it was
always using the drive.file scope, it pretty much forced
you into using that scope if you had an app.
You could, of course, always add an additional scope to
get, say, the full Drive access if your
application needed it.
But then you would have a very confusing
authorization dialogue.
And while we certainly encourage everyone to use the
narrowest scope possible for their application, and the
drive.file one is definitely preferred, there are certain
applications that really have a very compelling use case and
a justified use for having the full scope for Drive while
still appearing in the Drive Create menu and being able to
open files from the UI.
So if you do fall into that category, you now have the
option of initiating the OAuth request using just the Drive
scope and avoiding having duplicate text or conflicting
text in the OAuth dialogue, which potentially could
confuse users.
So one of things that I'm actually
really curious to do--
for those who have been through our documentation and
our samples, you know we have a JavaScript quick start.
We don't yet have a JavaScript version of the text editor
sample that we have for most other languages.
That is something that we would like to do.
Hopefully we'll have that out soon so that you can actually
see how to build a pure client-side application and
take advantage of this change in how we open applications.
But there are some other things that I think would be
interesting challenges for people to try, things that I
want to try myself.
I'm really hoping that somebody's going to beat me to
it in the community and maybe can post in the Google+
community about whether or not it was successful or learned.
But really, the two things that I'm curious to see how
they would work with Drive apps, one is building a
Chrome-packaged app.
Now that we can actually build Drive applications that are
completely client-side, it should be possible to build a
packaged app that works with the Drive APIs that integrates
with the UI and runs without a server.
And then the other thing is I know there are some new
experimental APIs in Chrome for identity.
Of course, we have the ability in the JavaScript client
library to do authorization.
It would be just really curious to see if people are
successful in using the identity APIs in Chrome as an
alternative, particularly when combined with
the packaged app.
So interesting things to do.
Maybe when we do to the JavaScript version of our text
editor, that's something that we can look at trying.
But if somebody out there is really curious and wants to
try it, I'd love to hear the results of that, whether or
not you're successful.
That's really the change.
I just want to give a couple other tips related to OAuth.
And this is regardless of how you're doing it, whether or
not it's client side or you're still using the server flows.
Just remember that with this change, what your app is doing
is really just plain OAuth 2 that you would use for any web
application, whether or not it was for Drive or using any of
our other APIs, like Google+ or Calendar or Contacts.
It doesn't really matter.
It is important, though, particularly in the case of
Drive, that when you are given a user ID hint when a user
initiates an action from Drive that you include this in your
authorization request.
And this should work for both the JavaScript client in the
configuration--
you can just give it user_ID and then the value.
Similarly for all of the client libraries, they all
allow this in the OAuth request.
If you happen to be constructing the URL by hand,
the query parameter that you would include in the request
is user_ID.
And then you would set that to the value that you get in the
state parameter.
This is really important.
If you don't do this, what could happen is a user would
attempt to open a file.
When they do the approval dialogue, depending on which
account they were using in Drive and which is their
default, or depending on just what they select in the
account chooser, they may pick the wrong account.
And what would happen is you would end up getting
authorization for an account that is different than the
owner of the file that the user is trying to act upon.
So what would happen is you would authorize.
Things would look great.
But as soon as you try to read that file, you're going to get
an error saying that you don't have access.
That would just be really confusing for the user.
You'd have to handle that, kind of back out, retry the
authorization, and hope that they picked the right user
account again.
It's just not a good user experience.
But if we can give you the user ID and you have it,
include it in the request, and it will ensure that the user
gets a really nice, smooth experience.
You can do some optimizations, depending on
how your app is done.
So for example, it's quite common for a user to launch an
application from Drive for an app that they're already
logged into.
So if you don't want to blindly check and reauthorize
every time, what you could do is you can detect if the user
has an active session, check to see if it's the same user--
because it is possible if they're logged in with
multiple accounts that they may have switched accounts in
between that period of time.
But you can use the user ID from the state parameter
against a saved value.
If they're the same, there's really no need to reauthorize
in that case.
And so you can save a redirect or save those two to three
seconds that it takes to actually do the authorization,
and then just let the user in right away.
If it's a different user or you don't have an active
session, then of course you do want to go through the full
authorization flow and make sure they have an updated
access token.
For JavaScript, if you're building a client-side
application, you can do this type of check.
There is what we call immediate mode, which is a way
that you can check to see if the user has previously
authorized your application and get an
updated access token.
You should always do this first for
the JavaScript client.
What this allows you to do is that if the user has
previously authorized your application, we don't want to
show an approval prompt.
We really just want to give you an
access token right away.
Immediate mode allows your application to do that check
but do it in a way that is transparent to the users, so
actually do a hidden iframe with post message, handle that
communication.
And then you just get back a status.
You either get back a successful
authorization or a failure.
And if it's a failure, then you want to go through the
normal authorization flow.
And when you do the normal authorization, you'll get a
popup and then the full UI for authorizing your application.
What this immediate mode does, besides giving a quick way to
do it, is in the case that the user is authorized, it's just
a nicer experience, because it avoids flashing a popup.
Even though it's only there for half a second or a second,
it's still something that you want to avoid just to keep
your UI nice and clean.
Other than that, just remember with OAuth in general, whether
or not you're talking to our APIs or any other provider,
they do want to keep your keys and secrets
protected, same as tokens.
Treat these like passwords.
It's a lot easier to reset tokens or reset your
credentials if they happen to be compromised.
But obviously, you want to avoid ever having credentials
compromised in first place, because it is disruptive, both
to you as a developer and to your users if they have to
reauthorize access to your application.
So treat these as sensitive materials, as you would for
any other credential that you would store in your system.
Other than that, I think that's really about it.
I do know there are a couple issues with the JavaScript
client related to multi-login.
I know there's some issues in Stack Overflow related to
this, and in the Issue Tracker on the client API.
It should, however, still work with the user ID parameter.
So basically, the issue that I'm referring to is by default
when you do an OAuth request with the JavaScript client, if
the user is logged in with multiple accounts, it's always
going to default to the first user.
However, if you do give it to the user ID parameter, it
should pick the correct user regardless.
Just at the moment, there's really no way to force the
account chooser if you want to make it an interactive
experience.
That is something that we're aware of, hopefully something
that will be fixed not too long.
But for the purposes of a Drive app, you should be able
to do things correctly and have a good experience.
And again, hopefully, probably in the next week or two, maybe
a little bit longer, we'll have an updated text editor
sample that shows how to do this in JavaScript.
And then from there, maybe we'll try some of these other
experiments with packaged apps and so on.
Again, I would love to see somebody from the community
try these things and give us your feedback as to what works
and what doesn't and if there's things that we could
do to make it easier.
Other than that, that's all I have on this.
Again, always check back in the documentation.
We'll try to keep it up to date.
Look for refreshes of a lot of our samples.
In the future there are some other OAuth-related changes
that we made, things like the install scope which we've
talked about back before the holidays, things that just
make it a lot easier for you as a developer to get your app
up and running without having to go
through a lot of overhead.
So in the near future, we're going to update all those
examples, clean up all the details that we used to have
in there about working with the Chrome Web Store, switch
over to using the install scope for Auth, and just
generally make it a much easier experience for you as a
developer to get started with these APIs.
So that's all for today.
I'm not sure what our next topic is going to be, but
check back on the Google Developers Live site.
We'll be back on Friday.
Our new normal times are, I believe, Tuesdays and Fridays.
And look for either Ali or Claudio to be here next time.
So thank you, everyone.
And we'll probably see you next week.
[MUSIC PLAYING]