How to investigate OAuth grants and administrator changes

1. Preserve the OAuth token event

Google's token activity report includes events such as authorize, request, deny, revoke, and application activity. An authorization event can identify the actor, application name, client ID, client type, and granted scopes. Preserve those fields and the original timestamp before the application or grant changes.

An authorize event establishes that access was granted under the reported scopes. It does not prove that the application used every scope, accessed particular content, or acted maliciously.

Google reference: OAuth Token Audit Activity Events

2. Pivot to administrator activity

The administrator activity report records Admin console changes and supports filtering by administrator, UTC time bounds, and event name. Search the smallest useful window around the OAuth event, then widen it deliberately if the sequence remains unclear.

Prioritize changes to users, delegated administrators, security settings, domains, groups, applications, and organization settings. Record the exact event name and supplied old or new values rather than reducing every administrator event to a generic “settings changed” label.

Google references: Admin Activity Report and administrator event names

3. Reconstruct the evidence sequence

OAuth actor

Which user authorized, requested, denied, or revoked access?

Application

Do the application name, client ID, client type, and scopes match an approved tool?

Administrator

Which administrator changed a user, role, security setting, or application policy?

Login context

Was there a nearby explicit password or SAML login worth validating with the user?

UTC order

Which event occurred first, and are reporting delays or missing streams relevant?

Change record

Does a ticket, owner confirmation, or onboarding task explain the sequence?

4. Example: an unfamiliar application receives access

This hypothetical example is an investigation pattern, not a customer incident. A token event reports that a user authorized an unfamiliar web application for several scopes. Ten minutes later, an administrator event records a security-setting change affecting the same user.

1. Preserve both source records, their UTC timestamps, actors, event names, application identifiers, scopes, and reported targets.
2. Ask the user whether they initiated the authorization and confirm the application's owner and intended purpose.
3. Verify whether the administrator event has an approved task and whether its supplied parameters identify the setting that changed.
4. Inspect nearby login activity for the user and administrator, while remembering that the login report does not cover every authentication path.
5. State the bounded conclusion: the grant and administrator change were observed close together; causality, intent, and downstream data access remain unproven.

5. Keep source coverage visible

Google Workspace exposes multiple audit applications. A search of token, admin, and login activity is not complete coverage of Gmail, Drive, every authentication path, or the full Workspace directory. History, lag, available parameters, and subscription requirements can vary.

Flare's current Workspace connector reads login, admin, and token Reports API activities for one verified customer. It does not read Gmail or Drive content, other Reports applications, or a full directory. Treat findings as investigative leads and preserve unresolved questions.

Google reference: Reports API activities.list