API Auth: Authentication Methods and Examples

API authentication is the layer that decides which systems and users get to talk to your API. Get it wrong and your endpoints become a free buffet. Get it right and you have controlled, auditable, revocable access for every consumer.

In this guide, you'll learn about the API authentication methods most commonly used in production today, how they work, and where each one fits:

• Basic auth
• API keys
• OAuth (and a note on OAuth 2.1)
• OpenID Connect (OIDC)
• Integration system user (ISU)
• Hash-based message authentication code (HMAC)
• Certificate signing request (CSR)

What's New in API Auth in 2026

Three things have changed in the last 18 months that anyone working on API auth needs to know about.

OAuth 2.1 is the new baseline. Still in IETF draft status (draft-ietf-oauth-v2-1-15, March 2026), but already the de facto standard. It mandates PKCE for all clients (not just public ones), removes the implicit grant and ROPC, and requires exact redirect URI matching. If you're building new auth flows in 2026, you should be implementing OAuth 2.1, not OAuth 2.0.

Agent auth is its own category now. AI agents acting on behalf of users break the assumptions OAuth 2.0 was built around. The agent isn't a person clicking "Authorize" — it's a piece of software making autonomous decisions about which APIs to call. The pattern that's emerging: per-user OAuth where the agent layer issues session tokens mapped to upstream credentials.

MCP authorization is a real spec. The Model Context Protocol authorization spec (updated 2025-11-25, with further 2026 refinements) formally requires OAuth 2.1 + PKCE + Resource Indicators (RFC 8707) + Dynamic Client Registration for remote MCP servers. ChatGPT, Claude, Cursor, and VS Code Copilot all enforce this for connecting to external tools.

The seven methods below are the foundational vocabulary. OAuth 2.1, agent auth, and MCP authorization all build on these primitives.

Basic Auth

This is the most straightforward authentication method. The incoming request includes the username and password in the authentication header, sent as a Base64-encoded string in the format Authorization: Basic <Base64EncodedCredentials>. When the API receives the request, it decodes the string and verifies it against the records in its database. If the credentials are valid, the API grants access:

Basic auth is easy to implement but has significant drawbacks. Base64 is encoding, not encryption — anyone who intercepts the request can decode the credentials in seconds. Basic auth is only ever safe over HTTPS, and even then it sends full credentials on every request, which means a single leaked TLS session exposes everything.

A good example of an API that uses basic auth is from UKG Pro, a human capital management suite.

Here's a sample request that uses basic auth to retrieve all employee deductions from the UKG Pro API:

curl --request GET \
 	--url https://hostname/personnel/v1/emp-deductions \
 	--header 'accept: application/json' \
 	--header 'authorization: Basic PFVTRVJOQU1FPjo8UEFTU1dPUkQ+' \
	--header 'US-Customer-Api-Key: ABCDE1'

Combining basic authentication with an API key adds a layer of protection. If the API key is compromised, an attacker still needs the username and password to get in.

This method is best suited for simple internal tools where the authentication process needs to be quick and straightforward, like accessing internal dashboards or administrative panels. Don't use it for anything internet-facing in 2026.

API Keys

API keys are unique identifiers that authenticate requests, typically generated from the API provider's dashboard. They are included in every request, either in the request headers or as query parameters. The server validates the key on each request and either grants or denies access:

API keys are popular due to their ease of implementation and the fact that they can be revoked or regenerated if compromised. However, they are susceptible to interception if the connection is not encrypted, and while they can be configured with scopes or permissions, they lack the built-in fine-grained access controls of OAuth.

API keys are also the auth method most likely to leak. A key checked into a public GitHub repo gets scraped within minutes by automated scanners. Treat every API key as one config mistake away from being public.

Teamtailor, an all-in-one recruitment software, is a good example of an API that uses API keys for authentication.

Here is a sample request to the Teamtailor API that uses an API key to retrieve lists of jobs:

curl --location 'https://api.teamtailor.com/v1/jobs' \
  --header 'Authorization: Token token=od71S1zmxWetVvzz6ovSeznEPb-OdsZZSX9EeBi9' \
  --header 'X-Api-Version: 20240404'

This method is best suited for simple integrations: public APIs, service-to-service communication, and internal applications. For anything user-facing or multi-tenant, OAuth is the better fit.

