¿Cuál es el propósito de un "Token de actualización"?

Tengo un programa que se integra con la API de transmisión en vivo de YouTube. Se ejecuta en temporizadores, por lo que ha sido relativamente fácil para mí programarlo para obtener un nuevo token de acceso cada 50 minutos con un token de actualización. Mi pregunta es, ¿por qué?

Cuando me autentiqué con YouTube, me dio un Token de actualización. Luego uso este token de actualización para obtener un nuevo token de acceso aproximadamente una vez por hora. Si tengo el token de actualización, SIEMPRE puedo usarlo para obtener un token de acceso nuevo, ya que nunca caduca. Así que no veo cómo esto es más seguro que simplemente darme un token de acceso desde el principio y no molestarme con todo el sistema de token de actualización.

Básicamente, los tokens de actualización se utilizan para obtener un nuevo token de acceso.

Para diferenciar claramente estos dos tokens y evitar que se confundan, estas son sus funciones proporcionadas en el marco de autorización de OAuth 2.0 :

• Los tokens de acceso son emitidos a clientes de terceros por un servidor de autorización con la aprobación del propietario del recurso. El cliente utiliza el token de acceso para acceder a los recursos protegidos alojados por el servidor de recursos.
• Los tokens de actualización son credenciales que se utilizan para obtener tokens de acceso. Los tokens de actualización son emitidos al cliente por el servidor de autorización y se utilizan para obtener un nuevo token de acceso cuando el token de acceso actual deja de ser válido o expira, o para obtener tokens de acceso adicionales con un alcance idéntico o más limitado.

Ahora, para responder a su pregunta sobre por qué todavía se le emitió un token de actualización en lugar de simplemente asegurar un token de acceso, la razón principal proporcionada por el Grupo de trabajo de ingeniería de Internet en los tokens de actualización es:

Hay una razón de seguridad, el refresh_tokensolo se intercambia con el servidor de autorización, mientras que el access_tokense intercambia con los servidores de recursos. Esto mitiga el riesgo de que un access_token de larga duración se filtre en el "token de acceso válido durante una hora, con un token de actualización válido durante un año o válido hasta revocado" frente a un token de acceso válido hasta revocado sin una actualización simbólico."

Para obtener información más detallada y completa de OAuth 2.0 Flow, intente consultar las siguientes referencias:

• Flujo de OAuth 2.0: aplicaciones web del lado del servidor
• El marco de autorización de OAuth 2.0 emitido por el Grupo de trabajo de ingeniería de Internet (IETF)
• SO post - ¿Por qué OAuth v2 tiene tokens de acceso y actualización?

@Teyam menciona SO post ¿Por qué OAuth v2 tiene tokens de acceso y actualización? pero prefiero la otra respuesta allí: https://stackoverflow.com/a/12885823/254109

TL; DR refresh_token no brinda mayor seguridad. Tiene el propósito de mejorar la escalabilidad y el rendimiento. Luego, access_tokenpuede almacenarse solo en algún almacenamiento temporal rápido (como la memoria). También permite la separación del servidor de recursos y la autorización.

El token de actualización tiene al menos dos propósitos. Primero, el token de actualización es una especie de 'prueba' de que un cliente OAuth2 ya ha recibido permiso del usuario para acceder a sus datos y, por lo tanto, puede solicitar un nuevo token de acceso nuevamente sin que el usuario tenga que pasar por todo el flujo de OAuth2. Y en segundo lugar, ayuda a aumentar todo el flujo de seguridad en comparación con un token de acceso de larga duración. Tocaré estos dos puntos con un poco más de detalle.

Actualizar tokens como medio para no molestar al usuario

