Puede que se de el caso de que halles algún fallo con tu código o trabajo, recuerda probar siempre en un entorno de testing antes aplicar el código al trabajo final.
Solución:
Esto es muy específico de la implementación, pero la idea general es permitir que los proveedores emitan tokens de acceso a corto plazo con tokens de actualización a largo plazo. ¿Por qué?
- Muchos proveedores admiten tokens de portador que son muy débiles en cuanto a seguridad. Al hacerlos de corta duración y requerir actualización, limitan el tiempo que un atacante puede abusar de un token robado.
- La implementación a gran escala no desea realizar una búsqueda en la base de datos cada llamada a la API, por lo que emiten un token de acceso autocodificado que se puede verificar mediante descifrado. Sin embargo, esto también significa que no hay forma de revocar estos tokens, por lo que se emiten por un período breve y deben actualizarse.
- El token de actualización requiere autenticación de cliente, lo que lo hace más fuerte. A diferencia de los tokens de acceso anteriores, generalmente se implementa con una búsqueda en la base de datos.
Un par de escenarios pueden ayudar a ilustrar el propósito de acceder y actualizar tokens y las compensaciones de ingeniería en el diseño de un sistema oauth2 (o cualquier otro sistema de 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 el access_token como el refresh_token contra su ID de sesión en el estado de sesión en su servicio de estado de sesión. Cuando el usuario solicita una página que requiere que acceda al recurso, use el access_token y si el access_token ha expirado, use el refresh_token para obtener el nuevo.
Imaginemos que alguien logra secuestrar su sesión. Lo único que es posible es solicitar tus páginas.
- si no tiene administración de sesiones, coloque el access_token en una cookie y utilícelo como una sesión. Luego, siempre que el usuario solicite páginas de su servidor web, envíe el access_token. Tu servidor de aplicaciones podría actualizar el access_token si es necesario.
Comparando 1 y 2:
En 1, access_token y refresh_token solo viajan por el 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 pirata informático podría secuestrar la sesión, pero solo podría interactuar con su aplicación web. En 2, el pirata informático podría quitarle el access_token y formar sus propias solicitudes a los recursos a los que el usuario ha otorgado acceso. Incluso si el pirata informático obtiene el access_token, solo tendrá una pequeña ventana en la que podrá acceder a los recursos.
De cualquier manera, el refresh_token y el clientid / secret solo son conocidos por el servidor, lo que hace imposible que el navegador web obtenga acceso a largo plazo.
Imaginemos que está implementando oauth2 y establece un tiempo de espera prolongado 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 la aplicación. 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 el ID / secreto de cliente en el dispositivo y haga que el dispositivo organice la obtención de acceso a los recursos del usuario.
-
Utilice un servidor de aplicaciones back-end para mantener el clientid / secret y hacer que se encargue de la orquestación. Usa el access_token como una especie de sesión key y pasarlo entre el cliente y el servidor de aplicaciones.
Comparando 1 y 2
En 1) Una vez que tenga clientid / secret en el dispositivo, ya no serán secretos. Cualquiera puede descompilar y luego comenzar a actuar como si fuera usted, con el permiso del usuario, por supuesto. El access_token y refresh_token también están en la memoria y se puede acceder a ellos en un dispositivo comprometido, lo que significa que alguien podría actuar como su aplicación sin que el usuario dé sus credenciales. En este escenario, la longitud del access_token no influye en la capacidad de pirateo, 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 del access_token determina cuánto tiempo un pirata informático podría acceder a los recursos de los usuarios, en caso de que lo consiguieran.
Longitudes de vencimiento
Aquí, depende de lo que esté asegurando con su sistema de autenticación en cuanto a la duración de la caducidad de su 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 Stackflow. La decisión sobre el vencimiento es un compromiso entre la facilidad del usuario y la seguridad. La longitud del token de actualización está relacionada con la longitud de retorno del usuario, es decir, establezca la actualización según 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 mediante una revocación explícita. Normalmente, un inicio de sesión no se revocaría.
Espero que la publicación bastante larga sea útil.
Además de las otras respuestas:
Una vez obtenidos, los tokens de acceso se envían normalmente junto con cada solicitud de los clientes a los servidores de recursos protegidos. Esto induce un riesgo de robo y reproducción de tokens de acceso (asumiendo, por supuesto, que los tokens de acceso son del tipo “Portador” (como se define en el RFC6750 inicial).
Ejemplos de esos riesgos, en la vida real:
-
Los servidores de recursos generalmente son servidores de aplicaciones distribuidos y, por lo general, tienen niveles de seguridad más bajos en comparación con los servidores de autorización (configuración SSL / TLS más baja, menos protección, etc.). Los servidores de autorización, por otro lado, generalmente se consideran una infraestructura de seguridad crítica y están sujetos a un endurecimiento más severo.
-
Los tokens de acceso pueden aparecer en seguimientos HTTP, registros, etc. que se recopilan legítimamente con fines de diagnóstico en los servidores de recursos o los clientes. Esos rastros se pueden intercambiar en lugares públicos o semipúblicos (rastreadores de errores, mesa de servicio, etc.).
-
Las aplicaciones backend RS se pueden subcontratar a terceros más o menos confiables.
El Token de actualización, por otro lado, generalmente se transmite solo dos veces sobre los cables, y siempre entre el cliente y el servidor de autorización: una vez cuando lo obtiene el cliente, y una vez cuando el cliente lo usa durante la actualización (“caducando” efectivamente el token de actualización anterior). Esto es un drásticamente oportunidad limitada de interceptación y repetición.
Último pensamiento, los tokens de actualización ofrecen muy poca protección, si es que hay alguna, contra los clientes comprometidos.
Más adelante puedes encontrar las críticas de otros desarrolladores, tú asimismo tienes la opción de mostrar el tuyo si lo deseas.