Any WordPress site that exchanges data with another application needs a reliable way to identify the calling user or service. That is the job of API authentication. The method you choose affects how credentials are stored, how permissions are limited, and how easily access can be revoked if something goes wrong.
This guide compares API keys, Basic Authentication, WordPress Application Passwords, OAuth 2.0, JSON Web Tokens, and HMAC signatures. It also covers practical considerations for custom WordPress REST APIs and WooCommerce integrations.
What API authentication actually does
Authentication establishes who is making a request. Authorization determines what that authenticated user or application is allowed to do. A secure API needs both controls.
For example, a WooCommerce inventory service might be allowed to read product stock but not modify administrator accounts. A valid token should not automatically grant access to every endpoint.
Common API authentication methods
API keys
An API key is a generated string that an application sends with each request, commonly in a header such as X-API-Key or Authorization. This approach is straightforward and can suit server-to-server integrations, reporting tools, and low-risk, read-only services.
GET /wp-json/my-plugin/v1/orders HTTP/1.1
Host: example.com
X-API-Key: your-server-side-keyAPI keys usually identify an application rather than a person, and some implementations give them broad access. Keep keys in environment variables or protected server configuration. Do not place them in browser JavaScript, public repositories, or WordPress post content.
Separate keys by application, restrict their permissions, add rate limits, and provide a process for expiration and rotation. Treat every key as a secret, even when it only grants read access.
Basic Authentication
Basic Authentication sends a username and password in an HTTP header. The credentials are encoded, not encrypted, so this method must only be used over HTTPS.
Authorization: Basic base64(username:password)Basic Authentication can be acceptable in a controlled development environment or for an internal service that specifically requires it. It is usually a poor fit for public production integrations because the credentials are reusable and may provide extensive access.
Never put Basic Authentication credentials in a URL or expose them in a client-side application. Use a dedicated account with limited capabilities rather than a primary administrator account.
WordPress Application Passwords
WordPress Application Passwords create separate credentials for REST API access without exposing the user’s main account password. A site administrator can issue a credential for a particular application and revoke it without changing the user’s normal login.
This is often a practical option when a trusted external service needs to call the WordPress REST API as a specific user. Use HTTPS and assign that user only the capabilities the integration requires. An editor or custom role may be more appropriate than an administrator.
Custom endpoints should still check capabilities before performing an action:
if ( ! current_user_can( 'edit_posts' ) ) {
return new WP_Error(
'forbidden',
'You do not have permission to perform this action.',
array( 'status' => 403 )
);
}OAuth 2.0
OAuth 2.0 lets an application obtain limited access without receiving the user’s primary password. It is commonly used when someone connects a WordPress site to a payment provider, email platform, CRM, or social service.
OAuth flows use access tokens, scopes, and redirect URIs. Scopes restrict what the connection can do, while short-lived access tokens reduce the damage caused by accidental exposure. Some flows also use refresh tokens to obtain new access tokens without requiring the user to sign in again.
OAuth is more involved than an API key. Use a maintained library or the provider’s official SDK, validate redirect URIs exactly, protect client secrets, and follow the provider’s documented flow rather than implementing the protocol from memory.
JSON Web Tokens
JWT authentication uses a signed token containing claims such as a user identifier, expiration time, and issuer. The receiving server verifies the signature and token claims before accepting the request. JWTs are common in headless WordPress projects, mobile applications, and separate frontend applications.
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...A JWT is usually signed, not encrypted. Someone who obtains the token may be able to read its claims, so never put passwords, payment details, or other private information inside it.
Use suitable expiration times, secure token storage, signature verification, issuer and audience checks, and a workable revocation strategy. A token that remains valid indefinitely is difficult to control after it has been exposed.
HMAC-signed requests
HMAC authentication signs selected request data with a shared secret. The receiving server calculates the signature independently and compares the result. This can help detect tampering and is well suited to server-to-server requests and webhook verification.
A robust signature design commonly includes the HTTP method, request path, timestamp, and a hash of the request body. Reject timestamps that are too old and include a request identifier when possible to reduce replay attacks. Both systems must use the same canonical format, and signatures should be compared using a constant-time operation.
Which authentication method should you choose?
| Use case | Practical choice |
|---|---|
| Read-only server integration | Scoped API key with rotation and rate limits |
| Trusted WordPress automation | Application Password or dedicated service account |
| User connects a third-party service | OAuth 2.0 |
| Headless frontend or mobile app | Short-lived JWT or the provider’s token system |
| Webhook verification | HMAC signature with timestamp validation |
The most sophisticated option is not automatically the best one. Choose the simplest method that supports limited permissions, secure storage, expiration or rotation, and useful auditing.
Implementing authentication in a WordPress REST endpoint
Custom WordPress endpoints should use a permission_callback rather than relying on an obscure URL or a nonce. WordPress nonces help protect browser-based requests against cross-site request forgery, but they are not a complete authentication system for external applications or long-term API access.
add_action( 'rest_api_init', function () {
register_rest_route( 'my-plugin/v1', '/report', array(
'methods' => 'GET',
'callback' => 'my_plugin_get_report',
'permission_callback' => function () {
return current_user_can( 'manage_options' );
},
) );
} );For an API-key endpoint, validate the key through a dedicated authentication layer or compare a securely stored hash. Follow that check with capability validation and input validation. Error responses should not reveal passwords, database credentials, raw exception messages, or other sensitive implementation details.
API authentication security checklist
- Require HTTPS for every authenticated request.
- Keep secrets out of frontend JavaScript, Git repositories, screenshots, and logs.
- Use least-privilege users, scopes, and WordPress capabilities.
- Set expiration dates and rotate keys or tokens.
- Rate-limit login, token, and sensitive API endpoints.
- Validate request data and escape output. For database queries, use prepared statements and review How to Prevent SQL Injection in WordPress, PHP, and MySQL.
- Record authentication failures without logging complete credentials or bearer tokens.
- Test unauthorized, expired, malformed, and replayed requests.
When to hire a WordPress API developer
Authentication deserves extra care when an integration handles WooCommerce orders, customer records, payment systems, CRMs, warehouses, or AI services. A quick solution that works in testing may fail when tokens expire, webhooks are replayed, or a connected account has more permissions than intended.
For a custom WordPress REST API, WooCommerce integration, OAuth connection, webhook system, or security review, a full-stack WordPress and PHP developer can help design the flow, build the plugin, test failure cases, and document the setup. Addressing these decisions before production is generally easier than repairing an exposed or unreliable integration later.
For a broader development workflow, see the custom software development process for WordPress projects. If you need help with an existing site, this guide to finding WordPress experts for hire can help you assess the skills required.
Frequently asked questions
Are API keys safer than passwords?
They can be easier to manage because they can be scoped, rotated, and revoked independently. They are still secrets, however, and need protection comparable to passwords.
Can a WordPress nonce be used as API authentication?
A nonce primarily protects WordPress browser requests against CSRF. It does not replace proper authentication for an external application or provide a complete long-term access-control system.
Should JWTs contain user passwords?
No. JWT claims may be readable by the token holder, and passwords or other sensitive credentials should never be included in a token.
What is the best method for WooCommerce?
It depends on the integration. A controlled server may use scoped credentials, while a user-approved connection may use OAuth. In either case, restrict permissions and protect order and customer data.
Conclusion
API keys provide a simple option for controlled integrations, Application Passwords fit trusted WordPress automation, OAuth supports user-approved connections, JWTs suit token-based applications, and HMAC helps verify signed server requests. Whichever approach you select, pair it with HTTPS, least privilege, validation, rate limiting, rotation, and careful logging. When an integration handles payments, orders, or customer data, experienced WordPress API development can reduce security and maintenance risks.