Third-Party App Access Auditor for University and School Google Workspace Accounts

The problem: thousands of quiet grants to students' email and files

Universities and schools across Pakistan and elsewhere give students and staff Google Workspace accounts. Every time someone clicks "Sign in with Google" on a study tool, a PDF converter, an AI note-taker or a browser add-on, they may grant that app access to their mail, files or calendar. Some apps ask for far more than they need. Some are run by people nobody can identify.

A single staff account that granted full mailbox access to a malicious app can leak exam papers, student records or password reset emails for other systems. Consent phishing, in which an attacker tricks users into granting access to a malicious app rather than stealing a password, bypasses passwords and two-step verification entirely. Most institution IT teams have never seen the full list of connected apps.

What already exists and the gap

• The Google Workspace Admin console lets administrators see accessed apps and set each one as trusted, limited or blocked, and since late 2024 configure access by specific API scopes. It does not rank risk or build a review routine, and Google does not block risky apps automatically.
• Commercial SaaS security tools discover connected apps and score them, priced for companies.
• Google's own reports provide token activity, but as raw events.

The gap is a free, simple tool built for an institution's small IT team: pull the data, rank it sensibly, present a short weekly review and make the action one click.

Inspiration

RFC 9700, "Best Current Practice for OAuth 2.0 Security" (IETF, January 2025), updates the OAuth threat model with lessons learned since OAuth 2.0 was published. Google's own guidance on controlling third-party app access, including its list of high-risk Gmail and Drive scopes, gives a ready starting point for a risk model. This project turns that guidance into routine practice for institutions.

What you build

• IT administrators get a ranked list of connected apps, a weekly queue of new or risky ones and buttons to trust, limit, block or revoke.
• Security leads see trends: how many accounts have granted full mailbox access, and whether that is going down.
• Students and staff can read a short explainer on what an app can do before connecting it.

The technically interesting part

• Collecting the data correctly. Use a service account with domain-wide delegation, page through token events for thousands of users, and respect API quotas. Store only what the review needs.
• A scope risk model. Rank scopes from "see your basic profile" to "read, send and delete all your email". Combine scope with publisher verification, the number of users and how long the app has been seen.
• Spotting campaigns. Many users granting the same unknown app within an hour is a strong sign of consent phishing, even if each grant looks harmless.
• Safe actions. Revoking tokens can break tools people rely on. Show who will be affected first, log every action and allow undo where possible.
• Telling users why. When an app is blocked, the people using it need a short, polite explanation and a safer alternative, or they will find a workaround. Draft templates for the common cases.
• Least data. The auditor itself becomes a sensitive system because it knows who uses what. Keep only app identifiers, scopes and counts where possible, restrict who can open the dashboard and log every view.

How to evaluate it

• Test domain: create a Workspace test domain with test users and apps of varying risk, including a fake over-permissioned app, and check ranking and flags.
• Pilot: with permission, run read-only for a department and record how many apps and risky grants were found, and how long a review takes.
• Usefulness: interview IT staff about whether the queue matches what they would worry about.

Suggested plan

• Weeks 1 to 3: Admin SDK basics, service account setup and a test domain.
• Weeks 4 to 7: collector, inventory and scope risk model.
• Weeks 8 to 11: dashboard, review queue and actions.
• Weeks 12 to 15: pilot, refinements and report.

Path to a product

Universities, school networks and small companies all run Google Workspace with thin IT teams. A free self-hosted tool with paid setup and support, or a small hosted service, is realistic. It is also a strong portfolio project for cloud security and IT operations roles.

Scope warning

Work only on a test domain or with explicit written permission from the institution, and read data, not email contents. Start with Google Workspace; Microsoft 365 is a stretch goal.

Learn what you need on Sefism

• Cybersecurity roadmap: identity, access and cloud account security.
• OWASP Cheat Sheet Series: OAuth and authorisation guidance.
• Backend development roadmap: APIs, OAuth and building the collector.
• Where do I start if I want a career in cybersecurity or IT operations?: where IT security work leads.
• ISC2 Certified in Cybersecurity (CC): the access control basics this project applies.

Get help with this idea

This is a practical first security project with a clear user. Tauseef can help you design the risk model, set up a safe test domain and approach an institution for a pilot. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session