Se necesita un token de larga duración si los usuarios deben permanecer conectados a su servicio, por ejemplo, a través de una aplicación móvil, sin tener que repetir su consentimiento una y otra vez. Por otro lado, los usuarios deben poder revocar su consentimiento (por ejemplo, después de perder su teléfono móvil) o reducir su alcance (por ejemplo, si la aplicación autorizada ya no podrá escribir en su cuenta de servicio, solo leer de eso).

Esto significa que antes de aceptar una solicitud, el servidor no solo debe validar el token, sino también verificar que el usuario no lo haya revocado. Para un mejor rendimiento, las dos tareas se distribuyen entre el servidor de recursos y el servidor de autorizaciones.

• El servidor de recursos valida el token de acceso. Esto se puede hacer mediante la verificación de una firma, sin acceder a una base de datos o algo así. El alcance del consentimiento del usuario puede estar contenido en el token de acceso (un reclamo en un JWT, por ejemplo) o puede guardarse en un caché. Esto permite que el servidor de recursos ejecute rápidamente muchas solicitudes sin verificar el alcance de cada una. Existe el riesgo de que no se detecte una revocación del contenido del usuario, pero este riesgo se mitiga haciendo que el token de acceso sea de corta duración.
• Después de que haya expirado el token de acceso de corta duración, el cliente que realiza la solicitud todavía tiene el token de actualización de larga duración. Este debe enviarse al servidor de autorizaciones para obtener un nuevo token de acceso, y durante este paso se verifica nuevamente el consentimiento del usuario, por ejemplo, accediendo a la base de datos del usuario. Esto puede conducir a una reducción del alcance o a que no se emita ningún token de acceso. Esta operación más costosa ocurre con menos frecuencia que una solicitud al servidor de recursos.

Incluso si su servidor desempeña funciones de autorización y servidor de recursos, puede tener sentido distribuir las tareas de la misma manera.