API authentication is the process a system uses to verify that a request to an API actually comes from who or what it claims to come from, before deciding what that caller is allowed to do. It answers one question — "who is this?" — using credentials like API keys, OAuth 2.0 tokens, JSON Web Tokens (JWT, RFC 7519), or mutual TLS certificates. Get it wrong and the damage is not hypothetical: Optus disclosed in September 2022 that an internet-facing API with no authentication exposed 9.8 million customer records, and T-Mobile confirmed in January 2023 that an API abused without authentication for 47 days exposed data on 37 million accounts. API authentication is the first checkpoint in API security, and the OWASP API Security Top 10 has ranked broken authentication (API2) as a top-three risk in both its 2019 and 2023 editions. This glossary entry breaks down how it works, where it fails, and how security teams verify it's actually enforced in production.
What Is API Authentication?
API authentication is the mechanism by which an API verifies the identity of a caller — a user, service, or device — before processing a request. Every authenticated call carries a credential: a static API key sent in a header, a bearer token issued by an OAuth 2.0 authorization server (RFC 6749), a signed JWT with an expiration claim, or a client certificate validated through mutual TLS (mTLS). The API's authentication layer checks that credential against an identity provider, a signing key, or a certificate authority, then either accepts the request or rejects it with a 401 Unauthorized response. This is distinct from encryption in transit (TLS protects the data on the wire) and from authorization (which governs what an authenticated caller can access). A request can be fully encrypted and still be completely unauthenticated — that gap is exactly what let Peloton's leaderboard API return private account data to any logged-in user in 2021, before authentication scope was tightened.
How Is API Authentication Different from API Authorization?
API authentication confirms identity; API authorization decides what that identity is permitted to do, and conflating the two is one of the most common design mistakes in API security. Authentication happens first, at the door: a bearer token or API key proves the caller is "user 4471" or "billing-service." Authorization happens after, at the resource: it checks whether user 4471 can read invoice #88213 or only their own invoices. The OWASP API Security Top 10 splits these into separate categories on purpose — API1:2023 is Broken Object Level Authorization, API2:2023 is Broken Authentication, and API5:2023 is Broken Function Level Authorization — because APIs regularly get one right and the other wrong. A 2023 case in point: an authenticated but improperly authorized endpoint in a popular fintech app allowed any logged-in user to modify another user's linked bank account by changing an account ID in the request path, a Broken Object Level Authorization (BOLA) flaw that authentication alone could never have caught.
What Are the Most Common API Authentication Methods?
The four methods that cover the vast majority of production APIs are API keys, OAuth 2.0 / OpenID Connect tokens, JWTs, and mutual TLS, each with different trust and revocation tradeoffs. API keys are static strings issued per client — simple to implement but hard to rotate at scale and, because they don't expire on their own, dangerous if leaked into a public GitHub repo or a client-side JavaScript bundle. OAuth 2.0, standardized in RFC 6749 in October 2012, delegates authentication to a dedicated authorization server and issues short-lived access tokens (commonly 15 minutes to 1 hour) plus longer-lived refresh tokens, which is why it underpins sign-in flows for Google, Microsoft, and most SaaS platforms today. JWTs (RFC 7519, May 2015) are self-contained, cryptographically signed tokens that let an API verify a caller without a database round-trip, but a signature-validation bug — such as accepting a token's "alg: none" header, a flaw found repeatedly across libraries between 2015 and 2022 — can let an attacker forge a valid-looking token. Mutual TLS, where both client and server present certificates, is the strongest of the four and is standard in payment and machine-to-machine APIs under PCI DSS-adjacent environments, but it carries real certificate-lifecycle overhead that keeps many teams from adopting it broadly.
Why Does Broken Authentication Keep Showing Up in Breaches?
Broken authentication keeps showing up because it is rarely a single bug — it is usually a missing control on one endpoint out of hundreds, and that one gap is enough. The USPS Informed Visibility API, disclosed in November 2018, exposed real-time data on roughly 60 million user accounts because a single API endpoint accepted any authenticated request and returned account details for arbitrary users, an authentication design gap that sat in production for over a year before a researcher reported it. In April 2023, T-Mobile disclosed its second API-related breach in five months, this time affecting 37 million prepaid and postpaid accounts, after an API pulled by a malicious actor required no authentication token at all to return name, billing address, and account PIN data. The pattern across nearly every large API breach since 2018 — USPS, Peloton, Experian's partner API in 2020, T-Mobile twice, and Optus — is the same: one endpoint, often an internal or "temporary" one, ships without the authentication check applied everywhere else, and it stays that way until an attacker or researcher finds it through simple enumeration.
How Do Security Teams Verify API Authentication Is Actually Enforced?
Security teams verify enforcement by testing every endpoint against unauthenticated and cross-tenant requests, not by trusting that a framework's default middleware covers it. Manual and automated dynamic testing (DAST) sends requests with missing, expired, and swapped tokens against each documented and undocumented endpoint — undocumented matters because a 2022 Salt Security report found that 41% of organizations surveyed had at least one API in production that their own security team didn't know existed, and unknown APIs are precisely where auth checks get skipped. Static analysis (SAST) and software composition analysis catch a different failure mode: authentication middleware that exists in the codebase but isn't wired into a specific route, or an outdated JWT library carrying a known signature-bypass CVE. Runtime API discovery closes the gap between the two by inventorying every live endpoint an application actually exposes, including ones added after the last code review, and flagging any that respond successfully to unauthenticated traffic.
How Safeguard Helps
Safeguard helps security teams close authentication gaps before they reach production and prioritize the ones that already have. Griffin AI reviews pull requests and flags missing or weakened authentication checks — a removed @RequiresAuth decorator, a JWT verification step bypassed in a new code path, or a hardcoded API key — directly in the diff, before merge. Reachability analysis determines whether a vulnerable authentication or JWT library is actually invoked by code your application executes, so teams stop burning triage time on CVEs in unreachable dependencies and focus on the ones an attacker could actually exploit. Safeguard's SBOM generation and ingest give teams a live inventory of every authentication-related library and its version across every service, so a signature-bypass advisory can be matched to affected services in minutes instead of days. When a fix is available, Safeguard opens an auto-fix PR with the patched dependency version and the reachability context attached, so the team reviewing it knows exactly why the change matters.