What is API access? API keys vs OAuth tokens explained

When an app talks to another service through an API, the service has to know who is calling and what they are allowed to do. That is what “API access” means in practice: a credential that identifies the caller and a set of permissions attached to it. The two credentials you will meet most often are API keys and OAuth tokens. They look similar, both are long random strings sent with each request, but they solve different problems. This guide explains how each works, when to use which, and how to keep them safe.

What API access means

An API is a set of rules that lets one program ask another for data or actions. Public APIs, such as a weather feed, may answer anyone. Most useful APIs do not: they charge per request, limit usage, or expose private data. So every request carries proof of who is asking, and the service checks two things:

• Authentication – who is this caller?
• Authorisation – what is this caller allowed to do?

“Getting API access” therefore usually means creating an account with the provider, registering an app or project, and receiving a credential that represents it.

How API keys work

An API key is a long random string created in the provider’s dashboard, for example sk_live_4f9a.... Your program sends it with every request, usually in a header:

GET /v1/forecast?city=Kyiv
Authorization: Bearer sk_live_4f9a...

The server looks the key up, finds the project it belongs to, applies that project’s permissions and rate limits, and records the usage for billing. Keys are simple, which is their main strength: one string, no extra steps, easy to use from scripts and servers.

Their weakness is that a key is a bearer credential. Whoever holds it can use it, from anywhere, until someone revokes it. A key does not expire on its own, it usually grants everything the project can do, and it identifies a project rather than a person.

How OAuth tokens work

OAuth solves a different problem: letting an app act on behalf of a user without ever seeing the user’s password. When you click “Sign in with Google” or allow a calendar app to read your Microsoft account, OAuth is at work:

1. The app sends you to the provider’s sign-in page.
2. You log in there, directly with the provider, and see a consent screen listing the requested permissions, called scopes, such as “read your calendar”.
3. If you approve, the provider gives the app a short-lived access token limited to those scopes, often with a refresh token to obtain new access tokens later.
4. The app sends the access token with API requests, exactly as it would send a key.

The access token typically expires within an hour. You can revoke the app’s access at any time in your account settings, without changing your password. The app never learns your password, and it can do only what the scopes allow.

API key vs OAuth: side by side

	API key	OAuth access token
Represents	A project or app	A user who granted permission to an app
How you get it	Copy from a dashboard	User signs in and approves a consent screen
Lifetime	Until revoked	Minutes to hours, then refreshed
Permissions	Usually everything the project can do	Only the approved scopes
Setup effort	Minimal	Redirects, client registration, token storage
Best for	Server-to-server calls, scripts, your own data	Apps that access other people’s accounts

Which one should you use?

Use an API key when your own server calls a service on your own behalf: sending email through a delivery provider, fetching exchange rates, or calling an AI model. There is no third-party user involved, and simplicity wins.

Use OAuth when your app needs access to data that belongs to its users: their files, contacts, social accounts or calendars. Asking users for their passwords would be unsafe and is forbidden by most providers.

Many services offer both. Some also offer a middle ground, such as personal access tokens with chosen scopes and expiry dates, or service accounts that use signed tokens instead of a static key. These are worth using when available, because they limit damage if the credential leaks.

Keeping API credentials safe

• Never put keys in code you publish. Bots scan public repositories for leaked keys within minutes. Keep them in environment variables or a secrets manager, and add config files to .gitignore.
• Never put secret keys in a website or mobile app. Anything shipped to users can be extracted. Call the API from your server, or use keys the provider explicitly marks as publishable.
• Use the least privilege. Create separate keys per environment and per service, with read-only or limited scopes where the provider allows it.
• Restrict where keys work. Many dashboards can limit a key to certain IP addresses, domains or apps.
• Rotate and revoke. Replace keys periodically, and immediately if one appears in a log, chat or screenshot. Revoking old keys is the step people forget.
• Watch usage. Billing alerts and usage graphs are often the first sign that a key has leaked.

Frequently asked questions

Is an API key the same as a password?

It plays a similar role for programs, but it is generated randomly, can be revoked without affecting your login, and can be limited in scope. Treat it with the same secrecy as a password.

Why does OAuth need a refresh token?

Access tokens are short-lived so that a stolen one stops working quickly. The refresh token, kept securely on the server, lets the app get a new access token without asking the user to sign in again.

Can I see which apps have OAuth access to my account?

Yes. Google, Microsoft, GitHub and most large providers have a “Connected apps” or “Third-party access” page where you can review and revoke access.

What should I do if I leak an API key?

Revoke it in the provider’s dashboard first, then create a new one and update your configuration. Deleting the commit is not enough, because copies may already exist.

In short: API access means proving who you are and what you may do. API keys identify a project and are ideal for your own server-to-server calls. OAuth tokens let an app act for a user with limited, revocable permissions. Whichever you use, keep it out of public code, give it the smallest scope possible and revoke it at the first sign of a leak.