Application password UX improvements

[johnbillion]

This ticket covers several related UX improvements for the application password approval screen.

These apply to the screen at wp-admin/authorize-application.php and its various URL query parameters.

1. Increase clarity about the target URL that will receive credentials if the request is approved. The only aspect of this URL that the user should be concerned about is its host name, and it should be front and centre.
2. Remove support for username:password@ credentials in URLs. These are deprecated in modern browsers and used almost exclusively for phishing.
3. Remove support for a reject URL. If a user rejects a request, a reject URL allows the user to still be phished.
4. Add a "Copy" button to the generated application password after approval.

I've been working on these enhancements in ​https://github.com/WordPress/wordpress-develop/pull/11079.

Any further suggested improvements should go into separate tickets.

Related: #62064

Work in progress.

A collection of UX enhancements for the authorize-application.php screen, with a particular focus on hardening against phishing.

• Greatly increase clarity about the target URL that will receive credentials if the request is approved
  • Shows the target host name front and centre without the rest of the URL
  • Gates approval behind a checkbox
• Removes support for username:password@ credentials in URLs
  • These are almost exclusively used for phishing
  • Despite being deprecated in modern browsers for many years, they're still technically functional, but there is no need to support them
• Removes support for reject URLs
  • If a user rejects approval, it is unexpected that they still get sent to the requesting site
  • This is an open redirect that can still result in phishing
  • Replaces the redirect with a message stating that the request was not approved
• Adds a "Copy" button to the generated application password after approval
  • Matches the one used on the Application Passwords section of the user profile screen

## Screenshots

## Ticket

I liked this - comparing with the current UX, this has better improvements :+1:

plus the additional confirmation step for external redirects.

One thing I'm wondering about: should confirm_external_redirect also be validated server-side when approving a request with a success_url?

The checkbox is required in the form and the approve button is gated in JS, but the no-JS PHP approval handler doesn't check whether confirm_external_redirect was submitted before creating the application password.

That means a direct POST with a valid nonce could bypass the confirmation step. Since this change is intended to make users explicitly acknowledge where their credentials will be sent, would it make sense to enforce that acknowledgement server-side as well (at least when success_url is present)?

I think a direct POST is fine, the checkbox is a safety net more than an enforcement.

Judging from the ​screenshot I'd like to propose some changes in the copy, to make things even clearer and easier scannable:

`
**An application would like to connect to your account.**

New Application Password Name:
[ ________ ]

An application would like to connect to your account. You should only do this if you trust the application in question.
The application identifies itself as: **Google Analytics**
The application will get access to:
- your username
- new application password
The data will send to: **evil.com**

[ ] I understand that my username and a new application password will be sent to evil.com

``

And then, when a application password was created, I think we should add links to the success screen:

• Delete password
• Show all application passwords

[im3dabasia1]

I’m going through the 7.2 tickets ahead of beta 1.

Thank you for the work on this, @johnbillion. With beta 1 only a few days away, is 7.2 still a realistic target? If it needs more time, we can move it to 7.3, and I’ll check back on Monday.