[MUSIC PLAYING]
MALE SPEAKER 1: Shanghai GDG is a very interesting
developer community.
FEMALE SPEAKER 1: I'm glad somebody
has asked this question.
MALE SPEAKER 2: This is where the magic happens.
FEMALE SPEAKER 2: This is primarily a question and
answer show.
So if any of you out there would like to ask questions.
ALI AFSHAR: Hi, everyone.
Welcome to Google Developers Live.
I'm Ali, and this is Vic.
And today, we're going to be talking about the
Google Drive API.
Specifically, we're going to give you some tips and tricks
on which OAuth scopes to be using.
VIC FRYZEL: Yep.
So we have a series of different OAuth scopes, and
they have very, very different purposes.
They even apply differently to different types of
applications.
In one scenario, you're going to need a certain scope.
Whereas in another scenario, you might
need multiple scopes.
So we're going to walk through those today.
Right now, on our laptop here, we're on developers.googl
e.com/drive/scopes.
I think you can see that on the screen right now.
So if you take a look at this, there are currently five
scopes that we provide to Google Drive developers.
Ali, do you want to talk about high level-- what the
different ones are?
ALI AFSHAR: Yeah, so can we just mention that with the
Google Documents List API, which was the API you used to
use to manage these kind of files.
We only had one broad scope, and these were in the infancy
of OAuth and OAuth 2.
So really we hadn't fleshed out what we would like.
And this is one of the real improvements we've made over
the Google Documents List API, so one of the reasons really
to move across.
The scopes themselves are firstly the full drive scope
is what we call Drive.
We've got the drive.file scope.
We have the drive.readonly scope and the
drive.readonly.metadata scope, or metadata scope.
We have another scope-- those are for reading data.
We have another scope that is called the
drive.apps.readonly.
And that relates to applications
that a user has installed.
We won't really be talking much about that one.
We'll stick to the data scopes for now.
VIC FRYZEL: So the reason that we have multiple scopes, just
as a reminder, is to benefit users.
This requires an application to behave well.
But really a user has to authorize less access to their
files to an application.
So, for instance, if somebody requests--
if an application requests just the drive.readonly scope,
an application is unable to manipulate the files that it
has access to, but it can read all the metadata and
download each one.
So this is very much less severe than the full scope,
for instance.
ALI AFSHAR: So that's a perfect place to start.
Shall we start with the most restrictive scope there that
is probably the drive.readonly.metadata scope?
VIC FRYZEL: Yep.
ALI AFSHAR: Now there are some applications around that
analyze your drive to see how much is used, and where it's
being used, and which kind of files are using it.
These are really useful applications for yourself and
even in a domain, if you have a Google domain, you can
manage that across all of it.
So previously, with the Documents List API, you'd have
to give that app access to do everything on your drive.
Now, you can just say, well, I only want this app to look at
the metadata for the files and not be
able to change anything.
So very specifically, they don't need to download files,
so you don't need to give that access.
And users are going to be much more willing to use your
application if they know you can't modify the data.
VIC FRYZEL: And how does a user know that an application
can't do that?
ALI AFSHAR: So when you first authorize an application, you
get a list of what the scope can do.
And this is quite a common screen.
I'm sure you've seen it before, the OAuth 2
confirmation dialog.
And it will say view files or list files.
The more permissive scopes, they will say other stuff like
can modify files, or can upload files,
can download files.
VIC FRYZEL: Exactly.
So with the metadata scope, the readyonly.metadata scope,
you cannot download the contents of a file, which is
super important to users who are concerned about maybe
their confidential information leaking to certain
applications.
ALI AFSHAR: So if you can't write the content, what can
you download?
VIC FRYZEL: Just the title, just the
description of the file.
You can find out when it was last modified, when it was
last updated.
You can see a series of its revisions and
who it's shared with.
But you can't actually access the content.
So that's a big deal.
You can pretty much access everything that you see in the
Google Drive user interface until you click
to download a file.
So that's the readonly.metadata scope.
We also have the readonly scope, which is a little bit
more permissive.
Do you want to go into that?
ALI AFSHAR: Yeah.
So the difference there is that you can
also download files.
So you can see what the title is.
You can see the size of the file, but also the application
can download files.
Can you think of an example when that might be used?
VIC FRYZEL: One example where that might be used is if the
application Loop wanted to have the ability to make a
collage of all of the photos in your drive but didn't want
to save the collage back to Drive, an application that
wants to perform some function on the files there but not
actually write anything back.
So in this case, Loop would have to collect the
drive.readonly scope.
They would have to go through all of the images in your
drive, and they would download each image.
And then given that, they would be
able to make a collage.
This is where the example use case ends though, because Loop
actually also must be able to save the generated collage
back into your drive.
So this scope alone is not good enough for that.
ALI AFSHAR: So if something like an application that would
back up all your drive, or say you select a few files, and
you'd like to make an archive from those files, and just
download that zipped archive.
Something like that would be perfectly
good with this scope.
VIC FRYZEL: There's a lot of enterprise use cases for this,
for instance, like enterprise audits or enterprise--
like let's suppose somebody leaves a company or somebody
needs to back up all of their stuff from Google Drive into
the company's filer.
Things like this are very good for the readonly scope.
There's no reason those applications need to write
anything to your drive.
ALI AFSHAR: Absolutely.
And we mentioned users being happy to give you
access to the data.
It also applies to domain administrators as well.
So a domain administrator is much more likely to allow
users on their domain to use your application if you use
quite a narrow scope like this one.
VIC FRYZEL: Right.
Exactly.
To give also an example of readonly.metadata, an example
of where somebody might use this is if they were
implementing their own picker, right?
You want to show the user a list of all of the files in
their drive.
And for some reason, the application has decided not to
use the picker that we provide.
Maybe, for instance, a picker on an embedded system like a
printer can't display our HTML5 picker.
So instead, they generate their own picker and allow a
user to select a file from Drive.
In that case, you don't need to download the files.
All you need really is like the title and type of file so
that the user can see those things and choose one.
And then once the user chooses that, you also have the file's
ID, and then you can use that to do other things.
So the two other scopes that we're going to talk about
today are the Drive and drive.file scope.
I actually think it might be easier to talk about the Drive
scope first.
ALI AFSHAR: I think so.
So the Drive scope's really easy.
It allows the application access to do just about
anything the user can do to their drive.
There's no restriction on that, and that is equivalent
to the scope that you would get for the
Documents List API.
VIC FRYZEL: Exactly.
ALI AFSHAR: I mean, it's so equivalent, in fact, that you
can use a token from the Documents List API that you
got with Drive API.
And that's useful for people who have migrated and they
don't want to reauthorize the user.
VIC FRYZEL: So with that scope, you can do anything
possible with the SDK.
Every single feature is available to you.
Now, that's not to say that you should use that scope.
You should use the least amount of
access that you need.
And actually, that's where the drive.file scope comes in.
That's the most important scope, I think.
Because what this scope allows your application to do is
access files like their metadata and download them and
manipulate them that the application has
either created or opened.
So if I have this scope and I create some file, if I upload
a file to the drive, I now have full
control over that file.
I can update it.
I can download it.
I can delete it if I need to.
ALI AFSHAR: And you can list it.
VIC FRYZEL: And I can list it.
Right.
ALI AFSHAR: So it's a slightly subtle difference.
The user authorizes your application first.
But then you have to have some kind of user input that the
user will explicitly say I will allow this application to
use this file.
For example, clicking in the Drive UI, or from the picker,
or from Android, these kind of situations.
The user makes an explicit choice.
So it's kind of like a filter on the drive scope.
VIC FRYZEL: Yeah.
So the drive.file scope is used primarily by applications
who need to only manage their own set of files.
They don't need to import any data or manipulate in the rest
of the user's drive.
They just want to take some set of files and
manage them in drive.
ALI AFSHAR: So we have some examples, don't we?
VIC FRYZEL: Yeah.
What's an example?
ALI AFSHAR: So take Balsamiq.
I don't know if you use Balsamiq.
It's a mock-up editor.
You create mock-ups for your new website or your GUI
application, whatever it is.
They have their own file format, BMML.
And those files are really are no use to any application
other than Balsamiq.
One day, if they're huge, maybe there'll be other people
who open that kind of file.
So that's really useful for them.
When they get a list of the files, they only get a list of
those files.
They can create those files.
They can read them.
They can do whatever they like with them.
But it's kind of a subset of the drive.
VIC FRYZEL: Yeah.
So really here, Balsamiq is a good citizen.
Like they're a good application in that they're
requesting the least amount of permissions that
they actually need.
They could use the full scope, but they choose not to,
because it's better for users.
ALI AFSHAR: And something we haven't mentioned much is that
you can combine these scopes.
So Balsamiq, if they wanted to just list the titles and be
able to find which files are actually Balsamiq files,
looking at all of them, they could request the
readonly.metadata scope with the file scope.
So they could be able to list all the titles and only open
the ones and save the ones that the
user explicitly allows.
VIC FRYZEL: Exactly.
ALI AFSHAR: So mix and match.
I mean, they're specifically designed to be atomic, so you
can take little bits of them and join them together and use
whatever you like.
VIC FRYZEL: Yeah.
So in the full scope, it's also important to note that
another application with the full scope could see
Balsamiq's files.
So if Balsamiq is creating all of their BMML and accessing
those with the drive.file scope, and another application
comes in and the user authorizes it, that other
application could actually impact those BMML files.
So it's important also when you're working with these
scopes to realize that you're not the only application
working with the user's files.
There's the Google Drive UI.
A user could come in and move files, or
delete them, or do whatever.
And then a user could authorize another application
to do the same thing.
So there's no way to have a locked section or a locked
folder of files that are only accessible by your application
at the moment.
So it's kind of something we're considering, but at the
moment, we don't have anything.
ALI AFSHAR: So this brings us back full circle to the first
thing you said, Vic, is that this is all for users.
And the user owns these data.
The user owns the files.
The user can say anyone can open this file, whatever.
On a regular file system, you wouldn't really lock it down
per application.
You would lock it down for the user name or whatever system
you're using.
VIC FRYZEL: Yeah.
Exactly.
So we are very fond of this permission structure.
And in the future, as we add more and more features to the
SDK, I suspect that we'll make much heavier use of scopes so
that your application can request just the
access that it needs.
So you should really look forward to the future in which
we expose other scripts to do other things.
ALI AFSHAR: Absolutely.
And as we said, very fine-grained as well.
VIC FRYZEL: We've even received a number feature
requests on adding more fine-grained scopes, like
being able to add a scope for instance by file type.
What if I only want to access the images in a user's drive.
That's a very good idea.
ALI AFSHAR: Yeah, it's a compelling use case.
VIC FRYZEL: So I think it's something we're considering
implementing.
But that is a pretty good summary, I think, of how to
use these scopes.
If you want to play around with these scopes, you can go
to the OAuth 2.0 playground, which is linked right here at
the bottom of this page.
And you can request the different scopes and see what
the OAuth dialogue will look like for the user when they
are granting access to your application and see how severe
the messaging is and things like that.
ALI AFSHAR: Obviously, we try to make the messaging more
severe the broader the scope.
We don't want to scare users away, but at the same time, we
do want to be absolutely transparent and honest in what
the user is allowing you to do.
So again, the less you use, the less you ask for, the less
scarier it will look for the user.
VIC FRYZEL: Exactly.
ALI AFSHAR: And we are going to a place where users are
starting to look through this stuff.
I mean, a few years ago, you could have said
people don't read that.
They just click OK.
But people do read that, and people do care.
VIC FRYZEL: Yeah.
We've definitely noticed a huge increase in time spent on
that page reading through these things.
Users pay attention.
All right, I guess that's about it for Google Drive
OAuth scripts.
ALI AFSHAR: Great.
Thank you very much, everyone.
VIC FRYZEL: We will see you all next week.
And thanks for watching.
ALI AFSHAR: Bye bye.
VIC FRYZEL: Bye.
[MUSIC PLAYING]