Read-only OAuth for Gmail and Outlook: a setup guide that explains itself

Connecting an inbox to a third-party app makes most people uneasy, and it should. The good news is that the modern flow gives you real control — if you know what to look at. Here is what happens under the hood and what to check before you approve anything.

What OAuth is doing

When you click "Sign in with Google", you are redirected to a page hosted by Google itself. You authenticate there. The application never sees your password — it cannot, because the credential is never sent to it. What comes back is an access token: a scoped, expiring, revocable key that says "this app may do these specific things with this account".

Three properties of that token matter. It is scoped, so it grants specific permissions rather than account access. It expires, so a leaked token has a short shelf life. And it is revocable from your account settings, without involving the app at all.

Reading the consent screen properly

The consent screen lists scopes in plain language, but the wording rewards close reading. For a task-extraction tool you want to see read-only language and nothing more:

• "View your email messages and settings" — read-only. Correct for this use case.
• "Read, compose, send, and permanently delete all your email" — full mailbox control. Far too broad for extracting tasks.
• "See, edit, create, and delete all of your Google Drive files" — full Drive access. Only accept if the feature you want genuinely requires writes.

If an app requests more than its stated function needs, that is the signal to stop. Excess scope is not usually malice — it is often laziness during development — but the risk lands on you either way.

Microsoft 365 and Outlook

The Microsoft identity platform works the same way with different vocabulary. The scope you want is Mail.Read rather than Mail.ReadWrite. On a work account, an administrator may need to grant consent on behalf of the tenant — if you see "Need admin approval", that is what is happening, and it is a feature rather than a problem.

For administrators

Before granting tenant-wide consent, review the publisher verification status and the exact permission list in the Azure portal. Tenant consent applies to every user in the organisation, so it deserves the same scrutiny as any other org-wide change.

Verifying what an app can actually see

Do not take the marketing page as evidence. Check the source of truth for yourself:

1. 1For Google: open myaccount.google.com, then Security, then "Your connections to third-party apps & services". Every connected app is listed with its exact granted scopes.
2. 2For Microsoft: open myapplications.microsoft.com, then the app tile, then Permissions.
3. 3Compare the granted scopes against what the app claims to need. Any gap is worth an email to the vendor.

Revoking access

This is the part worth rehearsing once so you know it takes under a minute. In the same Google or Microsoft screen, select the app and choose Remove access. The token is invalidated immediately at the identity provider. The application cannot prevent this, delay it, or require you to contact support first.

The right question is not "do I trust this app?" but "what happens if I stop trusting it?" With OAuth, the answer is: you click one button and it is over.

A short pre-flight checklist

• Scopes are read-only unless a write feature is the reason you are installing.
• The publisher is verified and the name matches the vendor you researched.
• The privacy policy states plainly what leaves your device.
• You have located the revocation screen before granting, not after.

Taskify requests read-only Gmail and Outlook scopes and stores its access token locally on your device. If you ever want it gone, revoke at the provider and every trace of access ends at that moment.