Hablemos del primer propósito con un ejemplo. Suponga que usted, un usuario, está utilizando una aplicación web de cliente de terceros que desea interactuar con los datos de su cuenta de YouTube. Una vez que otorgue permiso a la aplicación Cliente para usar sus datos de YouTube, ¿le gustaría que la aplicación Cliente le solicite su permiso nuevamente?¿Cuándo expiró su token de YouTube? ¿Qué sucede si el tiempo de vencimiento del token de YouTube es muy bajo, como 5 minutos? ¡Sería un poco molesto que la aplicación Cliente le pidiera su permiso al menos cada 5 minutos! La solución que propone OAuth2 a este 'problema' son los tokens de actualización. Al usar tokens de actualización, el token de acceso puede permanecer de corta duración (lo cual es deseable en caso de que el token de acceso se filtre o sea robado de alguna manera), y el token de actualización puede permanecer más tiempo (más) de vida, lo que permite al Cliente obtener un nuevo acceso token cuando uno expira sin requerir el permiso del usuario (nuevamente).

Pero, ¿por qué una ficha de actualización? Si el objetivo es no molestar al usuario con solicitudes de permiso, ¿por qué el cliente no puede simplemente decir "Hola, servidor de autorización, quiero otro token de acceso. ¡Ahora!" O, "Hola, servidor de autorización, aquí está mi token caducado, ¡dame uno nuevo!". Bueno, el token de actualización sirve como una especie de "prueba" de que un Usuario concedió acceso al Cliente en algún momento original. Esta "prueba" tiene la forma del token de actualización firmado digitalmente por el servidor de autorización. Si el cliente presenta un token de actualización, el servidor de autorización puede verificar que el cliente recibió, en algún momento del pasado, el permiso del usuario, y el cliente no tiene que volver a preguntarle al usuario.

Actualizar el token como medio para aumentar la seguridad

Sin embargo, esto plantea la pregunta: "Bueno, ¿qué sucede si el token de actualización se filtra o se lo roban, o simplemente lo mantiene una aplicación Cliente maliciosa que no se deshace de él a petición del usuario? ¿No puede el atacante simplemente continuar ¿Usar el token de actualización para obtener un token de acceso válido indefinidamente (o hasta que expire)? Esta pregunta lleva a discutir el segundo propósito que mencioné, de los tokens de actualización que contribuyen a un flujo más seguro.

El problema que surge con los tokens de acceso es que, una vez adquiridos, solo se presentan al servidor de recursos (YouTube, por ejemplo). Entonces, si un token de acceso es robado o comprometido, ¿cómo le dice al servidor de recursos que no confíe en ese token? Bueno, realmente no puedes. La única forma de hacerlo sería cambiar la clave de firma privada en el servidor de autorización (la clave que firmó el token en primer lugar). Me imagino que esto es un inconveniente y, en algunos casos (como Auth0), no es compatible.

Por otro lado, los tokens de actualización deben presentarse al servidor de autorización con frecuencia, por lo que si uno se ve comprometido, es trivial revocar o denegar el token de actualización en su totalidad y no tener que cambiar ninguna clave de firma.

"Así que no veo cómo esto es más seguro que simplemente darme un Token de acceso desde el principio y no molestarme con todo el sistema Refresh Token". Luché con la misma pregunta. La respuesta corta es que el token de actualización es necesario para garantizar que las credenciales no hayan expirado.

Un ejemplo puede ayudar: tengo una base de datos que almacena sus registros médicos. Usted da su consentimiento para compartir sus registros médicos con su cónyuge. Su cónyuge usa su token de acceso para leer sus registros de mi base de datos. Dentro de dos semanas, su cónyuge verifica nuevamente sus registros médicos y el token de actualización se usa para asegurarse de que todavía tengan permiso (del servidor de autenticación) para ver sus registros. El token de actualización evita la necesidad de que su cónyuge vuelva a ingresar sus credenciales (nombre de usuario y contraseña) en el servidor de autenticación, pero garantiza que aún tengan legitimidad para acceder al recurso. Un token de acceso que nunca caduca no sabría si usted ha revocado los derechos de su cónyuge para acceder a sus registros médicos.