[wp-trac] [WordPress Trac] #53995: Application Passwords Expiration

[WordPress Trac]

#53995: Application Passwords Expiration
-------------------------------------------------+-------------------------
 Reporter:  mboynes                              |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Application Passwords                |     Version:  5.6
 Severity:  normal                               |  Resolution:
 Keywords:  needs-patch needs-design needs-docs  |     Focuses:  rest-api
-------------------------------------------------+-------------------------
Changes (by TimothyBlynJacobs):

 * focuses:   => rest-api
 * version:   => 5.6


Comment:

 The idea of expiring tokens was explored in the context of having short-
 lived tokens with a longer-lived or non-expiring "refresh" token that you
 would use to mint a new short-lived token. We didn't go with it to keep
 the initial version as simple as possible. However, we probably wouldn't
 go with refresh-tokens regardless because the security benefit was fairly
 minimal, and IIRC from @rmccue's research for the OAuth REST API plugin,
 few OAuth providers implemented mandatory refresh tokens with a short
 expiration time.

 That being said, I do think having App Passwords with a permanent
 expiration would be very valuable to have in Core. An additional use case
 is using App Passwords to do a one-time flow with a user's site where you
 don't want to keep the App Password around for longer than the setup
 process. The Introspection endpoint introduced in 5.7 allows for an
 Application to cleanup after itself when it is finished, but an expiration
 date could add additional safeguards in case the user abandons the flow,
 not allowing the Application to delete it's token.

 The necessary filters exist so that a developer could add this feature if
 they desired, however I think there is a strong argument for supporting it
 in Core. That would allow for interoperability between different plugins
 that care about Application Passwords. In addition, it means that if an
 Application can use expiring Passwords even if they don't have a companion
 plugin already installed on the site.

 In terms of what UI is necessary, I do not believe we should expose an
 input field for controlling the expiration date when manually creating a
 token, either through `authorize-application.php` or the user's profile
 page. I think this would complicate the UI more than necessary for most
 cases. Additionally, a user may end up shortening or lengthening a token's
 expiration time in contrast to how the Application expects their token to
 function. Which could result in broken behavior if the token expires
 before the Application can finish using it, or sticking around for a long
 time even when the Application no longer cares for it.

 I do think we should indicate on `authorize-application.php` if an
 expiration time was provided when promoting the user to Approve the
 Application. Additionally, I think we should include the expiration time
 in the list table on the profile page. I think we should consider omitting
 expired tokens from that list table, as well as potentially deleting them
 ''x'' days after the token has expired. If we do hide the tokens, we need
 to consider that the UI may be potentially confusing if the user receives
 a "This application name is already used" error since they won't be able
 to see the existing App Password entry.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53995#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform