Un par de escenarios podrían ayudar a ilustrar el propósito de acceder y actualizar los tokens y las compensaciones de ingeniería en el diseño de un sistema oauth2 (o cualquier otra autenticación):
Escenario de aplicación web
En el escenario de la aplicación web, tiene un par de opciones:
- si tiene su propia administración de sesión, almacene tanto access_token como refresh_token en su ID de sesión en estado de sesión en su servicio de estado de sesión. Cuando el usuario solicita una página que requiera que usted acceda al recurso, use access_token y si access_token ha expirado, use refresh_token para obtener la nueva.
Imaginemos que alguien logra secuestrar tu sesión. Lo único que es posible es solicitar sus páginas.
- Si no tiene administración de sesión, coloque el access_token en una cookie y úselo como sesión. Luego, cada vez que el usuario solicite páginas de su servidor web, envíe el access_token. Su servidor de aplicaciones podría actualizar access_token si fuera necesario
Comparando 1 y 2:
En 1, access_token y refresh_token solo viajan a través del cable en el camino entre el servidor de autorización (google en su caso) y su servidor de aplicaciones. Esto se haría en un canal seguro. Un hacker podría secuestrar la sesión, pero solo podría interactuar con su aplicación web. En 2, el pirata informático podría quitar el access_token y formar sus propias solicitudes a los recursos a los que el usuario ha otorgado acceso. Incluso si el hacker obtiene el acceso a token, solo tendrá una ventana corta en la que podrá acceder a los recursos.
De cualquier manera, el servidor de actualización solo reconoce el Id. De cliente y el secreto, lo que hace que desde el navegador web sea imposible obtener acceso a largo plazo.
Imaginemos que está implementando oauth2 y establece un tiempo de espera largo en el token de acceso:
En 1) No hay mucha diferencia aquí entre un token de acceso corto y largo ya que está oculto en el servidor de aplicaciones. En 2) alguien podría obtener el access_token en el navegador y luego usarlo para acceder directamente a los recursos del usuario durante mucho tiempo.
Escenario móvil
En el móvil, hay un par de escenarios que conozco:
Almacene clientid / secret en el dispositivo y ordene el dispositivo para obtener acceso a los recursos del usuario.
Use un servidor de aplicaciones back-end para guardar el ID de cliente / secreto y que haga la orquestación. Use access_token como una especie de clave de sesión y páselo entre el cliente y el servidor de aplicaciones.
Comparando 1 y 2
En 1) Una vez que tiene clientid / secret en el dispositivo, ya no son secretos. Cualquiera puede descompilar y luego comenzar a actuar como si fuera usted, con el permiso del usuario, por supuesto. Access_token y refresh_token también están en la memoria y se puede acceder desde un dispositivo comprometido, lo que significa que alguien podría actuar como su aplicación sin que el usuario otorgue sus credenciales. En este escenario, la longitud de access_token no influye en la piratería ya que refresh_token está en el mismo lugar que access_token. En 2) el clientid / secret ni el token de actualización están comprometidos. Aquí, la duración de la expiración de access_token determina cuánto tiempo un hacker podría acceder a los recursos de los usuarios, en caso de que se apoderen de él.
Longitudes de caducidad
Aquí depende de lo que esté asegurando con su sistema de autenticación en cuanto a la duración de su vencimiento access_token. Si es algo particularmente valioso para el usuario, debe ser breve. Algo menos valioso, puede ser más largo.
Algunas personas como google no caducan el refresh_token. A algunos les gusta el stackflow. La decisión sobre el vencimiento es una compensación entre la facilidad y la seguridad del usuario. La longitud del token de actualización está relacionada con la longitud de retorno del usuario, es decir, configure la actualización con la frecuencia con la que el usuario regresa a su aplicación. Si el token de actualización no caduca, la única forma de revocarlo es con una revocación explícita. Normalmente, un inicio de sesión no revocaría.
Espero que la publicación más larga sea útil.