OAuth vs app password: choose the supported mailbox connection

Define the decision

OAuth grants an application access through the provider’s authorization flow. An app password is a separate secret supported only by eligible accounts and clients. Neither method bypasses protocol restrictions or authorizes arbitrary sender identities.

Work through the procedure

1. Check the provider and organization’s supported methods.
2. Confirm the deployed connector offers the appropriate flow.
3. Identify who can grant, review and revoke access.
4. Test sending and incoming replies with the selected method.
5. Document recovery without storing secrets in the handover notes.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Option A: Google OAuth available and approved → use the provider flow
Option B: eligible account requires a supported app-password client → dedicated credential with protected storage
Unsupported case: ordinary account password inserted into a legacy mail form

Read the result

The decision is about compatibility and control, not which login appears simpler. A successful authentication test still needs the correct mailbox identity and allowed SMTP and IMAP paths.

Check before moving on

1. Confirm the account type and administrative restrictions.
2. Remove obsolete credentials after switching methods.

Limits and next action

Do not tell users to disable protection to make an app password available. Use the currently supported route and escalate incompatible policy requirements.

Source: Google: app passwords and preferred sign-in options