OAuth

OAuth is an authorization protocol that lets a user grant an application access to API resources without sharing their credentials. It involves three parties: the user (the resource owner), the client application (the application requesting access), and the authorization/resource server. OAuth supports several types of flows, including authorization code, proof key for code exchange (PKCE), client credentials, and more.

Here are the steps in the authorization code flow:

1. The user initiates an access request from the client application.
2. The client application redirects the user to the authorization server with an authorization request that includes the client ID, redirect URI, and requested scopes.
3. The authorization server requests that the user grant the requested permissions to the client application.
4. Once the user consents, the authorization server redirects the user back to the client application with an authorization code using the client's redirect URI.
5. The client application sends the authorization code to the authorization server to exchange it for an access token.
6. The client application then uses the access token to make authenticated requests to the resource server and access the user's resources.

OAuth offers strong security and fine-grained access control. The trade-off is implementation complexity — multiple round-trips, token refresh handling, scope management, and edge cases around expired tokens.

A note on OAuth 2.1. What most developers call "OAuth" today is OAuth 2.0 (RFC 6749, published 2012). The next version, OAuth 2.1, consolidates a decade of security best practices into a single document: PKCE is mandatory for all clients, the implicit grant is removed, ROPC is removed, and exact redirect URI matching is required. If you're starting a new OAuth integration in 2026, target OAuth 2.1 patterns from the start. We'll cover OAuth 2.1 in depth in a separate article.

A good example of an API that uses OAuth is from QuickBooks, the accounting software developed by Intuit.

Here is a sample request in the authorization code flow where the client application exchanges the authorization code for an access token from Intuit's authorization server:

curl -X POST 'https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic Y2xpZW50X2lkOmNsaWVudF9zZWNyZXQ=' \
  -d 'grant_type=authorization_code' \
  -d 'code=abc123' \
  -d 'redirect_uri=https://yourapp.com/callback'

This method is ideal for third-party applications that need to access user data without exposing credentials. It is the standard for social media integrations, third-party applications accessing user data, and any scenario requiring delegated access. It's also the foundation of all modern AI agent auth, including the MCP authorization spec.

OpenID Connect (OIDC)

OpenID Connect (OIDC) is an authentication protocol built on top of OAuth. As mentioned earlier, OAuth is an authorization protocol; OIDC adds an identity layer to it. OIDC involves the same parties as OAuth and follows almost the same steps, with two key differences:

1. When the client application redirects the user to the authorization server, it must specify the scope as openid, along with other requested scopes.
2. When the client application sends the authorization code to the authorization server, it receives not only an access token but also an ID token. The ID token is a JSON Web Token (JWT) that contains information about the user in the form of claims.

OIDC offers simplified user authentication, single sign-on (SSO) across applications, and a standardized identity layer that works across providers. The catch: because OIDC is authentication and not authorization, it cannot be used to make signed requests on behalf of the user to the provider site to perform CRUD operations on their behalf. You still need OAuth for that.

An example of a popular API that uses OIDC is from Salesforce, a leading CRM platform.

In Salesforce, when using Okta as the OIDC provider, you can use the following sample code to make an authorization request. This returns an HTML page with a code that you can exchange for an access token and an ID token:

curl --location --request GET 'https://<OKTA-DOMAIN>/oauth2/v1/authorize?client_id=<CLIENT_ID>&response_type=code&response_mode=form_post&sessionToken=<SESSION_TOKEN>&redirect_uri=<REDIRECT_URI>&scope=openid groups&state=mystate&nonce=mynonce'

This method is best suited for applications that require user authentication and SSO across multiple domains.

Integration System User (ISU)

An ISU is a dedicated user account created specifically to enable programmatic access to APIs. The pattern: create a system user with predefined roles and permissions, then use that user's credentials (typically a username and password) for API requests:

ISUs give you dedicated, controlled access for programmatic interactions and clear audit trails for activities performed by the service user. The challenge is securely storing the system user credentials. If they leak, the attacker gets the same access the service user has — which in enterprise systems is often very broad.

Several enterprise APIs use ISUs as the authentication method. A good example is Workday, a leading enterprise cloud applications provider for finance, HR, and planning.

