WordPress application passwords: fix a rejection and revoke access

Distinguish an API rejection from dashboard login

You generated an application password in WordPress, but your tool receives a 401 error or a message saying authentication is incorrect. Your account may still open the dashboard normally. The desired result is an API request recognized as coming from the correct user, then authorized to perform only intended actions.

This guide concerns native application-password authentication on self-hosted WordPress. This feature has existed since WordPress 5.6. It serves software querying site interfaces; it does not replace the password you enter in the usual login form. WordPress.com, plugin-specific API keys and external-service authorizations follow other routes.

Record the WordPress version, exact requested address, software used and complete message while hiding secrets. A 401 error alone does not prove the password was copied incorrectly: protection in front of WordPress may also reject the request. Conversely, successfully viewing a public page does not prove the API identified you. Begin with a limited test distinguishing these situations instead of repeatedly creating credentials.

If your tool works but its access must be removed, go to the inventory and revocation route at the end of the guide. The intended success is then rejection of the old secret while authorized integrations remain functional. You do not need to provoke a 401 error first.

Check the account, site and secret type

An application password belongs to a user in a specific installation. With your authorized account, open Users, Profile, or Users, All Users, then Edit for the relevant user. Find the Application Passwords section and the row corresponding to the tool being configured.

Confirm this is the account whose login username you use. The name visible below a post is not always that username. Also verify the target WordPress host and path: a secret created on staging must not be assumed valid on the public site. The same username on two installations does not make them interchangeable. Conversely, a full database copy may retain still-valid secrets: changing domains does not revoke them. Check each environment’s access separately.

The software field must receive the generated application password, not the account’s main password, a third-party service key or a one-time login token. The generated secret is displayed only when created. If you no longer have it, WordPress cannot display it again from this list; prepare a targeted replacement instead of trying to reveal database-stored values. Keep the existing row’s name and date to identify access precisely during diagnosis.

Prepare a comparison that sends nothing to visitors

The initial test should read account identity without creating a post, sending email or changing a product. Arrange access to your WordPress profile and, if using the suggested command, a terminal in a trusted environment. You do not need to become a super administrator or install a new plugin for this comparison.

Keep current connector settings in a private note before changing them, without copying its secret into a shared report. Record the URL, authentication mode and account username. The goal is to restore the initial configuration if testing shows the problem lies elsewhere.

Then choose two separate observations: the minimal request below and the failing request in your usual software. If the first works, focus on that software and its route. If both fail, check the account, feature availability and route to WordPress. This avoids sequentially disabling every site protection without knowing which is involved. Do not send your application password to a person or public diagnostic tool to obtain these results.

Make an isolated GET test without putting the secret in the command

The following command suits a terminal where curl is already available. Replace the fictional username and URL with your values, retaining any installation path. In Windows PowerShell, explicitly use curl.exe if curl refers to another command. The --disable option, placed first, avoids loading a personal curl configuration file that could distort the test.

curl requests the password separately: enter the application secret then, without adding it to the command line. The URL requests your own profile through GET, so it asks for no content modification. The result contains account information; keep it private and record only the expected identity, status and any error message.

If your installation does not use pretty permalinks and the route returns 404, ask the maintainer to confirm the HTTPS variant /?rest_route=/wp/v2/users/me, appended after the installation path. A missing route does not prove a bad secret.

The test does not reuse browser cookies or automatically follow redirects. If you receive a redirect, first inspect its destination and use the canonical HTTPS address. Do not add an option forwarding credentials to a different destination without checking. Also do not ignore certificate errors: a TLS failure must be fixed before authentication. This command is an example to run on your authorized site; no result is assumed in advance.

curl --disable --basic --user 'VOTRE_IDENTIFIANT' --connect-timeout 5 --max-time 15 --write-out '\nHTTP %{http_code}\n' 'https://votre-site.example/wp-json/wp/v2/users/me'

Read the response before changing permissions

The expected response from this route is a JSON document corresponding to the identified account. Verify its username is the intended one instead of merely checking for 200. An HTML login page returned with HTTP success is not a valid WordPress identity response. A hosting block page may also precede API processing.

If the WordPress response says the user is not logged in or credentials are incorrect, keep its code and message without publishing the Authorization header. If it is an HTTP protection page, record the protection’s name. A certificate error, network timeout and password error require different corrections.

If identity is correctly recognized but another route rejects an action, minimal authentication succeeded. Then check account capabilities and that route’s requirements. A request for administration settings differs from reading your own profile. Do not grant Administrator merely because a response contains 403 or 401: first identify the layer and check producing the rejection. HTTP status is a clue to correlate with the response body, not a sufficient conclusion.

Check HTTPS and feature availability

On a public site, use an HTTPS address with a valid certificate matching the intended domain. Core normally makes application passwords available with HTTPS or in a recognized local environment. Forcing the feature on a public HTTP site would expose credentials in transit; that is not a solution to rejection.

