Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

For authenticated REST API requests from JavaScript running on the same WordPress site as a logged-in user, use the user’s authentication cookie with a REST nonce. For a deployment script, scheduled job, integration, or other external API client, use an Application Password over HTTPS. A nonce helps protect against cross-site request forgery (CSRF); it does not log a user in or grant permission to perform an operation.

How the two authentication patterns work

Cookie authentication with a REST nonce

In a logged-in WordPress session, the browser’s authentication cookie identifies the user. For a REST request made in that context, the client also supplies a nonce created for the wp_rest action, commonly in the X-WP-Nonce header. WordPress documents this as the pattern for cookie authentication for same-origin requests.

The nonce helps WordPress distinguish a legitimate request made in the logged-in context from a forged cross-site request. It is not a password or a portable credential for an external client. WordPress explicitly warns: “Nonces should never be relied on for authentication, authorization, or access control.” The Nonces handbook also explains that WordPress nonces are time-limited but may repeat during their validity window; they are not guaranteed one-time-use tokens and do not prevent replay attacks.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Application Passwords

An Application Password is a separate credential associated with a WordPress user and intended for programmatic access, including REST API clients. It is not a substitute for the interactive wp-login.php process. WordPress introduced Application Passwords in version 5.6 in December 2020. The integration guide describes their purpose and use.

Clients typically send the WordPress username and Application Password using HTTP Basic Authentication in the Authorization header. Basic Authentication does not encrypt credentials, so send it only over HTTPS. Application Passwords are available by default over HTTPS, but a site’s configuration, plugins, or filters can disable the feature or restrict which users may use it. See WordPress’s Application Password authentication guidance.

Which method should you use?

Situation Use Why
JavaScript running on the same WordPress site while a user is logged in Authentication cookie plus REST nonce Uses the existing logged-in session and supplies the nonce needed for CSRF protection. WordPress documentation
Deployment script, scheduled job, integration, or external API client Application Password Designed for programmatic access; the credential can be revoked separately from the user’s primary password. WordPress integration guide
Interactive sign-in to the WordPress admin Neither as a login-form substitute Application Passwords are for programmatic access, not interactive browser login. Use the site’s normal login flow. WordPress integration guide
Permission to carry out a protected REST operation Capability and endpoint permission checks Authentication identifies the user; it does not automatically authorize every action. A nonce is not an access-control check. WordPress Nonces handbook

Authentication is not authorization

After WordPress recognizes a logged-in user, the endpoint still needs to check whether that user has the capability required for the requested operation. A valid nonce does not make an otherwise unauthorized request permissible, and an Application Password does not grant more privileges than the associated WordPress user has. For sensitive operations, ensure the endpoint’s permission checks match the action being performed.

Public site data is generally available through the REST API without authentication. Private content and restricted data require authentication unless the site has specifically configured otherwise. WordPress’s REST API FAQ outlines this distinction.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Use Application Passwords safely and troubleshoot failures

  • Use HTTPS. Basic Authentication sends credentials in a form that can be intercepted on an unencrypted connection. WordPress requires HTTPS for Application Password use by default.
  • Create a separate credential for each integration. Give each one a descriptive name so you can identify and revoke it without changing the user’s primary password. WordPress’s Application Passwords REST API reference documents the records and related operations.
  • Store the generated password securely. WordPress shows the generated value only when it is created. If it is lost, create a replacement rather than expecting to retrieve the original.
  • Check site restrictions. If Application Passwords are unavailable, site configuration, plugins, or filters may have disabled them or limited their use. The integration guide covers site-level support.
  • Check whether the Authorization header reaches WordPress. If the client sends an Authorization header but WordPress does not authenticate the request, server or CGI configuration may be stripping that header. WordPress lists this in its REST API FAQ.

The Application Passwords REST API can create, retrieve, update, inspect, and delete password records. Records can include a name, creation date, last-used date, and last IP; the generated password itself is available only after creation. See the official endpoint reference.

Practical decision rule

  • If code runs on the WordPress site in a user’s logged-in browser session, use cookie authentication with a wp_rest nonce.
  • If a separate program needs to authenticate to the site’s API, use an Application Password over HTTPS, subject to the site’s configuration.
  • In either case, enforce authorization through the user’s capabilities and the endpoint’s permission checks.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.