To access Google Cloud Storage via REST API to another user account, after authenication with OAuth2.0, HTTP 403 is replied

Question

Below shown what I have done so far, after I successfully developed my application with a single Google account.

I have created another Google account with Google Cloud Storage enabled, in order to test whether I can register an API project with one account or not, and then use this client ID (& client secret) to list/create buckets or objects to another account. i.e. to go through steps:

1. "email account 1" owns "API project 1", and create buckets/objects Google Cloud Service account to "email account 1"

2. "email account 1" owns "API project 1", and create buckets/objects Google Cloud Service account to "email account 2"

3. "email account 2" owns "API project 2", and create buckets/objects Google Cloud Service account to "email account 1"

4. "email account 2" owns "API project 2", and create buckets/objects Google Cloud Service account to "email account 2"

It is all OK with case one, obviously, since all the things are under the same account.
After that, I have been stuck in case 2, with an HTTP response code 403. (forbidden, access denied) Once, I have interpreted it as a project can only write data in its own account. However, I don't believe that it is reasonable, then, I tried step (3), i.e. register the API project 2, and then use OAuth2.0 authentication with "email account 1", and it works finally.

Then, I tried case (4), it still failed with HTTP 403! i.e. The owner of the project cannot access its own Google Cloud Storage service!

However, with Google OAuth2.0 Playground, I can create a bucket with the account with problem ("email account 2").

Can anyone give me some hints that, what is the problem with my 2nd account? Why API application cannot access its own Google Cloud Service, even though the OAuth2.0 is done?

Answer 1

First a clarification on nomenclature. Email accounts don't own buckets: projects do. You log in as a user, and that user may have permission to create buckets for a project, but it is the project that owns the bucket. Objects are different. Objects are owned by accounts.

The reason for this is that the billing is done on a per project basis. When you store an object in a bucket, the bill is sent to the project that owns the bucket that the object is in.

Users can be members of multiple projects, and so when you try to create a bucket, you have to specify which project you are creating a bucket as. Projects can only create buckets if they have enabled billing.

So you may have encountered something like this:

1. "Email account 1" owns "API project 1", which has billing enabled, and can create buckets that belong to project 1 and can create objects in that bucket that belong to email account.

2. "Email account 1" cannot create buckets owned by "API project 2".

Email account 1 might have permission to create buckets that belong to project 1, but it might not have permission to create buckets owned by project 2. This could be for a couple of reasons. Maybe email account 1 simply isn't an OWNER or an EDITOR for project 2. Or, maybe project 2 doesn't have permission to create buckets because billing isn't enabled for project 2.

Then we get to case 4: "email account 2" owns "project 2" and cannot create buckets for "project 2".

Since email account 2 definitely owns project 2, it seems very likely that the answer is billing is not enabled for project 2.

Answer 2

In general there are a few reasons you may see a 403 error returned by a Google API. Here is what you should check (common to all Google APIs):

For the project associated with the client that is making the request (for a service account, that means the project that the service account belongs to):

1. The API being accessed is enabled.
2. Billing is enabled (if applicable that API)
3. Quota has not been exceeded:
   1. Per project (courtesy limit)
   2. Per user (configurable in Google Developer Console).

For APIs that include accessing resources belonging to a project (e.g. most Cloud Platform APIs), the above is also validated against the project owning that resource (if different).

So to your question - a service account belonging to project A should be allowed to manipulate resources (such as Cloud Storage buckets/objects) in project B provided that service account has been either added to the project team for project B, or explicitly added to a Google Cloud Storage bucket/object ACL entry.

In any case - project A will need to have the Google Cloud Storage service enabled (which may require billing be enabled) - however usage of that service account to manipulate resources owned by project B will be billed to project B.

See the following presentation for some more background on this: https://developers.google.com/events/io/sessions/333234305