Email OAuth Permissions: Read a Mail App Consent Screen

OAuth lets an app request defined access to an email account without receiving the account password. Before approving, match every requested permission to a feature you intentionally chose, distinguish read from modify or send access, and confirm revocation, storage and deletion behavior.

Verification note: This is a documentary guide checked against current sources on September 18, 2026. We did not hands-on test the named product or workflow during this review, so claims are limited to the cited documentation. Interfaces can vary by account, region, rollout, and app version.

OAuth is safer than giving a third party your mailbox password, but it is not “no access.” A token can authorize exactly the actions shown on the consent screen, and some mail permissions are broad because the feature itself is powerful. Use the AI email-assistant safety guide to evaluate the rest of the data path.

Scope and evidence boundary

This guide explains the authority documented by Gmail and Microsoft Graph permissions. It does not prove what a vendor actually requests, stores, logs, or does in production, and it is not a security assessment. The live consent screen, account type, tenant policy, and vendor privacy terms control the connection you are evaluating.

What a scope means

A scope is a named permission an app requests from an identity provider. Google and Microsoft display human-readable consent based on the requested scopes. Common capability families include:

• basic identity such as name and email address;
• message metadata such as labels and headers;
• message content read access;
• modification such as labels, archive or draft creation;
• sending mail as the user;
• settings, filters, forwarding or delegation;
• offline access through a refresh token.

Microsoft’s Graph permissions reference tells developers to request the least-privileged permission needed and documents the actual mail grants. Google’s OAuth policies impose a similar least-access requirement.

Gmail permissions are not interchangeable

Google’s official Gmail API scope list documents important differences. For example:

• metadata access can expose labels and headers without message bodies;
• gmail.modify permits reading and modifying mail and also includes compose/send capabilities, while not allowing immediate permanent deletion that bypasses Trash;
• settings scopes can affect filters or sensitive mail configuration;
• restricted scopes can require production verification and, when restricted data is stored or transmitted by a server, additional security assessment.

Do not judge only by the number of scopes. One broad scope may authorize more than several narrow identity scopes. Read the actual capability.

Microsoft Graph mail permissions are separate grants

Microsoft Graph’s permission names should be read literally:

• delegated Mail.ReadBasic reads basic mail properties for the signed-in user but excludes bodies, body previews, attachments, and extended properties;
• delegated Mail.Read reads the signed-in user’s mailbox;
• delegated Mail.ReadWrite can create, read, update, and delete mail, but does not include permission to send;
• delegated Mail.Send authorizes sending as the user and can be granted without Mail.ReadWrite;
• .Shared variants can extend delegated access to mail the signed-in user can access in shared mailboxes.

The Microsoft Graph permissions reference also distinguishes delegated access on behalf of a signed-in user from application access that can operate without one. “Sign in with Microsoft” or a generic OpenID Connect scope is therefore not evidence of the app’s mailbox authority; inspect the named Graph mail permissions and whether access is delegated or application-permission based.

Ask five questions before approving

1. Which feature requires this permission? “Inbox cleanup” is too vague. Archive requires modification; drafting may require content and draft-write access; a local statistics tool may not need either.
2. Can the app work with less access? Look for metadata-only, read-only, or incremental authorization options.
3. Where does data go? The provider consent screen explains provider access, not the third party’s storage, logging, model-training, retention or subprocessors.
4. How is access revoked? You should be able to disconnect at the provider and inside the app.
5. What gets deleted? Revocation and deletion are separate controls.

OAuth 2.0 Token Revocation (RFC 7009) is the standards reference for invalidating OAuth tokens. Google’s data-copy guidance says that after data is copied to a third party, the user must contact that service to learn whether the copy can be deleted. Revocation stops token-based future access; vendor-held copies are a separate deletion-policy question.

Read the consent in context

Legitimate mail features can require sensitive access. The right question is not “Does it ask for Gmail?” but “Does the requested capability match the feature, and does the vendor protect the resulting authority?”

Warning signs include:

• password collection instead of provider OAuth;
• permission explanations that do not name concrete features;
• send or settings access for a view-only tool;
• missing privacy, terms, support or deletion information;
• unclear developer identity or redirect domain;
• inability to disconnect individual accounts;
• success claims that ignore expired or revoked tokens.

Google’s OAuth policy requires production apps to use owned domains, secure redirect URIs, public homepages, privacy and terms links, secure token handling, and non-embedded authorization flows.

OAuth does not solve application security by itself

After authorization, the third party must still protect tokens, isolate users and accounts, prevent cross-account actions, validate every write, redact logs, handle revocation, and delete retained data. A correctly issued token can still be misused by flawed application code.

Use the email app security checklist for the broader evaluation. The email cleanup app privacy report explains how to compare documented vendor practices without implying hands-on security testing.

For write-capable tools, also ask how authorization becomes a provider-confirmed result. How email apps verify actions follows that chain from account binding through idempotency, provider commit and readback.

How to review existing access

Quarterly:

1. Open the provider’s connected-app page.
2. Identify apps you no longer use.
3. Recheck permissions against current functionality.
4. Revoke unnecessary access.
5. Request vendor-side deletion where appropriate.
6. Confirm the app reports the disconnect and stops processing.

Do not store tokens or passwords in an account inventory. Record the app, scope family, owner, connected date and review date instead.

Flick’s current boundary

Flick’s live connector declaration currently reports normal operation, new OAuth and checkout enabled, direct Gmail, and additional provider capability through Nylas. It marks Gmail smoke-tested and Microsoft, Yahoo, iCloud, and IMAP not smoke-tested. The dedicated Verified Finish rail is disabled. The sample demo requests no mailbox access and cannot demonstrate production token handling; review Flick’s consent screen, privacy policy, revocation, and deletion behavior before connecting a real account.

Bottom line

OAuth avoids sharing the account password, but the granted authority is real. Match every scope to a chosen feature, prefer least privilege, inspect storage and deletion beyond the consent screen, and review connected apps regularly.