Google Sheets API authentication: API key vs OAuth vs service account

Which Google Sheets API credential should you use?

Choose based on whose data the app reads, not which setup tutorial looks shortest. An API key has no user identity, so it only works for data already public. OAuth represents a person who consented to let your app act on their behalf. A service account represents the application itself, like a bot with its own email address.

All three start with a Google Cloud project and the Sheets API enabled. What changes is who Google believes is calling, which spreadsheets that identity can open, and which secrets or tokens you must keep safe.

The decision in one table

API keys: public data, not private access

A standard Google API key does not authenticate a principal. It associates the request with your Cloud project for quota and API restrictions. With no person or service account attached to the request, Google cannot use private file permissions to let it through. That is why an API key is appropriate only for a sheet already shared publicly.

The key still needs protection from quota theft. Restrict it to the Google Sheets API and restrict where it can be used: HTTP referrers for a browser app, IP addresses for a server, or the matching mobile application restriction. A browser key is visible to anyone using developer tools, so the restriction is the control. Hiding it in minified JavaScript is not.

A public read with an API key

For a public spreadsheet, the key travels as the key query parameter. This reads a range through the official spreadsheets.values.get method:

curl 'https://sheets.googleapis.com/v4/spreadsheets/SPREADSHEET_ID/values/Sheet1!A1:D10?key=YOUR_API_KEY'

OAuth: when the user owns the sheet

Use OAuth when your application needs to open private spreadsheets belonging to the person using it. Your app redirects the user to Google, the user approves specific scopes, and Google returns an authorization code. Your server exchanges that code for an access token and, when offline access is requested, a refresh token.

The access token belongs in an Authorization: Bearer header. Access tokens expire; the refresh token is what lets a server continue reading after the user leaves. Treat refresh tokens like passwords: store them encrypted, never put them in browser storage, and handle revocation by sending the user through consent again.

Google's current Auth Platform separates setup into Branding, Audience, Data Access, and Clients. In Testing mode, only listed test users can authorize the app, and grants involving Sheets scopes expire after seven days. Moving a public app to production can require verification depending on the scopes it requests.

OAuth and service accounts send the same header

OAuth and service accounts differ in how they obtain a token, not how the Sheets request uses it. Both ultimately call the API with a short-lived bearer token:

curl \
  -H 'Authorization: Bearer ACCESS_TOKEN' \
  'https://sheets.googleapis.com/v4/spreadsheets/SPREADSHEET_ID/values/Sheet1!A1:D10'

Service accounts: an application identity, not an API key

A service account is a separate, non-human identity. It does not automatically inherit access to your spreadsheets. For one private sheet, share the file with the service account's email address just as you would share it with a colleague. Google Cloud IAM roles do not grant access to Google Workspace files; the file share is the permission that matters.

This is a good fit for a scheduled import, an internal backend, or a job that always reads the same small set of sheets without a person present. It is usually the wrong identity for a SaaS product whose customers each expect to connect their own Drive. OAuth preserves which user granted access and lets that user revoke it.

Do not casually download a service-account JSON key because an old tutorial says to. Google recommends avoiding user-managed service-account keys when possible. On Google Cloud, attach the service account to the workload. Outside Google Cloud, prefer Workload Identity Federation when your platform supports it. Create a JSON key only when those options do not fit, keep it out of the repository and filesystem where possible, and rotate it like any other long-lived secret.

The scope often matters more than the credential

OAuth users and service accounts still need authorization. Ask for the narrowest scope that supports the product:

Two scope details most implementations miss

First, spreadsheets.readonly sounds conservative, but it can see all spreadsheets the user can access and is classified as sensitive. For an app that lets a user choose specific files, Google recommends drive.file. It is non-sensitive and file-scoped, which is a much smaller blast radius.

Second, the Sheets scopes apply to an entire spreadsheet file, not one tab inside it. If your product promises tab-level access or read-only behaviour while holding a broader scope, that guarantee must be enforced by your application. A scope is the maximum Google permits; it is not proof that your code uses every permitted operation.

The failures that look like API bugs

• "This app isn't verified": the OAuth client is requesting sensitive or restricted scopes without the required production verification. During development, keep the app in Testing and list the accounts that should have access.
• The token worked last week and suddenly stopped: Testing-mode grants involving Sheets scopes expire after seven days, or the user revoked access. Refresh when possible; otherwise ask the user to authorize again.
• origin_mismatch: the browser origin, including scheme and port, does not exactly match an authorized JavaScript origin in the OAuth client.
• Insufficient authentication scopes: the token is valid, but it was minted without a scope that permits the attempted Sheets operation. Changing the scope in code does not upgrade an existing token; request consent again.
• A service account cannot find the spreadsheet: share the file with the service-account email. Giving the account a Cloud IAM role does not grant Workspace file access.

When you do not need to own this authentication stack

If the job is simply "make this sheet readable as JSON," building Google authentication may be work around the actual problem. A link-shared sheet can be published through PasteSheet by pasting its URL. A restricted sheet can stay restricted: connect Google, choose the exact file in Google Picker, and PasteSheet handles the file-scoped grant.

The result is a cached, typed, row-oriented REST API with filtering, sorting, pagination, and an MCP endpoint. PasteSheet has no write path to the source sheet. Use Google's API directly when you need writes, custom spreadsheet operations, or a first-party integration across many user files. Use the hosted endpoint when you need one sheet published safely and quickly.

Publish a sheet without your own Google credentials

MCP is included on the Free plan. Connect any public endpoint over MCP with no Google Cloud project and no credit card. Private endpoints and the account-wide workspace server need a paid plan (from Starter ($9/mo)) for the keys and OAuth they authenticate with.

Pro adds full-text search and aggregation (count, sum, avg, group_by) that your AI agent can call through query_rows.

Frequently asked questions

Sources

• Create access credentials — Google Workspace
• Choose Google Sheets API scopes — Google
• Manage API keys — Google Cloud
• Using OAuth 2.0 for web server applications — Google
• Manage App Audience — Google Cloud
• Best practices for using service accounts securely — Google Cloud

Related guides