Application Passwords Expiration

[mboynes]

As a developer, I want the option to set an "expiration" date on Application Passwords so that they aren't able to be used beyond the period of time that I know they'll be used.

Use case

I've been working with Application Passwords as a replacement for session cookies in an isomorphic decoupled website. I am generating them programmatically and treating them almost identically to sessions. Because they behave like sessions, I want them to expire. I'm working around this presently by including an expiration timestamp in the Application Password name.

While this feature request would solve that specific use case, I believe this would be a worthwhile addition to Application Passwords to add an option to make them more secure.

[JeffPaul]

@mboynes this seems like a reasonable request, though I'm curious if @georgestephanis or @timothyblynjacobs had considered this as part of the original merge to core and if there was a reason this was left out? Also curious if this is something that should be / needs to be exposed in the WP Admin UI or is better left to adjust as a filter? Confirming the ideal user flow would be helpful if someone wants to take a stab at that to help move this along?

[TimothyBlynJacobs]

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.