Google OAuth app access blocked: identify the policy owner

Define the decision

A blocked consent screen may be controlled by the organization rather than the user. Capture the exact wording, selected account and application identity; a general screenshot saying login failed omits the information an administrator needs.

Work through the procedure

1. Confirm the intended Workspace account was selected.
2. Record the app name, client identity shown and sanitized error.
3. Ask the administrator to review the relevant app access policy and requested services.
4. If the message instead names a redirect or client configuration problem, route it to the deployment operator.
5. Retry once the responsible setting is corrected.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Error class: administrator has restricted this app
Owner: Workspace administrator
Evidence: account domain, app identity, requested access
Unhelpful retry: switching browsers without changing the policy

Read the result

The owner split saves time and avoids broad security changes. Approval of basic sign-in scopes does not necessarily authorize the mail access needed for SMTP and IMAP.

Check before moving on

1. Never include an authorization code or token in the ticket.
2. Recheck mailbox functionality after consent succeeds.

Limits and next action

Only an authorized administrator should change organizational access policy. Do not advise users to bypass controls using a different personal account.

Source: Google: control app access to Workspace data