OAuth is the wrong default for read-only personal data sync
Designing a sync agent that ingests user data (email, calendar, etc.) from third-party services into a local app for personal-CRM or knowledge-base purposes.
The natural starting point when integrating with Google/Microsoft/etc. is OAuth via their official APIs (Gmail API, Microsoft Graph, Google Calendar API). It looks correct because docs are first-class and the libraries are maintained. But OAuth as a personal-onboarding flow has real friction that compounds: register an app in someone's console (Google Cloud / Azure AD / Apple Developer), configure scopes + redirect URIs, paste client_id and client_secret into the agent, run a browser dance, store and rotate refresh tokens. For roughly half of real-world accounts (corporate inboxes with admin lockdown, restricted Google Workspaces, Microsoft 365 tenants with strict app policies), that flow is impossible without IT involvement that does not happen. The friction-free alternative for READ-ONLY use cases is almost always a published-feed or universal-protocol path: IMAP plus app password for email, CalDAV or .ics URL subscription for calendars, RSS for blogs, public iCal for sports schedules. These cover roughly 95% of the data needs of a personal-CRM-style tool, require no app registration, work across providers with the same code, and have an auth model that any user with 2FA enabled can self-serve in five minutes.
When scoping a sync-agent design, first ask: do I need to WRITE to the provider, or just READ? If read-only, default to the universal protocol (IMAP / CalDAV / .ics / RSS) and treat provider-specific OAuth as a maybe-later feature for power users. Document onboarding as a single page: go to provider security settings, create an app password, paste it in. Provider OAuth agents can ship alongside as opt-in but should not be the default path.