Our OAuth 2.0 tokens are configured to expire in the very far future (about 292,277,000,000 years in the future).
This isn't a problem for APIs implemented in MediaWiki, since they can do an additional check in the database that the token has not been revoked by the user.
This isn't acceptable for APIs implemented in NodeJS or another system, which depend on the JavaScript Web Token (JWT) data to tell if a token is expired. If access tokens have infinite expiration dates, the user could revoke access, but the app could still keep using the JWT to call a NodeJS-based API, and everything would keep working.
Right now, the only API that's exposed through the API gateway that isn't in MediaWiki is Wikifeeds, which doesn't use the JWT. But future ones might.
OAuth 2.0 has a mechanism to require refreshing a token on some period. We should choose a refresh period that is more bounded, and that balances the hassle of having to refresh tokens with the risk of using a token that's been revoked. Somewhere between 1 hour and 1 day is probably reasonable.
I need to investigate the refresh period of some other services to see what's typical for OAuth 2.0 use.