API Authentication Methods: What 1,625 APIs Use

Quick answer: four methods cover almost every public API: no authentication, an API key, OAuth 2.0, and bearer tokens such as JWTs. Of the 1,625 APIs currently listed on publicapis.dev, 50% use an API key, 40% require no authentication at all, and 9% use OAuth 2.0. Use a key for server-to-server access, and OAuth when you act on a user's behalf.

Most articles on this topic list six methods and rank them by how secure they sound. That is backwards. The method you need is decided almost entirely by one question: are you accessing your own data, or someone else's? Everything below starts there, and then checks the theory against what public APIs actually ship.

What are the main API authentication methods?

Six things get called an authentication method. Only four are common in public APIs.

1. None. The endpoint is open. Correct for genuinely public data, and far more widespread than most developers expect.
2. API key. A single long string, sent in a header (X-API-Key, or Authorization: Bearer <key>) or, badly, in a query string. It identifies the calling application, not a user.
3. HTTP Basic. A base64-encoded username and password on every request. Still around in older APIs. It is only as safe as the transport, and it is awkward to rotate.
4. Bearer token, usually a JWT. A short-lived signed token the client obtains first and then presents on each call. Almost always the output of some other flow rather than a method of its own.
5. OAuth 2.0. A delegation protocol. The user grants your app scoped access to their account, and you receive a token that is not their password and that they can revoke.
6. mTLS. Both sides present certificates. Common in banking and partner integrations, effectively absent from open public APIs.

Which methods do public APIs actually use?

This is where a directory beats an opinion. Across the 1,625 public APIs currently published on publicapis.dev, the split is:

• 819 (50.4%) use an API key. Half the ecosystem. Six of those use a vendor-specific header rather than a standard one, which is a small but real portability tax.
• 654 (40.2%) require no authentication at all. No signup, no key, no token. This is the number people find surprising, and it is why so much prototyping happens against public APIs directly.
• 151 (9.3%) use OAuth 2.0. Nearly all of these are APIs that read or write user-owned data: GitHub, Spotify, Google's workspace APIs, Slack.
• One authenticates by User-Agent string, which is a fun reminder that the long tail exists.

The pattern is clean once you see it. APIs over public reference data (Open-Meteo for weather, currency rates, country data) tend to need nothing. APIs where the vendor bills you or rate-limits you (Stripe, most commercial services) use a key. APIs that touch an end user's account use OAuth, because nothing else lets a user grant and revoke access without handing over a password.

Of the 654 APIs needing no authentication, 237 also confirm CORS support, which means you can call them straight from browser JavaScript with no proxy and no secret to hide. Browse the development category if you want to try that in a scratch file right now.

When should you use an API key?

Use a key when the caller is a machine you control and there is no end user in the picture: a backend job, a server-rendered page, a CLI, an internal service.

Three rules make keys behave:

• Never ship a key in client-side code. Anything in a browser bundle or a mobile binary is public. If a browser needs the data, proxy the call through your own server.
• Send it in a header, not a query string. Query strings land in server logs, browser history, and Referer headers.
• Make rotation routine. Support at least two live keys per account so you can roll one without downtime. An API where rotation means downtime is an API where nobody rotates.

When should you use OAuth 2.0?

Use OAuth the moment your app acts on behalf of a user. The test is simple: if the answer to "whose data is this?" is "the person using my app", you need delegation, and a key cannot express that.

The cost is real. You implement a redirect flow, store refresh tokens, handle expiry and revocation, and get your app reviewed by the provider before you can request sensitive scopes. In exchange the user sees exactly what you asked for and can revoke it in one click, and you never hold their password.

For scripts and internal tools most OAuth providers also offer a personal access token: the same bearer credential, issued to one user, no redirect flow. That is the right shortcut for a cron job, and the wrong one for anything multi-user.

Is a JWT an authentication method?

No, and the confusion causes real design mistakes. A JWT is a token format: signed, self-describing, and readable by anyone who has it. It is what an authentication method hands you at the end. OAuth 2.0 typically issues JWTs. So does a plain email-and-password login.

Two consequences follow. A JWT is signed, not encrypted, so never put anything private in the payload. And because it is self-contained, the server does not check a database on each request, which is exactly why an issued JWT cannot easily be revoked. Keep access tokens short-lived and pair them with refresh tokens.

What the data says about getting it wrong

Auditing the same 1,625 APIs turns up a small set of live configurations that should not exist:

• 40 APIs are still HTTP-only. Any credential sent to them travels in plaintext, and any HTTPS page calling them fails on mixed content.
• 11 of those APIs still ask for an API key. A secret over plain HTTP is not a secret.
• 3 implement OAuth without HTTPS, which defeats the point of the protocol entirely.

The lesson is not that these vendors are careless. It is that transport security is a precondition for every method on this page, not a separate item on the checklist. Before comparing methods, confirm the endpoint is HTTPS-only and rejects plain HTTP rather than redirecting it.

Frequently asked questions

What are the 4 methods of REST API?

This question usually means the four main HTTP verbs (GET, POST, PUT, DELETE), not authentication. If you meant authentication, the four you will meet in practice are no auth, API key, OAuth 2.0, and bearer tokens.

What is the best API authentication method?

There is no single best one. For machine-to-machine access, an API key over HTTPS is correct and anything more is overhead. For access to a user's data, OAuth 2.0 is the only mainstream option that supports scoped, revocable consent.

Which authentication method is most commonly used for APIs?

API keys. In the 1,625 public APIs listed on publicapis.dev, 50.4% use a key, 40.2% use nothing, and 9.3% use OAuth 2.0.

What is the difference between authentication and authorization?

Authentication establishes who is calling. Authorization decides what that caller may do. An API key authenticates an application; scopes and roles authorize it. OAuth 2.0 is often described as an authorization framework for exactly this reason.

Do I need authentication for a read-only public API?

Usually not for security, but often for operations. Two in five public APIs run with no auth at all. A key still buys you per-consumer rate limiting, abuse traceability, and a way to contact heavy users before you have to block them.