Estoy empezando a trabajar con Google API y OAuth2. Cuando el cliente autoriza mi aplicación, recibo un "token de actualización" y un "token de acceso" de corta duración. Ahora, cada vez que caduque el token de acceso, puedo PUBLICAR mi token de actualización en Google y me darán un nuevo token de acceso.

Mi pregunta es ¿cuál es el propósito de la expiración del token de acceso? ¿Por qué no puede haber un token de acceso duradero en lugar del token de actualización?

Además, ¿caduca el token de actualización?

Consulte Uso de OAuth 2.0 para acceder a las API de Google para obtener más información sobre el flujo de trabajo de Google OAuth2.

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 token de portador que son muy débiles en cuanto a seguridad. Al hacerlos de corta duración y que requieren actualización, limitan el tiempo que un atacante puede abusar de una ficha robada.
• La implementación a gran escala no desea realizar una búsqueda en la base de datos en cada llamada a la API, por lo que, en su lugar, 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 corto tiempo y deben actualizarse.
• El token de actualización requiere autenticación del 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 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:

1. 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.

2. 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:

1. Almacene clientid / secret en el dispositivo y ordene el dispositivo para obtener acceso a los recursos del usuario.

2. 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.

Además de las otras respuestas:

Una vez obtenidos, los tokens de acceso generalmente se envían junto con cada solicitud de los clientes a servidores de recursos protegidos. Esto induce un riesgo de robo y reproducción de tokens de acceso (suponiendo, por supuesto, que los tokens de acceso sean 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 endurecimiento, etc.). Los servidores de autorización, por otro lado, generalmente se consideran infraestructura de seguridad crítica y están sujetos a un endurecimiento más severo.

• Los tokens de acceso pueden aparecer en rastreos HTTP, registros, etc., que se recopilan legítimamente con fines de diagnóstico en los servidores o clientes de recursos. Esos rastros se pueden intercambiar en lugares públicos o semipúblicos (rastreadores de errores, servicio técnico, etc.).

• Las aplicaciones de backend RS pueden subcontratarse a terceros más o menos confiables.

El token de actualización, por otro lado, generalmente se transmite solo dos veces a través de los cables, y siempre entre el cliente y el servidor de autorización: una vez cuando el cliente lo obtiene, y una vez cuando el cliente lo usa durante la actualización (efectivamente "caduca" la actualización anterior simbólico). Esto es drásticamente oportunidad limitada para la intercepción y la repetición.

Último pensamiento, los tokens de actualización ofrecen muy poca protección, si la hay, contra clientes comprometidos.

Es esencialmente una medida de seguridad. Si su aplicación se ve comprometida, el atacante solo tendrá acceso al token de acceso de corta duración y no habrá forma de generar uno nuevo.

Los tokens de actualización también caducan, pero se supone que viven mucho más que el token de acceso.