[wp-trac] [WordPress Trac] #65110: Application Passwords: add a safer authorize flow for browser-based apps

[WordPress Trac]

#65110: Application Passwords: add a safer authorize flow for browser-based apps
-----------------------------------+-----------------------------
 Reporter:  alekmitch              |      Owner:  (none)
     Type:  enhancement            |     Status:  new
 Priority:  normal                 |  Milestone:  Awaiting Review
Component:  Application Passwords  |    Version:
 Severity:  normal                 |   Keywords:
  Focuses:                         |
-----------------------------------+-----------------------------
 The current wp-admin/authorize-application.php browser authorization flow
 redirects to success_url with the newly generated Application Password in
 the URL query string.

 As documented in the integration guide, the success redirect currently
 includes:
  * site_url
  * user_login
  * password

 Current core JS still implements that behavior by appending the generated
 password to the redirect URL.

 This makes the flow awkward for browser-based web applications that want
 to avoid placing plaintext credentials in browser URLs. Depending on the
 environment, a URL can be captured by browser history, session restore,
 reverse proxy or CDN logs, observability tooling, analytics middleware, or
 browser extensions before the receiving application has any chance to
 scrub it.

 I am not proposing that the existing success_url behavior be removed or
 changed by default, since that would likely break existing consumers. The
 request is for an additive, safer completion mode for browser-based
 applications.

 Possible directions could include:
  * a form_post style response mode that returns the success payload in an
 auto-submitted HTML form POST instead of query parameters
  * another non-query transport with similar properties
  * a one-time code that the receiving application can redeem server-side
 for the generated Application Password

 The key requirement is to support completing the authorization flow
 without the generated Application Password appearing in the browser URL.

 In practice, the only core-only way I found to avoid this was to omit
 success_url entirely and require the user to copy the generated password
 manually from the WordPress page into the receiving application. That
 works, but it gives up the seamless browser handoff.

 Related tickets for context:
  * #57809 and #51581 show the success_url / reject_url flow is still
 active and maintained, but they do not address the transport of the
 generated password itself
  * #61644 discusses revocation by app_id, which is related operationally
 but does not solve the callback transport problem
  * #53995 is relevant background on Application Password lifecycle, but
 does not solve this callback transport issue either

 If there is already another ticket covering a safer callback transport for
 Application Password authorization, I would be happy to move discussion
 there.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65110>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform