How do Google OAuth 2.0 Scopes for Google APIs differ from roles and permissions in an IAM on Google Cloud?

Question

I am trying to decipher the meaning "scopes" in the following error message from Error: Could not load the default credentials. context: firebase login:ci AND firebase auth:export:

[2021-04-27T20:48:23.188Z] > command requires scopes: ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase","https://www.googleapis.com/auth/cloud-platform"]
[2021-04-27T20:48:26.208Z] Error: Could not load the default credentials. Browse to https://cloud.google.com/docs/authentication/getting-started for more information.
    at GoogleAuth.getApplicationDefaultAsync (/home/node/.npm-global/lib/node_modules/firebase-tools/node_modules/google-auth-library/build/src/auth/googleauth.js:160:19)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at runNextTicks (internal/process/task_queues.js:66:3)
    at listOnTimeout (internal/timers.js:518:9)
    at processTimers (internal/timers.js:492:7)
    at async GoogleAuth.getClient (/home/node/.npm-global/lib/node_modules/firebase-tools/node_modules/google-auth-library/build/src/auth/googleauth.js:502:17)
    at async GoogleAuth.getAccessToken (/home/node/.npm-global/lib/node_modules/firebase-tools/node_modules/google-auth-library/build/src/auth/googleauth.js:524:24)
Error: An unexpected error has occurred.

If I understood what "scopes" are I might be able to figure out where to set them. So far I have only found a place to set roles and permissions in the IAM for my user.

Here are the definitions I could find:

roles & permissions (source)

A role contains a set of permissions that allows you to perform specific actions on Google Cloud resources. To make permissions available to members, including users, groups, and service accounts, you grant roles to the members.

scopes (source, source)

Access scopes are the legacy method of specifying permissions for your instance. They define the default OAuth scopes used in requests from the gcloud tool or the client libraries.

The error message arose when I tried to run firebase --debug auth:export using an OAuth token generated by firebase login:ci and applied in my script with firebase use --token. The OAuth token was generated with the Google user id that owns my Firebase project. That user has role "Owner" on the Google Cloud IAM page (i.e. https://console.cloud.google.com/iam-admin/iam).

How do I set the required scopes for my Google user id when the Google Cloud IAM page only allows you to set roles and permissions?

Answer 1

I'm not familiar with Firebase, but I do recognize this:

Error: Could not load the default credentials

This is telling you that no (application) default credentials were found. You can generate default credentials using a Google user account by executing:

gcloud auth application-default login

There's also other options. I wrote a whole blog post on application default credentials that you may find interesting.

To give you an answer to your other question, I'm afraid I'm going to get a bit wordy...

OAuth

Scopes are a term from OAuth; scopes are not specific to GCP or even to Google. OAuth is a protocol for authority delegation and is in wide use all over the internet. Understanding OAuth fully is not trivial.

The "parties" that OAuth concerns itself with are:

• resource (the GCP service you're trying to access),
• end-user (you, Michael)
• authorization server (Google account service) and
• client (in this case, the firebase CLI; the program you want to act on your behalf).

The problem that OAuth concerns itself with is the following: You, as the end-user, have the authority to act on the resource. You want a client to be able to act on the resource on your behalf. To do this, you log in with the authorization server, and get a secret token to the client; how to do this specifically is defined in detail in the OAuth spec. The resource recognizes anyone who possesses such a token as "speaking" on behalf of the end-user. By handing the client a token, you're "delegating" your end-user authority to the client.

Scopes

Anyway... Where to scopes come in? In interactions like the above, you do not necessarily want to delegate all the authority that you carry at the resource to the client. Therefore, you can bind a "scope" to the token. The scope tells the resource that the token bearer may not perform everything on behalf of the end-user, but only certain actions. What specific scopes mean is not defined by the OAuth protocol. Scopes are free-form strings, and it's the resource that should know how to interpret them.

IAM

IAM, on the other hand, is what defines the end-user's authority at the resource, that is, it defines what a Google account can do when it comes to handling GCP resources. Naturally, you a Google account cannot delegate authority to a client that it itself does not have, even if it can create tokens with very broad scopes.

If Google receives a request to, say, start a GCE instance, it will first check if the request is signed by a valid, trusted token with sufficient scopes. If the check passes, Google checks if the end-user that's "backing" the token actually has the authority to perform the requested action using IAM.

In your example above: you're the OWNER, so you have plenty of IAM permissions. However, if the token you generated does not include appropriate scopes, that token does not carry that authority, and the requests sent by firebase to GCP will not pass the first check.

Legacy?

The concept of scopes is not legacy, but the way in which GCP uses scopes to regulate processes' permissions is.

In the past, processes on GCP often ran using generic identities with very broad (IAM) permissions, such as the default compute account. The processes' permissions were limited by scoping the tokens generated for them.

IAM is much more powerful and can be defined at a more granular level as scopes. Nowadays we define custom identities with minimal permissions for different processes. Given appropriate IAM permissions, we can simply create tokens with very broad scopes, such as https://www.googleapis.com/auth/cloud-platform.