OAuth2 vs service accounts: authenticating to an API cleanly

The question comes up the first time you build something that touches a client's Google Drive, their calendar, or any platform where 'authentication' means more than pasting in a key. Do you send them through an OAuth consent screen and hold their token, or do you get them to generate an API key or service account and hand it to you directly? It looks like a five-minute setup choice. It is actually a decision about who owns the maintenance burden six months from now.

What each one actually costs you later

An API key is a flat cost. The client generates it once, you plug it in, and unless they revoke it, it keeps working. A service account is the same shape: one credential, scoped to a specific resource, no human session behind it to expire.

OAuth is a recurring cost dressed up as a one-time setup. You get a token, that token expires (a common pattern is a 60-minute access token with no refresh token available, which means someone has to re-authorize by hand on a schedule), and if the client changes their password, enables two-factor, or the app's OAuth consent screen falls out of a verified state, the connection breaks and stays broken until somebody notices. One builder spent real time round-tripping an authorization flow because each code expired after five minutes, meaning every failed attempt meant starting the whole exchange again.

Where OAuth is genuinely the only option

Some platforms don't give you a choice. If the data belongs to an individual user account rather than an organization-level resource, calendars are the obvious case, there is often no service-account equivalent. You cannot get a static key that reads someone's personal calendar. The platform wants to know a human authorized it, and it wants to be able to revoke that authorization from their account settings. In those cases the job is not avoiding OAuth, it's building for its failure modes from day one: request the offline_access scope so you actually get a refresh token, store the refresh token somewhere durable, and put a monitor on the connection so a broken token shows up as an alert instead of a support ticket three weeks later.

Where a key wins outright

For anything server-to-server, a CRM export, a data pull that never touches an individual's personal account, a service account or scoped API key is the better call almost every time. It's one credential, it doesn't expire on its own schedule, and a non-technical client can generate it themselves from an admin settings page without you walking them through a consent screen. This matters more than it sounds: the moment a client has to click through their own Google account permissions to unblock your workflow, you've made your reliability dependent on their attention span.

The actual rule

Default to an API key or service account whenever the platform offers one, because it removes an entire category of failure you'd otherwise have to monitor for. Reach for OAuth only when the API forces it, personal calendars, personal Drive folders, anything scoped to one human's session, and when you do, build the refresh cycle and the failure alert at the same time you build the happy path, not after the first client complains their integration silently died three weeks in.