Al proteger las API de REST para aplicaciones móviles, lo que se ve a menudo es el uso de tokens de actualización. Existen porque:
- Los tokens de acceso tienen fecha de caducidad.
- No queremos que el usuario tenga que ingresar sus credenciales.
Los tokens de actualización son tokens revocables sin fecha de caducidad que se pueden usar para recuperar un token de acceso nuevo cuando el último ha caducado. Consulte aquí .
En todas sus llamadas a la API, se enviará el token de acceso (válido). Cuando caduca, utiliza su "clave especial" (el token de actualización) para obtener otro token de acceso no caducado.
¿Por qué este patrón ampliamente utilizado es inferior o diferente a la simple emisión de un token de acceso que no caduca y al almacenarlo en el dispositivo, de la misma forma en que habría almacenado su token de actualización?
PD: Si su respuesta a esto es que enviar el token que no caduca en cada solicitud es menos seguro (intermediario), diría: ¿es realmente cuando su API ha superado el HTTPS? (Además, de todos modos, do envía un token que no caduca en la misma red, simplemente lo llama "token de actualización" y lo envía con menos frecuencia).
PS2: si su respuesta se relaciona con la capacidad de revocar tokens de actualización, supongo que podría argumentar que también podríamos hacer que nuestros tokens de acceso sean revocables.