Who Did You Let In With a Click? Auditing App Permissions in Microsoft 365 and Google Workspace

There is a particular kind of silence in a small office after someone says: “I think I approved that.” It usually follows a demo, a free trial, or a well-meaning colleague trying to make the rota easier to manage. The app looked useful. The button said “Sign in with Microsoft” or “Continue with Google”. Nobody had to invent a password, so nobody thought much about it.

Months later, that app may still be sitting inside your tenant with permission to read mail, browse files, or see your contacts. It does not need to be malicious to be a problem. It just needs to be forgotten.

The consent button is not a login button

When someone signs in to a third-party app with their work account, they are often doing two things at once: proving who they are and granting the app permission to act on their behalf. That second part is OAuth consent, and it is easy to gloss over because the screen is designed to be clicked through.

The permissions are called scopes. A modest scope might let an app see the user’s basic profile and email address. A more generous one might allow it to read every message in a mailbox, send mail as the user, or access files in OneDrive or Google Drive. For a small UK team with no dedicated identity administrator, those grants can pile up quietly — a meeting scheduler here, a PDF signer there, a project tool someone trialled over a sandwich.

This is not about banning helpful software. It is about knowing what you have let through the door and being able to explain why.

What “risky” actually looks like

You do not need to become an OAuth specialist to spot the obvious offenders. Treat these scopes with suspicion unless there is a very clear business reason:

• Mail read access — an app that can read inboxes can see password resets, invoices, client conversations and anything else that lands there.
• Mail send access — an app that can send as a user can phish your own contacts from a trusted address.
• File access — broad access to OneDrive, SharePoint or Google Drive can expose contracts, payroll files and customer data.
• Contact access — useful for address books, also useful for mapping who knows whom.
• Offline access — this lets an app keep working after the user has logged out, which is handy for tools that need to sync in the background and less handy when nobody remembers approving them.

A scheduling app that reads your calendar may be reasonable. A “free CV builder” that wants to read all your mail is not. The question is not whether an app is popular. It is whether the permission matches the job.

The twenty-minute sweep

The aim is not a perfect inventory. It is a first pass that removes the obvious clutter and gives you a list to take to whoever owns the budget.

Microsoft 365

1. Sign in to the Microsoft Entra admin centre with an account that can manage applications. In many small tenants this will be the same person who set up the tenant.
2. Go to Identity > Applications > Enterprise applications. Set the filter to All applications and look for names nobody recognises.
3. For each suspicious app, open it and check Permissions. Look at both delegated permissions (acting as a signed-in user) and application permissions (acting without a user).
4. Check Users and groups to see who is actually assigned or consented. An app with no users may still have a tenant-wide grant.
5. If the app is no longer needed, remove the enterprise application or revoke its consent. If you are unsure, disable sign-in first and ask the team.

You can also review user consent settings under Enterprise applications > Consent and permissions > User consent settings. If users can consent to apps themselves, decide whether that still suits your team. Many small organisations find it safer to require admin approval for anything beyond basic profile access.

Google Workspace

1. In the Google Admin console, go to Security > Access and data control > API controls.
2. Open App access control and review the list of third-party apps with access to Google Workspace data.
3. Look at the scopes for each app. Google labels some as restricted or sensitive; read the descriptions rather than trusting the app’s own marketing page.
4. Check whether access is trusted, limited or blocked. If an app is unused, remove its access.
5. Ask users to review their own connected apps at myaccount.google.com > Security > Third-party apps with account access. A short email with that link is often enough to surface the guilty parties.

While you are there, look at API controls > App access control settings for whether users can install unapproved apps. If anyone in the team can grant access without a second look, that is a policy decision worth making deliberately rather than by default.

A simple triage rule

When you find an app you do not recognise, ask four questions:

1. Does anyone still use it? If nobody can name the person or the process, it is a candidate for removal.
2. Does the permission match the purpose? A rota tool needs calendars. It does not need mail.
3. Who approved it, and when? If there is no answer, treat it as unapproved.
4. What would we lose if we revoked it today? If the answer is “nothing obvious”, revoke it and see who shouts.

That last step is not reckless. It is a controlled test with a short feedback loop. Tell the team what you are doing, remove the least defensible grants first, and keep a note of what changed.

The next “Sign in with Microsoft” request

You do not need a procurement department to stop the next messy consent. You need a rule that everyone understands: no work account signs in to a third-party app without a named owner and a reason.

A lightweight approval note can be three lines: the app name, the person who needs it, and the business task it supports. Keep it in a shared document or a ticket. When the request arrives, check the scopes before clicking approve. If the app wants mail or file access, ask why. If the answer is vague, suggest a narrower alternative or a manual export.

It also helps to do this sweep quarterly, or at least before the next renewal season when someone suggests another tool. Twenty minutes now is cheaper than explaining to a client why an abandoned trial still had access to their correspondence.

Small teams do not need a formal identity programme to get this right. They need a habit: look at what has been let in, remove what nobody can defend, and make the next consent a conscious decision rather than a lunchtime reflex.