Consent screens and the impact of administrative controls
When users sign in to an application that uses Google OAuth or OpenID Connect, they typically see a consent screen. But there’s more than one type of consent screen, and the type of consent screen that users end up seeing not only depends on the publisher, but also on the administrative controls applied on the consumer side.
Let’s take a look at the various consent screens that we might see as a user:
No consent: We might see no consent screen at all. This happens when the application doesn’t request any information or data access – but as we’ll see later, it can happen in other cases as well.
Identity consent: When an application requests user information but no data access, we typically see a simple consent screen like the following:
Full consent screen: When an application requests user information and data access, we might see a sequence of two screens:
Full consent screen with granular permissions: As a variation of the previous case, we might see a sequence of two screens where we need to manually check each scope:
The idea here is that we’re given the option to grant partial consent, where we might consent to one scope, but not to another.
Access blocked: Finally, if we’re unlucky, we might not see a consent screen at all and see one of these errors instead:
The publisher side
As a publisher of an application, thee are 3 things we can control that impact consent screen behavior:
Choice of scopes: We can choose the list of scopes to request consent for.
Note that what matters here is the list of scopes in the sign-in request, which can be a subset of the list of scopes configured in the consent screen.
If any of the requested scopes is restricted or sensitive, users will typically see a full consent screen. If we request more than one scope, that consent screen will use granular permissions (checkboxes).
Type of client (Desktop or Web): While this choice is typically forced upon us, it does impact consent screen behavior in two ways:
First, Desktop clients are subject to stricter rules w.r.t. the Google Cloud session length control. While Web clients retain consent when the session expires, Desktop clients loose their consent.
Second, and as we’ll see later, the type of client also matters when configuring domain-wide delegation.
Visibility: We can set an application’s visibility to internal so that users outside our own Cloud Identity/Workspace account can’t use the application at all, or set it to public.
The consumer side
As the Cloud Identity or Workspace administrator on the consuming side, we have a set of administrative controls at our disposal that all influence consent behavior:
Domain-wide delegation: We can configure domain-wide delegation for an OAuth app, which grants consent on behalf of our users.
Domain-wide delegation is primarily known (and somewhat infamous) for letting service accounts impersonate other users. But when we configure domain-wide delegation for an OAuth app’s client ID (as opposed to a service account’s client ID), the effect is that it suppresses the consent screen.
App restrictions: We can configure third-party app access and categorize individual apps as Trusted, Limited, or Blocked.
Internal apps: We can control whether internal apps should automatically be considered Trusted.
Unconfigured apps: We can decide whether to allow or block access to unconfigured apps.
Service restrictions: We can configure individual Google services to be restricted. Restricted services can only be accessed by Trusted apps.
Note that restricted services are not the same as restricted scopes, because that would be too easy.
The user side
Now let’s see how all these controls interact with another and determine which type of consent screen users end up seeing.
In the following flow chart, blue diamonds correspond to the 3 factors controlled by the publisher, yellow diamonds correspond to the 5 administrative controls (click to enlarge):
