Dealing with partial consent in Google OAuth clients

When we use a tool like gcloud or IAP Desktop for the first time, we need to authorize it. Google Sign-in then shows us a consent screen that lists all the things the tool might do on our behalf (or more precisely, which scopes we’re authorizing), and and we can decide whether to consent or deny.

In the case of gcloud, the consent screen looks like this:

Notice that we only have two choices: We can consent to all four scopes by clicking Allow, or we can cancel the process. There’s no intermediate option like I’m fine with letting gcloud access my Cloud SQL instances, but not my Compute Engine instances, please.

When we authorize IAP Desktop, the consent screen looks different:

Suddenly there are checkboxes. The first two (which correspond to the openid email scopes) are checked by default and can’t be unchecked. The third (corresponding to the cloud-platform scope) is unchecked by default.

Why do these consent screens look different? And is there any way for us to influence whether a consent screen supports partial consent or not?

Partial consent

Letting users approve or deny individual scopes gives them additional control: Users can decide which resources they’re comfortable with sharing, and which resources they’d rather not provide access to. In a perfect world, the application then adapts its feature set accordingly by enabling or disabling certain functionality.

In theory, that makes a lot of sense. In practice, it’s often not that easy.

One problem is that scopes can be coarse grained. For example, IAP Desktop needs access to the Identity-Aware-Proxy API so that it can establish IAP-TCP tunnels. The only scope that covers this API is ../auth/cloud-platform. That’s a very broad scope, and by consenting access to that scope, a user is actually giving more access than IAP Desktop needs – but there’s simply no way to let users pick a more granular scope.

Another problem is that adapting the feature set based on consented scopes isn’t always possible. For example, denying IAP Desktop the ../auth/cloud-platform cripples the tool – without that scope, IAP Desktop is useless.

Unfortunately, Google Sign-In doesn’t let an application specify which scopes are mandatory and which scopes are optional. Instead, it treats all scopes as optional and apps have to be prepared to not get all the scopes they asked for.

An application can check which scopes have been authorized by inspecting the scope field in the response from the token endpoint:

{
  "access_token": "ya29.A0A…",
  "expires_in": 3599,
  "scope": "https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/userinfo.email openid",
  "token_type": "Bearer",
  "id_token": "eyJhbGci…"
}

IAP Desktop reacts to a missing ../auth/cloud-platform scope by showing a (more or less helpful) error message:

Trusted apps

Because gcloud is a Google application, it enjoys certain “privileges” that regular OAuth clients (like IAP Desktop) don’t have. One of these privileges is that its consent screen doesn’t show checkboxes.

As an administrator of a Cloud Identity or Workspace account/domain, we can decide to grant this privilege to other applications by configuring them as “trusted”.

Let’s try that for IAP Desktop:

1. Open the Admin Console and go to Security > Access and data control > API Controls > App Access Control
2. Add app > OAuth app name or client ID
3. Enter IAP Desktop and click Search
4. Select IAP Desktop and click Select
5. Select the OAuth client ID and click Select
6. Select Trusted: Can access all Google services and click Configure

Now the consent screen for IAP Desktop looks different. The checkbox is gone, and the two OpenID scopes aren’t listed at all anymore – it pretty much looks like the gcloud consent screen now:

Notice that configuring an app as trusted not only changes the consent behavior, but also exempts it from reauthentication.

Domain-owned apps are exempt

As an application developer, it’s easy to miss the perils of partial consent. That’s because OAuth clients that are registered in our own Google Cloud organization are trusted by default. To see a consent screen “with checkboxes”, we have to sign in with a user account from a different Cloud Identity Account or we need to change that default under Security > Access and data control:

• Share this article: