Tracking User Account and OAuth in Google Workspace (Without Losing Your Sanity)

4 hours ago
5 min read

If you’ve ever had to investigate a Google Workspace account takeover, you already know one thing: it’s not about one log — it’s about connecting multiple logs and understanding how Google thinks.

The Two Logs You Must Know

When it comes to tracking user behavior (and especially account compromise), there are four core log types you’ll always come back to:

Admin log events
User log events (Previously it was seperated into two logs) (Login Audit Log + User Accounts Audit Log)

Think of these as different camera angles. One log alone never tells the full story — but together, they usually do.

Log Retention: The 6-Month Trap

By default, Google Workspace retains these logs for six months. And here’s the annoying part:

You cannot extend retention inside the Admin Console
There is no “keep logs longer” checkbox

If you want long-term visibility (and you absolutely should), the only solution is to:

Export logs to Google Cloud Logging
Configure extended retention there

Google Cloud allows log storage for up to 10 years, which is a lifesaver for compliance, threat hunting, and delayed investigations.

Log Lag Time: Why “Too Early” Is a Real Problem

One thing that trips up a lot of investigators is log availability delay.

Each of logs has a different lag time before events become searchable. And that lag time should be treated as the minimum waiting period, not a guarantee.

So if you search immediately after an incident and think,

“This doesn’t make sense…”

…it probably doesn’t — yet.

Rule of thumb: Never rely on searches run shorter than the documented log lag times. Some events just arrive late.

Admin log events: Start Here for Admin Compromise

The Admin Log evets is your go-to log for anything that happens inside the Google Admin Console.

It tracks:

Admin actions
Configuration changes
Policy updates
Organization-wide modifications

If you suspect an admin account compromise, don’t overthink it — this is the first log you check. It tells you exactly what changes were made and by which admin account.

User log events: Where the Action Is

The User log events is where most account takeover investigations spend their time.

This log captures:

Successful and failed logins
Re-authentication prompts
MFA changes
Security challenges triggered by Google

It doesn’t just tell you that someone logged in — it tells you how, why, and under what conditions.

Understanding Login Types (This Matters)

Each login event includes a Login Type, which explains how the authentication happened.

Some common ones you’ll see:

Google Password – Standard username + password login
ReAuth – Google forced the user to re-authenticate
SAML – Login via SSO
Exchange – OAuth or existing token-based session
Unknown – Login occurred using an unidentified method (always worth a closer look )

When you’re hunting suspicious activity, “Unknown” and unusual patterns in login types are often gold.

Warning Icons = Pay Attention

In the User log events, some events show a warning icon. These usually indicate unusual or suspicious logins, such as:

New IP addresses
Unfamiliar locations
Behavior Google flags as risky

Instead of scrolling endlessly, a smart approach is to hunt by event type.

Login Event Types Investigators Care About

Here are some high-value event types you should always keep an eye on:

2-step verification disabled – Big red flag
Account password change – Especially if unexpected
Failed login – Useful for brute-force patterns
Government-backed attack – Google explicitly flagged a known threat actor
Leaked password – Password found in credential dumps
Suspicious login – Unusual characteristics detected
Out-of-domain email forwarding enabled – Common data exfil trick
User suspended – Often triggered by Google due to abuse or compromise

Important note: Some details (like why a login failed) are not visible in the Admin Console and require pulling logs via the API.

-------------------------------------------------------------------------------------------------------------

OAuth

Let’s be honest — OAuth sounds way more complicated than it actually is.

At its core, OAuth is just a permission slip.

Instead of giving an app your username and password (which is a terrible idea), OAuth lets you say:

“Hey, this app can read my emails, but nothing else.”

That’s it. That’s the magic.

So What Exactly Is OAuth?

OAuth is an authorization mechanism — not authentication.

It doesn’t prove who you are
It proves what an app is allowed to do

When an application wants to access your data through an API (emails, Drive files, contacts, calendar, etc.), OAuth sits in the middle and asks you for permission.

If you say yes, the app gets a token. That token is like a digital key that says:

“This app is allowed to access these specific things, on behalf of this user.”

No password sharing. No repeated logins. Cleaner and safer.

Why OAuth Exists (And Why Everyone Uses It)

Imagine if every app you used asked for your Gmail password. Nightmare.

OAuth solves a few big problems:

You don’t have to re-authenticate every time
Apps never see your actual credentials
Access can be limited (scope-based)
Tokens can be revoked anytime

That’s why OAuth is everywhere — Google Workspace, Microsoft, GitHub, Slack, Twitter (X), basically everything modern.

OAuth in Google Workspace (What Users Actually See)

Inside Google Workspace, OAuth usually shows up as that familiar screen:

“This app wants access to your : GmailDrive filesContacts”

That list? Those are called scopes.

Scopes define exactly what the app can touch. Nothing more.

Once the user clicks Allow, Google generates an OAuth token, and the app can start making API calls using that token.

Important point: OAuth is enabled by default in Google Workspace unless admins restrict it.

Where Things Go Wrong: OAuth Abuse

Here’s the problem — OAuth is secure, but humans are optimistic.

Threat actors figured out something clever:

“Why steal passwords when we can just ask nicely?”

The Basic OAuth Attack Chain

Attacker creates a malicious app
Victim gets a phishing email with a link
Victim clicks → sees a legit Google OAuth screen
Victim clicks Allow
Attacker now has access — no password needed

No malware. No credential theft. No MFA bypass required. Just consent.

Why Threat Actors Love OAuth

OAuth attacks are attractive because:

No credentials to steal
MFA doesn’t stop it
Looks completely legitimate
Uses official Google infrastructure

And the scariest part?

OAuth does NOT give attackers more access than the user already has — but that’s usually more than enough.

Detecting OAuth Abuse in Google Workspace

Google Workspace actually gives us solid visibility here.

Oath Log events

These logs show:

Which user authorized which app
Application ID
Scopes granted
API activity performed using the token

If you pull these logs via API, you get even more gold:

Source of the request
Which Workspace service was accessed
How much data was returned
Client type and product bucket

This is huge for investigations and retroactive analysis.

Killing the Access: Revoking OAuth Tokens

A few important things defenders should know:

Changing a user’s password revokes OAuth tokens
IMAP tokens can take up to an hour to expire
Admins can:
- Review all third-party apps
- See who authorized them
- Block apps org-wide

In the Admin Console, you can quickly identify sketchy apps by:

Unusual scopes
Non-verified apps
Excessive permissions

Block once — and it impacts the whole org.

The Big Takeaway

OAuth isn’t insecure. Blind trust is.

OAuth attacks succeed because:

Users trust the Google consent screen
App names look legitimate
No passwords are involved (so alarms don’t go off)

Defenders need to:

Monitor Token Audit Logs
Restrict third-party apps
Educate users that “Allow” is a powerful action

Because sometimes, clicking Allow is worse than typing your password.