A long-lived token is needed if users shall be kept logged in to your service, for example via a mobile app, without having to repeat their consent over and over again. On the other hand, users must be able to revoke their consent (for example, after losing their mobile phone) or reduce its scope (for example, if the authorized app shall no longer be able to write to their service account, only read from it).

This means that before accepting a request, the server must not only validate the token but also verify that the user has not revoked it. For better performance, the two tasks are distributed between the resource server and the authorization server.

• The resource server validates the access token. This can be done by verifying a signature, without accessing a database or so. The scope of the user consent can be contained in the access token (a claim in a JWT, say), or can be kept in a cache. This allows the resource server to quickly execute many requests without verifying the scope for each. There is a risk that a revocation of user content is not detected, but this risk is mitigated by making the access token short-lived.
• After the short-lived access token has expired, the client making the request still has the long-lived refresh token. This must be sent to the authorization server in order to obtain a new access token, and during this step the user consent is verified again, for example, by accessing the user database. This may lead to a reduction in scope, or to no access token being issued at all. This more expensive operation happens less often than a request to the resource server.

Even if your server plays both roles of authorization and resource server, it may make sense to distribute the tasks in the same way.