Every time you connect Gmail to a new app, a screen shows up listing permissions in Google's own careful language: “Read, compose, send, and permanently delete all your email from Gmail.” Most people click Allow without parsing that sentence. This post breaks down what these scopes actually mean, in plain English, and how to check what you have already granted across every app you have ever connected.
What a scope is
An OAuth scope is a specific, named permission a third-party app requests from Google. When you connect an app, Google shows you the scopes it is asking for, you approve or deny, and Google issues a token limited to exactly those scopes. The app never sees your password. It only gets what the token allows.
Scopes are granular in theory. In practice, a handful of common ones cover almost everything an email client needs, and they differ a lot in how much access they grant.
The Gmail scopes that matter
gmail.readonly. Read-only access to your entire mailbox: every message, every label, every attachment. No sending, no deleting, no modifying. This is the narrowest scope that still lets an app show you your mail.
gmail.send. Send mail as you, using your address. No read access. An app with only this scope can send email on your behalf but cannot see what is already in your inbox. Rare to see alone; usually paired with something else.
gmail.modify. Read, send, and modify (archive, label, mark read or unread, move to trash) but not permanently delete. This is the scope most full-featured email clients need, including STAMP: we need to mark messages read, apply labels, and archive on your behalf.
gmail.compose. Create and send drafts, but not read the rest of your mailbox. Used by apps that only need to draft on your behalf, like some scheduling or template tools.
mail.google.com (full access). The broadest scope. Everything above, plus permanent deletion, plus settings changes like forwarding rules and filters. This is the scope Google's consent screen describes with the “permanently delete all your email” language, because it can. Very few legitimate consumer apps need this. If an app requests it and you are not sure why, that is worth pausing on.
userinfo.email / userinfo.profile. Not mail access at all: just your email address and basic profile info (name, photo), used for login and identifying which account is connected. Nearly every app requests this alongside a mail scope, and it is low-risk on its own.
What STAMP requests, and why
STAMP requests gmail.modify and userinfo.email. That is read, send, archive, label, and mark-as-read, which is what triage requires, plus enough profile info to show you which account you are looking at. We do not request full account access (mail.google.com), and we do not request access to Calendar, Contacts, Drive, or any other Google product. If a consent screen ever shows STAMP asking for more than that, something is wrong and you should not approve it. Because credentials live in the macOS Keychain rather than in application storage, the token itself is encrypted at rest and scoped to the app that requested it.
How to check what you have already granted
You do not need to remember every app you have connected over the years. Google keeps a full list.
- Go to myaccount.google.com/permissions.
- You will see every third-party app with any access to your account, grouped by how much access they have.
- Click into any app to see its exact scopes, listed in the same plain language as the original consent screen.
- For anything you do not recognize, or do not use anymore, click Remove Access.
Do this once a year at minimum. It is common to accumulate a long tail of apps you connected once, years ago, for a single task, and forgot to revoke. Each one is still holding a live token unless you remove it.
What over-scoping looks like in practice
A calendar-scheduling tool that requests full Gmail access instead of gmail.readonly is over-scoped: it does not need to send or delete your mail to read your availability. A newsletter-unsubscribe tool that requests mail.google.com instead of gmail.modify is over-scoped: unsubscribing needs to send one email and maybe archive, not delete your whole mailbox or change your forwarding rules.
Over-scoping is not always malicious. Sometimes it is laziness (broad scopes are simpler to request once and never revisit) or a legacy decision nobody has updated. But laziness with your inbox access is still a real exposure if that company is ever breached, subpoenaed, or acquired by someone with different intentions. The scope an app holds is the scope an attacker gets if that app's systems are compromised.
The five-second check before you click Allow
Before approving any OAuth consent screen, read the specific permission list, not just the app name and logo. Ask: does this app's stated purpose match the access it is requesting? A read-only newsletter digest tool asking for full Gmail access does not pass that check. A full-featured email client asking for read, send, and modify does.
Where to go from here
For how OAuth fits into the full connection flow (SMTP, IMAP, and token storage), IMAP, SMTP, OAuth, explained. For how to verify a client's other privacy claims yourself, what “on-device” actually means.
Scoped access, nothing more. hello@stamp.email