STEVE BAZYL: Hey, everyone.
Thank you for joining today for another Google Developers
Live session on Google Drive.
Today we're going to talk about, how to use Service
Accounts with Google Drive.
For those who aren't familiar with Service Accounts, this is
a special mode for OAuth 2.0 that is really designed to
allow applications to act as themselves.
Typically when we're using OAuth with the Drive API,
we're building applications that are acting on behalf of
the user and accessing the user's data on their behalf.
And that requires a particular flow around what we call
"three-legged OAuth," where there's this exchange, a
series of re-directs, in order for the user to delegate that
access to your application.
With service accounts, we're basically removing the user
from that equation, and allowing the application to
use its own credentials, and act on data.
In the case of Drive, there's really two use cases that this
becomes very useful for.
One, is--
in cases where you actually just want to build an app that
stores data in Drive, but it can continue to own that data.
It can still share files it creates in Drive with users.
It can use some of the advanced features in the SDK
such as document conversion, OCR, image recognition, and
Goggles, but doing this all in the context of owning the data
itself, and not acting on behalf of a user.
There's a second use case, which is particularly
important for Google Apps for Business customers, which is
user impersonation.
And we can use the Service Accounts functionality in
OAuth to allow an application to act on behalf of users
within a domain, but without involving them directly in the
authorization.
And we'll actually go through both of
those with some samples.
For those who are curious about how service accounts
work, you can find information at developers.googl
e.com/account/do cs/oauth2serviceaccount.
I actually have the page up here.
This page actually goes a lot into the particular protocol--
the mechanism-- which is it's an assertion
profile that uses JWTs.
You'll see those are j-w-t, pronounced "jawt." And it's
basically a small bit of JSON, it's Base64 encoded, digitally
signed, and then transmitted over.
It's a lot simpler than a lot of the other assertion
protocols that been around for while-- things like
[? SML-- ?]
[? so ?]
[? it's ?] really simple, very
lightweight, and easy to implement.
Again, the information on here is really for
building it for yourself.
The good thing is most of our client libraries actually have
this functionality built in.
It's very easy to use.
And for the demos that I'm going to do, I'm going to be
using the Ruby Client since that happens to be
the one I work on.
But again, you can find the same functionality, similar
code in Java, Python, PHP.
And I think most of the libraries now
have this built in.
So the first thing you really have to do when you're using
Service Accounts is you have to create credentials for your
application.
I'm going to switch over to the API's console.
And here, I actually already went through the steps of
creating it.
And you can see here, we have a service account with a
client ID and email address.
And this actually downloads a new private key when you
create this.
Actually just going to create another one here.
We can have as many of these as we want.
But it's really simple.
Create client ID, you select a service account, and create--
that's going to generate a key pair--
you can download this.
And we'll get a PKCS12 file.
You do need to make note of the [? secret. ?]
Right now these are not password projected-- well they
are password protected, but it's the same password for
every file.
So you do need to take care of protecting your private key
once you get it.
Also you cannot download it again.
If you do lose that file, you do need to regenerate it so
that you have a new one for your application.
But we created another one.
I' m just going to use the first one that I had over here
and switch over to our little sample application.
For those who have gone through the quickstarts
before, this is basically a modified version of the
quickstarts that we've been showing off in some of the
earlier Google Developer Live sessions.
They are also up on the website.
And what I did, I just went through that application and
changed the OAuth mechanism to use Service Accounts.
So there's a couple things I want to point out
for how this works.
These first couple lines up here-- basically just the
information that we need in order to have our app
authorize itself.
We have the service account ID.
This is the email address that is generated for
that service account.
You'll notice, if you go back over to the API console, we
actually have two different client IDs.
You have a client ID and an email address.
Typically with OAuth 2.0, we're using the client ID in
the various OAuth APIs to identify our client.
In the case of the assertion profile with Service Accounts,
we actually want to use the email address instead.
So go over here.
We have our key file-- this is one that we
just downloaded earlier.
Again, it's a PKCS12 file, and we also have the secret to
unlock the private key-- in this case just not a secret.
The rest of this is actually follows very similar to how
OAuth works in general.
We initialize the client.
We have the API we want to discover-- in this case,
Google Drive.
But instead of going through the redirects that we would
normally do for OAuth or normal three-legged OAuth, We
actually just create [? a new motor ?] key file,
create our [? asserter ?]
with our service account ID, the scopes that we want, and
our private key.
And then we can make an assertion.
That is very similar to what would happen when in normal
OAuth where you get a code from the user and you would
exchange that for an access token.
In this case, we're just exchanging the assertion for
an access token that we can use in our application.
Once we have that set up, we have an authorized client, and
we can just do an upload as normal.
So we can actually go and try this, and what we'll see here
is everything worked fine.
We uploaded the file, and we have the metadata.
And the one thing I want to point is the owning
user for this file.
And we can see here is our service account-- our
application-- basically is acting as a user and it owns
the content that we created.
So we can use those.
We can create as many files as we want up
to our quota limits.
One of the limitations, though, with this approach is,
there currently isn't a way where you can actually buy
more storage quota for your service account.
In terms of practical usage, there are limits, but you can
still do some very interesting things with Service Accounts.
The other case I want to demo--
and first, I'm going to switch over to here--
is this mode of user impersonation.
And this is just our Google Apps control panel.
We just have one of our test domains here, [? Apps ?]
[? Rocks. ?]
And underneath Advanced Tools, there's this link down here
for Manage Third-party OAuth Client Access.
You can click here.
And I actually already created this earlier, but here's where
we would do the delegation for--
or basically to authorize our application to impersonate
users on this domain.
So basically what you do is you take the client ID--
this is the actual client ID for the service account, not
the email address--
list the scopes.
And then you authorize.
Now what we can do is we can go back into this file.
And now I'm just going to add my email address here.
So when I authorize, instead of authorizing on behalf of
the application, I want to authorize on behalf of the
user for that domain.
I can go back in.
You can rerun this.
And what we'll see is now the file is owned by me.
So even though it's basically the same mechanism by virtue
of the fact that I have at the domain level authorized this
particular application to act on behalf of any of my users,
I can now easily switch.
This is really useful if you're building Administrative
Tools, you're a domain administrator, you want to do
auditing of docs usage or reporting or just moving files
between users in a programmatic way.
Obviously, it can be very difficult to have lots of
different users come and authorize your application.
This just allows you as a privileged administrator to
create applications that can do things across your domain
very easily.
If you were to try this and say, let's change this to my
Google [? account, ?]
this will fail because this application isn't allowed to
assert users on that domain.
So, pretty easy to use.
There is one other case for Service Accounts that I want
to mention.
It's not something that is currently supported, but this
is our App Engine robot accounts which uses a
functionality very similar to the Service Accounts
that we just saw.
But for various technical reasons it is not yet fully
supported with the Drive API.
It is something that we're aware of and looking to fix.
But if you do you want to use service account functionality
on App Engine, particularly with the Drive API, you do
need to do a service account created through our APIs
console, as opposed to using the built-in robot account
functionality that comes with App Engine.
Again, something we're aware of and looking to fix.
But there are workarounds for the time being.
So that is Service Accounts.
Again, you can find this functionality in most of our
client libraries.
It's generally pretty easy to use--
particularly useful for domain administrators that want to be
able to manage Google Drive on behalf of their users, without
having to build a full-fledged web application, and have to
go through the complexities of requiring each user to
authorize themselves.
So that is all for today.
Look forward to seeing everyone on Thursday at our
next session.
I don't know if we have a topic yet, but once we have
that, we'll make sure that it is announced and available on
developers.google.com/live.
And you can also find us on Google+ and Stack Overflow.
Great, thank you very much.
[MUSIC PLAYING]