When the profile section is absent or WordPress reports the feature unavailable, the maintainer also checks HTTPS detection behind any proxy. HTTPS in the browser does not always describe how PHP receives the request. Configuration must follow the host’s intended trust path.

WordPress filters, a security plugin or custom code may disable this method globally or for certain accounts. Review existing policy before changing it. If disabling is intentional, use an administrator-approved login method; do not copy a filter reactivating everyone merely to make a field appear. The expected result is availability consistent with site policy and the affected account. For a configuration correction, preserve its previous value and validate the same minimal test afterward.

Correct the client when the minimal test works

If identity reading succeeds with curl, keep the same account, secret and URL when comparing your usual software. In its site connection screen or authentication settings, choose Basic Authentication when this integration actually uses native application passwords. The user field receives the WordPress username and the password field the application secret.

Remove only conflicting parameters added for this test: an old Bearer token, manually entered Authorization header or cookies imported from the browser. A client should not manufacture multiple incompatible methods for one request. If the software expects plugin-specific keys, consult its documentation instead of putting a WordPress secret in a field intended for another use.

Then perform the same identity read before retrying publication. The expected result is recognition of the same account through both routes. If the software still fails, restore saved settings and send the maintainer the chosen method’s name and received message. Do not include the secret. A difference between equivalent requests gives a concrete client-side lead; it does not justify changing every account or replacing site authentication.

Check capabilities only after successful identification

An application password does not automatically give software a more powerful role. Available actions depend on the owning account, API-exposed capabilities and any site restrictions. Reading your own profile and modifying other authors’ content are different requests.

Under Users, All Users, the authorized administrator examines the account’s role against the function actually required. In multisite, they also check assignment to the targeted subsite. A network user may lack the required role on that subsite. The check must concern the correct URL and record without turning a local difficulty into super-administrator assignment.

If a capability is genuinely missing, the administrator chooses the minimum suitable role or a dedicated integration account according to site policy. The application password’s name identifies it; the name alone does not restrict permissions. After an authorized change, validate identity reading, then a nonpublic operation matching the need on the intended test copy. If the function requires more privileges than necessary, review the software’s route. Raising a role does not fix credentials WordPress never receives.

Have Authorization header forwarding checked

When secret and account are consistent but WordPress continues treating the request as anonymous, the Authorization header’s path becomes a hypothesis to check. A proxy, web server, protection rule or PHP connection may intervene before core. Public access to the REST URL does not verify this forwarding.

The maintainer correlates your exact test time with server and application logs. Ask them to confirm header presence at the correct level without recording or returning its value. In Basic Authentication, the value contains encoded credentials; encoding does not make it publishable. A full request capture can therefore compromise the secret.

The correction must happen at the identified layer and follow the actual hosting setup: proxy, server or PHP-handler configuration. An Apache directive copied into a setup served by Nginx does not address the same need. Do not add several recipes to random files. The administrator retains previous configuration, applies one documented correction and compares the same identity read. If nothing changes, they revert it before testing another hypothesis. A security rejection must be explained by its rule and scope instead of handled by globally disabling the firewall.

Distinguish staging protection from WordPress authentication

A copy may request an HTTP username and password before WordPress even loads. Those credentials protect staging; they differ from the WordPress account and application secret. If this layer already consumes the Authorization header for Basic authentication, the request may no longer present the credentials WordPress needs.

Do not try to resolve this conflict by adding two Basic headers or mixing both credential pairs in one field. Check the copy’s protection panel for the active method and applicable path. The maintainer can then design diagnostic access compatible with the copy’s policy, for example through the team’s existing private route while preserving isolation.

The expected result is a request passing environmental protection while supplying WordPress its own authentication. This sometimes requires changing the access method rather than the secret. Do not expose all staging publicly for one successful test. Afterward, restore temporary access under the planned procedure and verify private copy pages remain protected. Compare success on the public site and failure on the copy with this infrastructure difference in mind.

Inventory access before intentional revocation

Before removing a working secret, confirm the tool, account and site with its administrator. Its label helps identify it but is insufficient evidence when several rows have similar names. In the profile, correlate name, creation date and observed use with private connector configuration. Record the intended decision: stop the integration or replace its secret.

Last-used date and last IP address are clues. Core records these details again only after at least twenty-four hours since the previous recording; they are not a log of every request. A successful identity read may therefore not immediately change the displayed date. To validate your test, compare the identity route’s response and your call time. Absence of a recent timestamp is insufficient to declare a monthly process abandoned, and a relay IP does not necessarily identify a person.

Create a short list of functions to retain, such as reading a report and synchronizing a working draft. If several tools share one secret, revocation affects all of them. In multisite, the secret belongs to the network account: removing it from one subsite may interrupt integrations on other subsites using it. The command URL does not limit revocation to one subsite. Prepare separation before planned removal. Conversely, an exposed secret requires an immediate security decision; do not artificially wait for a processing cycle while leaving it active.