Here is a sample request to the Workday API that retrieves worker data:

curl --location 'https://wd2-impl-services1.workday.com/ccx/service/{TENANT}/Human_Resources/v40.1' \
--header 'Content-Type: application/xml' \
--data '<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:bsvc="urn:com.workday/bsvc">
	<soapenv:Header>
    	<wsse:Security>
        	<wsse:UsernameToken>
            	<wsse:Username>{ISU_USERNAME}</wsse:Username>
            	<wsse:Password>{ISU_PASSWORD}</wsse:Password>
        	</wsse:UsernameToken>
    	</wsse:Security>
	</soapenv:Header>

	<soapenv:Body>
    	<bsvc:Get_Workers_Request/>
	</soapenv:Body>
</soapenv:Envelope>'

This method is best suited for system-to-system integrations within enterprise environments where OAuth flows aren't practical or where the API itself doesn't support modern auth.

Hash-Based Message Authentication Code (HMAC)

HMAC is a message authentication mechanism that uses a cryptographic hash function and a secret key, both known to the server and the client, to guarantee the authenticity and integrity of a message. The flow:

1. The client generates a unique HMAC value from the message and the secret key using a secure cryptographic function, such as SHA-256.
2. The client sends the message along with the unique HMAC value to the server.
3. The server uses the same secret key and cryptographic function to compute the HMAC of the message. If the computed HMAC matches the one received from the client, the message is authentic and untampered. If not, the message was modified in transit.

HMAC is strong because it relies on secure cryptographic hash functions. Even if a message in transit is intercepted by malicious actors, it cannot be modified without detection. The whole security model depends on the secret key staying secret. If it leaks, HMAC's integrity guarantees collapse.

An example of a popular API that uses HMAC is from NetSuite, the integrated cloud business software suite from Oracle.

This method is best suited for verifying the integrity and authenticity of messages transmitted over insecure channels — securing webhook notifications sent from an e-commerce platform to a payment gateway is the classic example.

Certificate Signing Request (CSR)

A CSR is a message sent by an applicant to a certificate authority (CA) to apply for a digital identity certificate. The CSR typically includes information that gets bundled into the certificate: a public key, common name, organization name, organizational unit, locality, state, and country. The flow:

1. The applicant generates a private and public key pair using tools such as OpenSSL. The private key is kept secret; the public key is included in the CSR.
2. The applicant creates the CSR by including their information along with the public key.
3. The CSR is submitted to the CA, which verifies the information, signs the CSR with its private key (creating the digital identity certificate), and issues it to the applicant.

The certificate can then be used for authentication and encryption of data transferred between server and client. Authentication can be one-way or two-way.

One-way authentication uses standard SSL/TLS, where only the server is authenticated:

1. The client requests data from the API.
2. The API sends its digital identity certificate to the client.
3. The client verifies the API's certificate against a list of trusted CAs.
4. If the certificate is valid, a secure connection is established between the client and server.

Two-way authentication (mutual TLS, often abbreviated mTLS) authenticates both parties to each other:

1. The client requests data from the API.
2. The API sends its digital identity certificate to the client.
3. The client verifies the API's certificate against a list of trusted CAs. If valid, the client sends its certificate to the API.
4. The API verifies the client's certificate against a list of trusted CAs. If everything checks out, secure communication is established.

CSR-based authentication offers high security, especially with mutual authentication, which makes it very effective against man-in-the-middle attacks. The cost is operational complexity: generating, distributing, installing, rotating, and revoking certificates is non-trivial, and certificate expiry has caused more outages than most other auth failure modes combined.

A good example of an API that uses CSR is ADP Workforce Now, the all-in-one platform for payroll and HR software.

This method is best suited for high-security environments requiring mutual authentication, such as secure communication between a financial institution's servers and client applications.

Which API Authentication Method Should You Use?

Method	Best For	Avoid When
Basic auth	Internal tools, admin dashboards	Anything internet-facing or multi-tenant
API keys	Service-to-service calls, simple integrations	User-delegated access, complex permission models
OAuth (2.0/2.1)	Third-party app access to user data, delegated authorization	Pure machine-to-machine where API keys are simpler
OIDC	User authentication, SSO across applications	When you need to act on the user's behalf (use OAuth)
ISU	Enterprise system-to-system, when OAuth isn't supported	Public APIs, anywhere credentials might leak
HMAC	Webhooks, verifying message integrity	Pure authentication without integrity requirements
CSR / mTLS	High-security mutual auth, regulated industries	Resource-constrained or high-velocity environments

