Also read - OAuth Overview - and OAuth Consent Screen. Also, remember that OAuth is for Authorization (to protected resources) and not so much for plain authentication. Authentication is more often handled by OpenID Connect.

Distinguish between User Data and Project Level Resource Data

  • This OAuth 2.0 flow is specifically for authorization (authorizing USERS or APPs to access protected resources). It is designed for applications that can store confidential information and maintain state. A properly authorized web server application can access an API while the user interacts with the application or after the user has left the application.
  • Web server applications frequently also use service accounts to authorize API requests, particularly when calling Cloud APIs to access project-based data rather than user-specific data.
  • Web server applications can use service accounts in conjunction with user authorization.

Why do we need Authorization Tokens in GCP?

  • Calling APIs in GCP needs either AUTHORIZATION Tokens or API Keys (or BOTH).
  • Typically, it is Service Accounts (non human user) that are used to make these calls.
  • Typically, these Service Accounts are used from within an application (could be a web app, a mobile app or a desktop app)
  • Use cases that require short term access to GCP resources also need authorization tokens (This is done via a lifetime parameter on the access token: The amount of time until the access token expires, in seconds. For example, 300s)

Which API (in GCP) is responsible for generating the Access Tokens (OAuth Access Tokens)?

The Service Account Credentials API's serviceAccounts.generateAccessToken method generates an OAuth 2.0 access token for a service account.

Before using any of the request data below, make the following replacements:

  • sa-name: The name of the service account that you want to create a token for.
  • project-id: Your Google Cloud project ID.
  • delegates: If you are using a delegated request flow, see Specifying a delegation chain on this page. If you are using a direct request flow with no delegation, omit the delegates field in the request body.
  • scopes: The OAuth 2.0 scopes for the request. The following scopes are valid when calling the generateAccessToken API:
    • "https://www.googleapis.com/auth/iam"
    • "https://www.googleapis.com/auth/cloud-platform"
  • lifetime: The amount of time until the access token expires, in seconds. For example, 300s.By default, the maximum token lifetime is 1 hour (3,600 seconds). To extend the maximum lifetime for these tokens to 12 hours (43,200 seconds), add the service account to an organization policy that includes the constraints/iam.allowServiceAccountCredentialLifetimeExtension list constraint.

Resource Manager API

Requests to the Resource Manager API for non-public user data must be authorized by an authenticated user.

When your application requests public data, the request doesn't need to be authorized, but does need to be accompanied by an identifier, such as an API key.

Every request your application sends to the Resource Manager API needs to identify your application to Google. There are two ways to identify your application: using an OAuth 2.0 token (which also authorizes the request) and/or using the application's API key.

  • If the request requires authorization (such as a request for an individual's private data), then the application must provide an OAuth 2.0 token with the request. The application may also provide the API key, but it doesn't have to.
  • If the request doesn't require authorization (such as a request for public data), then the application must provide either the API key or an OAuth 2.0 token, or both—whatever option is most convenient for you.

Exchange OAuth Authorization Code for Short Term Tokens

Requests to the Resource Manager API for non-public user data must be authorized by an authenticated user.

The details of the authorization process, or "flow," for OAuth 2.0 vary somewhat depending on what kind of application you're writing. The following general process applies to all application types:

  1. When you create your application, you register it using the Google Cloud Console. Google then provides information you'll need later, such as a client ID and a client secret.
  2. Activate the Resource Manager API in the Google Cloud Console. (If the API isn't listed in the Cloud Console, then skip this step.)
  3. When your application needs access to user data, it asks Google for a particular scope of access.
  4. Google displays a consent screen to the user, asking them to authorize your application to request some of their data.
  5. If the user approves, then Google gives your application a short-lived access token.
  6. Your application requests user data, attaching the access token to the request.
  7. If Google determines that your request and the token are valid, it returns the requested data.

Need a hands-on, GCP Consultant?

Need help with your GCP journey?  Start the conversation today.  



Need an experienced Data Protection Expert?  Anuj has successfully delivered over a dozen deployments on each of the public clouds (AWS/GCP/Azure) including several DevSecOps engagements. Set up a time with Anuj Varma.