Application Passwords: add a safer authorize flow for browser-based apps

[alekmitch]

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.