FAQ

What is API authentication? API authentication is the process of verifying the identity of a system or user making a request to an API. It's how an API decides whether to trust the caller and grant access to its resources. Authentication answers "who are you?" Authorization (a related but distinct concept) answers "what are you allowed to do?"

What's the difference between authentication and authorization in APIs? Authentication verifies identity — proving who you are. Authorization checks permissions — what that identity is allowed to do. OAuth is fundamentally an authorization protocol. OIDC is an authentication protocol. Most production systems use both: OIDC to verify the user's identity, OAuth to issue scoped tokens for actions on their behalf.

What are the most common API authentication methods? The seven methods covered in this guide are the production standards: basic auth, API keys, OAuth, OIDC, ISU, HMAC, and CSR/mTLS. In practice, OAuth (and increasingly OAuth 2.1) is the dominant choice for user-delegated access, API keys remain ubiquitous for service-to-service calls, and HMAC dominates webhook verification.

Is OAuth 2.0 still secure in 2026? Yes, when implemented correctly. OAuth 2.0 is widely deployed and has well-understood security patterns. That said, OAuth 2.1 consolidates the security best practices that OAuth 2.0 implementations have had to bolt on (mandatory PKCE, removed implicit grant, exact redirect URI matching). If you're building new OAuth flows, target OAuth 2.1 patterns.

What is OAuth 2.1 and how is it different from OAuth 2.0? OAuth 2.1 is an in-progress IETF draft that consolidates OAuth 2.0 plus the security extensions everyone has been adding for the last decade. The big changes: PKCE is mandatory for all clients (not just public ones), the implicit grant is removed, ROPC is removed, and exact redirect URI matching is required. We cover OAuth 2.1 in depth in a separate article.

What is API gateway authentication? API gateway authentication is the practice of moving auth concerns to a dedicated gateway layer (Kong, AWS API Gateway, Apigee, etc.) instead of implementing auth inside each backend service. The gateway validates tokens, applies rate limits, and forwards verified requests to upstream services. It's a common architectural pattern for organizations running many APIs.

Are API keys secure? API keys are convenient but have weaker security guarantees than OAuth. They're long-lived secrets typically transmitted in headers or query strings, with no built-in expiration or fine-grained scoping. Use HTTPS, treat keys as secrets (never in client-side code, never in Git), rotate them regularly, and prefer OAuth for anything user-facing.

How do AI agents authenticate to APIs? AI agents typically authenticate to APIs using OAuth 2.1 patterns, often through the Model Context Protocol (MCP) authorization spec which formally requires OAuth 2.1 + PKCE + Resource Indicators (RFC 8707) for remote MCP servers. The hard problem in agent auth is scoping: an agent acting on a user's behalf needs delegated permissions that map back to the user's original consent, with auditable trails for every autonomous action. We cover agent authentication and MCP authorization in depth in separate articles.

What is mutual TLS (mTLS)? Mutual TLS (also called two-way TLS or two-way authentication) is the CSR-based pattern where both client and server present certificates to each other. Standard TLS only authenticates the server; mTLS authenticates both parties. It's the gold standard for high-security machine-to-machine auth, especially in regulated industries like finance and healthcare.

Conclusion

In this guide, you've seen the seven foundational API authentication methods used in production today: basic auth, API keys, OAuth, OIDC, ISU, HMAC, and CSR/mTLS. Each has a place. The right choice depends on what you're building, who's calling your API, and what the consequences are if a credential leaks.

Modern API auth is moving in two directions at once: stricter standards for human-driven flows (OAuth 2.1 hardening the OAuth 2.0 patterns) and entirely new specs for AI agents acting on users' behalf (MCP authorization). Both build on the primitives covered above.

Apideck takes care of the messy parts of API authentication for unified API integrations. With Apideck Vault, you can integrate with hundreds of SaaS APIs without implementing each provider's auth flow yourself — the Vault handles credential storage, token refresh, and per-consumer isolation across every method covered in this article. Try Apideck today.