# Fix Google OAuth 403 access denied by admin policy

## TL;DR
Access denied by admin policy means the Google Workspace admin has blocked the app, not that your code is wrong. The admin must allow-list the app in the Admin console under API controls. End users cannot fix this themselves.

## The error
```text
Google OAuth failed
Error 403: access_denied. The administrator has blocked this app.
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=google oauth error 403 access denied admin policy"
```

## Fix it

### Step 1: Confirm the block in the Admin console

```bash
Google Admin -> Security -> Access and data control -> API controls -> Third-party access.
```

Expected: The app shows as blocked for the user's org unit.

### Step 2: Allow-list the app

```bash
Change the app's access setting to trusted for the relevant org units and save.
```

Expected: The app shows as trusted.

### Step 3: Check the OAuth scopes requested

```bash
Confirm the scopes the app requests are ones the admin policy permits.
```

Expected: No requested scope is on the restricted list without approval.

### Step 4: Have the user retry the OAuth flow

```bash
The user runs the Google OAuth flow again.
```

Expected: The flow completes instead of showing 403.

### Step 5: Document the allow-list requirement

```bash
Add the allow-list step to your onboarding docs for Google Workspace customers.
```

Expected: Future installs include the admin step up front.

## When this applies

- Google OAuth fails with 403 access denied by admin policy
- An app works for consumers but not for Workspace users
- You are onboarding Google Workspace customers

## When it doesn't

- The error is about unverified app screens (that is the verification flow)
- The admin allowed it and it still fails (check the org unit scoping)
- The error names a specific scope (request a narrower scope)

## Compatibility

Google OAuth 2.0 with Google Workspace admin API controls.

## Variant phrasings

### google oauth blocked by administrator

Same condition. Only a Workspace admin can unblock; the user and the developer cannot.

### error 403 access_denied google workspace app

The 403 wrapper is the same admin block. Check third-party access settings first.

### google admin blocked third party app oauth

Bulk blocks happen when admins restrict all third-party access. The app needs an explicit trust entry.

## Why it happens

Google Workspace admins can block third-party API access org-wide. When they do, every OAuth flow for the blocked app fails with 403 before the user even sees a consent screen. It is a policy decision on the customer's side, not a defect in the app.

## Edge cases

- Blocks can be scoped per org unit; the app may work for one team and fail for another
- Restricted scopes need admin approval even for trusted apps; check the scope classification
- After allow-listing, propagation can take several minutes

## If it still fails

- Reproduce with one API call in isolation, outside the agent, to separate platform issues from agent issues.
- Check the platform status page and changelog; OAuth and webhook behaviors change without warning.
- Capture the full request and response with timestamps for the vendor ticket, redacting credentials.
- Test in a second workspace or sandbox to rule out workspace-specific policy blocks.
- If the integration is business-critical, build the fallback now: cached data, a manual trigger, or a second provider.

## Prevention

- Store OAuth credentials in a secrets manager with rotation reminders.
- Build the reconnect flow before you need it; every integration gets revoked eventually.
- Log token ages so expiring grants are visible ahead of time.
- Keep a sandbox integration for testing config changes.
- Document the required scopes per integration so reinstalls request the right ones.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_irEQvfc_K366ER04Gi0Lpg