Choose between permanent removal and secret rotation

For a discontinued integration, open Users, Profile, or the authorized record of the affected account. Under Application Passwords, find the confirmed row and choose its Revoke button. Read the confirmation and verify only that row disappears. Do not revoke all secrets to save a step. The account, its posts and secrets in other rows must remain.

For a tool still needed, follow the rotation steps below. They assume the old secret may remain authorized during this brief transition. If a leak is suspected, the administrator first decides on immediate removal and targeted interruption.

If the new secret fails before removing the old one and no leak is suspected, temporarily restore the client’s still-authorized private configuration during diagnosis. If the old secret is compromised, do not return to it to restore service: accept targeted interruption and fix the new route. The administrator must record the decision.

1. In the confirmed account profile, enter a distinct name under New Application Password Name, then choose Add New Application Password. Labels may vary with translation.
2. Place the value displayed once into the integration’s secret manager; do not paste it into a ticket or command history.
3. Replace only this client’s secret. Verify identity reading and the expected function without publication or external effects.
4. Revoke the precisely identified old row, then perform the negative and positive checks at the end of the route.

Optional route: read the list with WP-CLI

A maintainer already equipped with WP-CLI and authorized server access can list the exact account’s secrets. These subcommands exist from WP-CLI 2.6; if absent, use the interface instead of modifying the database. This route does not authorize inspecting every user.

In the example, replace the installation path, address and 123 with confirmed site and account values. Output exposes private metadata, not reusable secret values. Keep it protected. The uuid field identifies the row to remove; it is neither the name nor app_id describing the application. If several rows look alike, compare dates and configuration before choosing. Do not request password: it contains a hash unnecessary for this diagnosis.

Before any delete command, compare this UUID with the targeted row’s record and have the integration administrator confirm the operation. If the list does not match the expected installation or account, stop this route. WP-CLI operates with server-access authority: choosing a URL or user does not replace authorization to act on that account. Empty output or a connection error does not prove no access remains.

wp --path='/chemin/wordpress' --url='https://votre-site.example/' user application-password list 123 --fields=uuid,name,created,last_used,last_ip --format=json

Revoke only the confirmed UUID with WP-CLI

After this read, the command below removes one application password. Replace UUID_CONFIRME with the actual recorded UUID and use exactly the same path, URL and user. Do not replace this parameter with an approximate name. Add neither an option targeting every secret nor a loop over users.

Read the output: a message saying one secret was deleted must be followed by another list read, not an assumption about all account access. Other UUIDs must remain. If the operation fails, retain its message and recheck context; do not multiply deletions to obtain a positive result.

Revocation provides no undo button to recover the same secret. If the wrong access was removed, functional recovery means creating a new authorized secret and updating its client. Do not restore the entire site database: that could reintroduce revoked access and overwrite recent content. Correction must remain limited to the affected integration.

wp --path='/chemin/wordpress' --url='https://votre-site.example/' user application-password delete 123 UUID_CONFIRME

Verify the expected rejection and retained integrations

From a trusted terminal, repeat identity reading with the old secret without cookies or added authentication methods. It must no longer identify the account through that secret. Compare the WordPress status and message with the previous result. A network block or globally disabled feature makes the test inconclusive: disappearance of only the targeted UUID and success of retained access must also be established. A public display or HTML login page does not establish this check. If the old secret seems to work, first verify the client was not already reconfigured and targets the intended site.

Then validate identity reading with the new secret or a retained authorized integration. Check the next scheduled process without triggering a real order, email or publication as a test. The desired pair of results is precise: removed access rejected, retained access functional. A widespread failure requires contextual diagnosis, not rushed creation of new secrets for everyone.

Revoking this secret does not close browser sessions, change the main password or remove keys belonging to other services. Examine those access methods separately if the decision concerns a departing collaborator or incident.

Finally remove unnecessary configuration from the discontinued client and follow your secret-retention policy. Keep the integration name, removed UUID, decision maker, date and performed checks in the report without the secret value. This record does not assert there was no prior use; it documents removal performed.

Close diagnosis with a reproducible record

Keep a record of the established cause and supporting check: obtained identity, requested route, client correction, account availability or affected server layer. Add the test time and canonical address. A usable record contains neither the secret, Authorization value nor an export of all browser cookies.

First validate identity reading after the correction, then the real function in an appropriate environment and content. An operation sending notifications, creating an order or publishing a post must not become a simple connection test. If identity remains correct but a business function fails, open diagnosis specific to that function while retaining this result as a starting point.

No new authentication plugin is needed for this guide’s native routes. A plugin adding another method will not automatically repair header forwarding and may complicate comparison. To prevent recurrence, maintain a mapping of account, tool, secret name and maintenance owner, then revoke unnecessary access under your policy. This tracking simplifies targeted replacement and distinguishes a technical failure from access that no longer has a reason to exist.