¿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. Funciona con 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 autenticé en 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 nuevo token de acceso, ya que nunca caduca. Así que no veo cómo esto puede ser 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 mezclen, aquí se detallan sus funciones en el marco de autorización de OAuth 2.0 :
- Los tokens de acceso los emite un servidor de autorización a clientes de terceros 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. El servidor de autorización emite tokens de actualización al cliente y se utilizan para obtener un nuevo token de acceso cuando el token de acceso actual deja de ser válido o caduca, 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 emitía un token de actualización en lugar de simplemente asegurar un token de acceso, la razón principal proporcionada por Internet Engineering Task Force en los tokens de actualización es:
Hay una razón de seguridad:
refresh_tokensolo se intercambia con el servidor de autorización, mientras que seaccess_tokenintercambia con los servidores de recursos. Esto mitiga el riesgo de que se filtre un token de acceso de larga duración en "un token de acceso válido por una hora, con un token de actualización válido por un año o válido hasta que sea revocado" frente a "un token de acceso válido hasta revocado sin actualización". simbólico."
Para obtener información más detallada y completa sobre 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 OAuth 2.0 emitido por Internet Engineering Task Force (IETF)
- Publicación SO: ¿Por qué OAuth v2 tiene tokens de acceso y de actualización?
El token de actualización tiene al menos dos propósitos. En primer lugar, el token de actualización es una especie de "prueba" de que un cliente OAuth2 ya recibió permiso del usuario para acceder a sus datos y, por lo tanto, puede solicitar un nuevo token de acceso nuevamente sin necesidad de que el usuario siga 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é ambos 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. Supongamos que usted, un Usuario, estaba utilizando una aplicación web de Cliente de terceros que quería 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 permiso nuevamente cuando su token de YouTube caduque? ¿Qué sucede si el tiempo de vencimiento del token de YouTube fuera muy bajo, como 5 minutos? ¡Sería un poco molesto que la aplicación Cliente le pidiera 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 de larga duración, lo que permite al Cliente obtener un nuevo acceso. token cuando uno caduca sin requerir el permiso del usuario (nuevamente).
Pero ¿por qué un token de actualización? Si el objetivo es no molestar al usuario con solicitudes de permiso, entonces ¿por qué el cliente no puede simplemente decir "Oye, 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 le 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. Cuando 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, permiso del Usuario, y el Cliente no tiene que volver a solicitarlo al Usuario.
Actualizar 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 es robado, o simplemente lo guarda una aplicación Cliente maliciosa que no lo elimina a petición del usuario? ¿No puede el atacante simplemente continuar? ¿Utilizar el token de actualización para obtener un token de acceso válido de forma indefinida (o hasta que caduque)? Esta pregunta lleva a discutir el segundo propósito que mencioné, que los tokens de actualización contribuyan a un flujo más seguro.
El problema que surge con los tokens de acceso es que, una vez adquiridos, sólo 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 está comprometido, entonces es trivial revocar o denegar el token de actualización en su totalidad y no tener que cambiar ninguna clave de firma.
Aquí está la información de la documentación de OAuth 2.0 .
Los tokens de actualización se utilizan para obtener un nuevo token de acceso cuando el token de acceso actual deja de ser válido o caduca, o para obtener tokens de acceso adicionales con un alcance idéntico o más limitado (los tokens de acceso pueden tener una vida útil más corta y menos permisos que los autorizados por el propietario del recurso).
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
(A) El cliente solicita un token de acceso autenticándose con el servidor de autorización y presentando una concesión de autorización.
(B) El servidor de autorización autentica al cliente y valida la concesión de autorización y, si es válida, emite un token de acceso y un token de actualización.
(C) El cliente realiza una solicitud de recurso protegido al servidor de recursos presentando el token de acceso.
(D) El servidor de recursos valida el token de acceso y, si es válido, atiende la solicitud.
(E) Los pasos (C) y (D) se repiten hasta que caduque el token de acceso. Si el cliente sabe que el token de acceso expiró, salta al paso (G); de lo contrario, realiza otra solicitud de recurso protegido.
(F) Dado que el token de acceso no es válido, el servidor de recursos devuelve un error de token no válido.
(G) El cliente solicita un nuevo token de acceso autenticándose con el servidor de autorización y presentando el token de actualización. Los requisitos de autenticación del cliente se basan en el tipo de cliente y en las políticas del servidor de autorización.
(H) El servidor de autorización autentica al cliente y valida el token de actualización y, si es válido, emite un nuevo token de acceso (y, opcionalmente, un nuevo token de actualización).
Usar solo el token de acceso es mucho más riesgoso que usar el token de acceso y el token de actualización .
Por ejemplo, solo utiliza el token de acceso con fecha de vencimiento de "100 días" , pero un día, un pirata informático roba el token de acceso . Ahora, el hacker tiene la gran oportunidad de utilizar libremente el token de acceso durante un máximo de 100 días para malos propósitos.
Ahora, utiliza el token de acceso con fecha de vencimiento de "60 minutos" y el token de actualización con fecha de vencimiento de "100 días" , pero un día, un pirata informático roba el token de acceso . Ahora, el hacker tiene muchas menos posibilidades de utilizar libremente el token de acceso durante 60 minutos como máximo para malos propósitos.
Ahora, pensarás si te roban el Refresh Token . En realidad, si un pirata informático roba el token de actualización , el pirata informático todavía tiene la gran posibilidad de utilizar libremente el token de actualización durante 100 días como máximo para malos propósitos. Pero la probabilidad de que se robe el token de actualización es mucho menor que la de que se robe el token de acceso porque el token de actualización se usa solo una vez cada 60 minutos para actualizar el token de acceso (para obtener un nuevo token de acceso ), mientras que el token de acceso se usa cada vez que accede a recursos, lo cual es mucho más frecuente.
Por lo tanto, será mejor que utilice tanto el token de acceso como el token de actualización .
