App Passwords: No stable way to identify applications

[TimothyBlynJacobs]

We should add support for an app_id parameter that applications could use when sending the user to authorize-application.php. Apps can already pass an app_name but this is just a suggestion and can be changed by the user when creating an app. The app_id would be a string unique to that application, and by default not displayed to the user.

Plugin developers could use this to add support for disabling all app passwords with a given app_id. This isn't to protect against bad actors, since they could use random ids each time, but for well behaving applications it would give administrators an easy way to "turn off" an application if they needed to.

By default, Core wouldn't enforce that the app_id is provided, but developers could using the wp_authorize_application_password_request_errors hook.

Technically, plugin developers could add support for app_id themselves too, but I think the chances are slim of clients passing an app_id if we don't include it as a suggestion in our documentation and provide a basic level of support.

​https://make.wordpress.org/core/2020/09/23/proposal-rest-api-authentication-application-passwords/#comment-39884

Trac ticket: https://core.trac.wordpress.org/ticket/51583

[TimothyBlynJacobs]

In 49276:

App Passwords: Support an app_id to uniquely identify instances of an app.

Apps may now optionally include an app_id parameter when directing the user to the Authorize Application screen. This allows for instances of an application to be identified and potentially revoked or blocked.

Props TimothyBlynJacobs, georgestephanis.
Fixes #51583.

Fixed in fe2053f2c1cff0c416112103988e832687ca3836.

[TimothyBlynJacobs]

In 49296:

REST API: Regenerate wp-api-generated.js after [49276].

See #51583.