Application password with REST API fails when logged in (Unauthorized), works when logged out — Regression from WP 6.8.2

[elabinnovations]

Description

After updating to WordPress 6.8.2, requests using Application Passwords with the REST API fail with 401 Unauthorized when the user is logged in to WordPress in the browser.

This behavior did not happen in earlier versions. Previously, REST API calls authenticated via Application Passwords worked regardless of login state.

Steps to Reproduce

1. Create a new Application Password from the User Profile page.
2. Use the password in a REST API request (e.g., via Postman or curl).
3. While the user is logged in to the site in the browser, the REST call returns 401 Unauthorized.
4. If the user logs out, the same request starts working again.

Expected Behavior

Application Password authentication should work independently of the browser login state, as it did in previous versions.

Actual Behavior

REST requests using Application Passwords fail when the associated user is logged in.

Environment

• WordPress version: 6.8.2
• Browser: Any
• Auth: Application Password (Basic Auth)
• REST API endpoint: Any (e.g., /wp-json/wp/v2/posts)

Regression

This issue is a regression — it worked properly in WordPress 6.8.1 and earlier.

Additional Notes

This could potentially be related to recent security hardenings or session validation changes. Please investigate the recent updates to auth/session handling.

[mindctrl]

Hi @elabinnovations,

Welcome to Trac, and thanks for the report!

I've tried to reproduce the issue you describe, but so far have been unable to do so. My application passwords work as expected over the REST API, regardless of login status in the browser.

Can you share more information about your site's setup? Do you have any plugins that might be limiting the number of concurrent logins per user? In any case, it would be helpful to know which plugins you have active, which theme, which PHP version, etc.

[elabinnovations]

Hi @mindctrl,

Thank you for your patience. I've been working on an open-source financial management plugin called Pika as an alternative to Firefly III and Firefly Pico.

Plugin Information

Download: [Pika v1.0.0 ZIP](​https://elabins.com/wp-content/uploads/2025/08/pika-v1.0.0.zip)
Repository: [GitHub - e-labInnovations/pika](​https://github.com/e-labInnovations/pika)

Installation & Testing Steps

1. Install the plugin from the ZIP file
2. Create an Application Password in WordPress Admin → Users → Profile → Application Passwords
3. Access Pika at yourdomain.com/pika
4. Login using your WordPress username and the generated application password

Issue Description

The authentication issue occurs specifically when:

• ✅ WordPress logged in → Pika shows "Unauthorized" error
• ✅ WordPress logged out → Pika works perfectly

This suggests a conflict between WordPress session management and the plugin's REST API authentication.

Environment Details

WordPress Version: 6.8.2
PHP Version: 8.2.28
Server: Apache/2.4.62 (Debian)
Database: MySQL 9.3.0
Debug Mode: Enabled

Active Plugins:

• Pika Financial Management (v1.0.0)
• FluentCRM (v2.9.60)
• Fluent Boards (v1.65)

Technical Context

The plugin uses WordPress REST API with Application Passwords for authentication. The issue appears to be related to session handling when a user is simultaneously logged into WordPress admin and trying to access the PWA interface.

Could you please test this scenario and let me know if you encounter the same authentication conflict?

Note: This is a local development environment using Docker with debug mode enabled for testing purposes.

[mindctrl]

Hi @elabinnovations, thanks for the extra details. I'm able to reproduce the issue, but only with your plugin. Without your plugin, I can login simultaneously via browser using the typical cookie-based session, and I can also login and make REST API requests via Bruno using my App Password. Neither gets automatically logged out or rejected.

I only took a quick look at your plugin code, but I'm guessing there's some auth issue within. I noticed some places where you call check_auth manually while passing the $request param, but your implementation of check_auth doesn't accept parameters and doesn't reason about the request object. Since that method is defined as your permission_callback, it will be automatically called (and receive the WP_REST_Request $request param) by WordPress. That alone seems like it might create issues.

I don't think this is an issue with WordPress itself, and is some issue with the auth code within your plugin. I'm going to propose this ticket be closed, but maybe we can get a second opinion here to confirm.

[johnbillion]

There's no inherent connection between an authenticated REST API request and whether the authenticating user happens to be logged in elsewhere. They are independent states as far as authentication is concerned.

I'll close this off as per the above. Discussion can continue on a closed ticket if necessary.

[elabinnovations]

Hi @mindctrl
Thanks again
I’ve identified the problem: when the REST API request contains the wordpress_logged_in_* (eg: Cookie: wordpress_test_cookie=WP%20Cookie%20check; SignonSession=8d9e72a90f731d6429532f0ff72a26d3; wp_lang=en_US; wordpress_logged_in_70490311fe7c84acda8886406a6d884b=admin%7C1756707188%7CyY973u1MXtrAIGENdOKzfxKPN0FeNshlQFzPhZl1Odr%7C2d2ccdb1b4e95482f06806eed4e23329a96565e6159c04d95d77274d2145c1c2; user_id=1; wp-settings-1=deleted; wp-settings-time-1=1755497588 cookies, Application Password authentication fails.

If I strip those cookies, the Application Password works as expected.

So the issue is tied to being logged in — WordPress sets the wordpress_logged_in_* cookies during login, and those cookies interfere with Application Password authentication, causing it to fail with a 401 Unauthorized.