Guide to WordPress REST API Authentication

Introduction to WordPress REST API authentication

WordPress API interface REST API is a powerful tool enabling access to WordPress content and functionality via HTTP requests from any application, whether mobile app, JavaScript frontend, external service, or completely separate web application. However, while reading public content is usually available without authentication, creating, updating, and deleting content requires the user to authenticate so WordPress knows who is performing the action and whether they have the necessary permissions.

WordPress supports multiple authentication methods for REST API, and each has its advantages, disadvantages, and ideal usage scenarios. The choice of the right method depends on who accesses the API (frontend on the same site, external application, mobile application), what level of security is needed, and how complex an integration you want to implement. In this guide, we go through each method in detail with practical examples.

Cookie authentication with nonce

Cookie authentication is the default method for requests coming from the WordPress site itself, typically from JavaScript code in the admin panel or on the frontend. When the user is logged into WordPress, the browser automatically sends a cookie with every request and the WordPress REST API uses it for user identification. However, the cookie alone isn't enough because that would enable CSRF attacks where a malicious site could trigger requests on behalf of the logged-in user.

How nonce works

WordPress uses nonce (number used once) as an additional layer of CSRF attack protection. Nonce is a time-limited token WordPress generates for the logged-in user that must be sent with every mutating request (POST, PUT, DELETE). JavaScript code gets it via the wp_localize_script() function or the wpApiSettings.nonce global variable in the admin panel.

• Generation - wp_create_nonce('wp_rest') on the server side
• Forwarding - wp_localize_script() for passing nonce to JavaScript
• Sending - X-WP-Nonce header or _wpnonce query parameter
• Validity - nonce expires after 24 hours (two WordPress nonce periods of 12h)
• Revalidation - for long-lasting sessions, periodically request a new nonce via API

Cookie authentication is ideal for JavaScript code executing on the WordPress site itself because it doesn't require any additional configuration beyond properly passing the nonce. It's not suitable for external applications because they can't access the WordPress cookie. Also, keep in mind that nonce expires and long-lasting sessions require a token refresh mechanism so the user doesn't get a 403 error mid-work.

Application Passwords

Application Passwords were introduced in WordPress 5.6 as a built-in method for authenticating external applications without giving the user's main password. Each user can create multiple application passwords with descriptive names (e.g., Mobile App, Zapier Integration, Custom Script) and each can be independently revoked without affecting others or the user's main password.

Creation and usage

Application password is created in the WordPress admin panel under Users, Edit User, Application Passwords section. You enter the application name and WordPress generates a 24-character password grouped in 4 groups of 6 characters separated by space. This password is used for HTTP Basic Authentication where username and application password are sent in the Authorization header encoded in base64 format.

A request with Application Password looks like standard HTTP Basic Auth: Authorization header contains Basic followed by the base64-encoded string username:application_password. Spaces in the password are ignored so you can remove them or leave them. WordPress automatically recognizes it's an Application Password and not the user's main password and applies appropriate permissions.

Advantages and limitations

• Simplicity - built-in functionality without need for plugins
• Granular control - each application has its own password that can be revoked
• Logging - WordPress records last use of each application password
• Limitation - works only over HTTPS because Basic Auth sends credentials in every request
• Limitation - no scope or permission granularity beyond user role

Application Passwords are an excellent choice for server-to-server integrations, ideal for VPS hosting environments, automation scripts, and applications where simplicity is more important than granular access control. Always use HTTPS because credentials are sent in every request and without HTTPS they can be intercepted. For production integrations, create a separate WordPress user with minimum necessary permissions instead of using an admin account.

OAuth 2.0

OAuth 2.0 is an industry standard for authorization used by Google, Facebook, GitHub, and many other services. WordPress doesn't have built-in OAuth support but it's available through plugins like WP OAuth Server and OAuth 2.0 Provider. OAuth is ideal for scenarios where you want to enable third-party applications to access your WordPress API with precise permission control without sharing user credentials.

OAuth 2.0 flow

The most common OAuth flow for web applications is the Authorization Code flow consisting of several steps. The application redirects the user to the WordPress authorize endpoint where the user approves access. WordPress redirects the user back to the application with an authorization code. The application exchanges the code for an access token by calling the token endpoint. The access token is then used for API requests in the Authorization Bearer header.

• Authorization Code - most secure flow for web applications with server side
• Implicit - for SPA applications without a server (less secure, usually not recommended)
• Client Credentials - for server-to-server communication without user context
• PKCE - Proof Key for Code Exchange, improves security for mobile and SPA applications

OAuth provides the highest level of control and security but is also the most complex to implement. Access tokens have limited duration and refresh tokens are used to get new ones without re-authorizing the user. The scope parameter defines which permissions the application requests, giving the user transparency about what the application can do with their data.

JWT (JSON Web Tokens)

JWT authentication is a popular alternative for REST API access using tokens instead of sessions. A JWT token is a signed string containing information about the user and permissions, sent in the Authorization header of every request. WordPress doesn't have built-in JWT support but it's available through plugins like JWT Authentication for WP REST API and Simple JWT Login.

How JWT works

The user sends username and password to the token endpoint (usually /wp-json/jwt-auth/v1/token) and gets a JWT token in response. This token is then sent in the Authorization: Bearer header of all API requests. The server verifies the token signature and extracts user information without needing to query the database, making JWT more efficient for high-load APIs.

The JWT token consists of three parts separated by dots: header (algorithm and token type), payload (user data, expiration time, issuer), and signature (cryptographic signature guaranteeing token integrity). The token can be decoded on the client side but can't be forged without the secret key known only to the server. This enables the client to read user information from the token without an additional API call.

JWT advantages

• Stateless - server doesn't store sessions, facilitating scaling
• Self-contained - token contains all necessary user information
• Cross-domain - works with different domains without CORS issues with cookies
• Mobile applications - ideal for mobile apps that don't use cookies
• Performance - token verification doesn't require database query

Comparison of authentication methods

The choice of authentication method depends on your specific scenario. Cookie and nonce are ideal for JavaScript on the same site because they don't require additional configuration. See our WordPress hosting plans for an optimal environment. Application Passwords are best for simple server-to-server integrations and scripts because they're built-in and easy to use. OAuth 2.0 is the right choice for third-party applications where granular access control and user authorization are needed. JWT is optimal for mobile applications and SPA frameworks communicating with WordPress as a headless CMS.

Security recommendations

• Always use HTTPS - all authentication methods require an encrypted connection
• Minimal permissions - create users with only necessary permissions for API access
• Token rotation - implement refresh tokens and short access token expiration
• Rate limiting - limit number of requests per user for brute-force protection
• Logging - record all API requests for audit and detection of malicious activities
• CORS configuration - restrict API access only from allowed domains

For production applications, we recommend a combination of multiple methods where each covers a different scenario. Cookie authentication for admin panel and frontend interactions, Application Passwords for internal scripts and automation, JWT for mobile applications, and OAuth for third-party integrations. Regularly review active tokens and application passwords and revoke those no longer in use because every active token is a potential attack vector.