Fixing Google SSO issues: 'Access blocked' and unexpected logouts

Two different problems, one sign-in system

Arc apps offer Google single sign-on (SSO), so staff and students sign in with their school Google account. Two separate things can interrupt that — and both can appear after weeks or months of normal use, because nothing has to change on your end or Arc's for either one to start. This guide covers both.

Problem A — "Access blocked" at sign-in. The user sees "Access blocked: Your institution's admin needs to review [Arc app]" with Error 400: access_not_configured, and cannot sign in at all. This is a Google Workspace setting: the app needs to be marked Trusted in your district's Admin console.

Problem B — signed in, then locked out. Users can sign in, but keep getting logged out or the app stops responding to their account. This is almost always the school or district web filter blocking a domain the app depends on.

If you're not sure which one you have: an explicit error screen at the Google sign-in step means Problem A; sign-in that works but doesn't stick means Problem B. When in doubt, apply both fixes — they don't conflict, and together they cover the full sign-in path.

Problem A: "Access blocked" (Error 400: access_not_configured)

What this error means

This is not an outage, a bug, or a security problem with the app. It's a standard Google Workspace for Education setting: students designated as "under 18" by your age-based access policy are automatically blocked from any third-party app that has never been explicitly configured (as Trusted, Limited, or Blocked) in your Admin console — even if that app has been in use at your school for months or years.

This most commonly resurfaces at the start of a new school year, when rosters, org units, or age designations are refreshed and previously-approved apps can fall back to an "unconfigured" state.

How to fix it (5–7 minutes)

1. Sign in to the Google Admin console at admin.google.com with an account that has the Service Settings admin privilege.

2. Go to Menu → Security → Access and data control → API controls.

3. Click Manage Third-Party App Access.

4. Click Configure new app → OAuth App Name Or Client ID.

5. Search using the app name or paste the exact Client ID from the table below — the Client ID is the most reliable way to find the correct app. Note that Arc apps may appear under "UDBapp", "Ultimate Drill Book", or the app's domain, depending on how Google lists them.

6. Select the app, then set the access level to Trusted.

7. Apply the setting to the organizational unit(s) that need access (or your top-level OU to cover the whole domain), then click Confirm.

Access is typically restored within a few minutes.

Arc OAuth Client IDs

Use these to locate each Arc app directly in step 5 above, rather than relying on search-by-name:

Note: Geo, Beam, and UDB Blue (Android) each also have a separate "Play Market" OAuth client for the Play Store–signed build, which is not listed above. If the Android IDs above don't match the Client ID shown in a student's "error details," check with Arc support — the Play Store build may be the one in use at that district.

If you'd rather review the request first

If a student has already clicked "Request Access" on the error screen, the app will also appear under API controls → Apps pending review, where you can approve it directly from the request.

Problem B: signed in, then locked out

What causes it

Your school or district's web filter (Lightspeed, GoGuardian, Securly, or similar) periodically re-scans and re-approves the sites it allows through. Arc's address can get swept up in one of those re-scans and start being blocked, even though it was approved when you first set up. When the app can no longer reach Arc's servers or Google's sign-in endpoints, it can't confirm the user is still signed in — so it logs them out.

Network / firewall allowlist

Ask IT to allow the following domains:

Allow these as domains, not fixed IP addresses (Google's and Arc's IP ranges change, but the domains don't). If the filter supports it, exclude them from SSL/HTTPS inspection, since re-inspecting an encrypted sign-in session is a common cause of intermittent failures.

Also check the Workspace side

The same third-party app access setting from Problem A can produce rolling logouts too, since Google enforces it on a rolling basis. If Arc appears under "unconfigured third-party apps" in Admin console → Security → API controls → App access control, move it to the trusted list using the steps in Problem A so it doesn't get swept up in a periodic security review.

If it keeps happening

Ask IT whether the web filter's re-scan schedule or the Workspace access review cycle lines up with when the problems started — that's usually the giveaway for which one it is. If both check out and users are still blocked or being logged out, contact Arc support with the date and time it started, the account(s) affected, and — for Problem A — the "error details" text from the block screen (tap "error details" on the error page and copy the full text). It confirms exactly which app and Client ID Google is blocking, and lets us cross-check against our sign-in logs.

Questions

Arc Support · support@ultimatedrillbook.com · 844-368-2665 · Knowledge base: help.joinarc.us