¿Por qué caducan los tokens de acceso?


209

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.

Respuestas:


226

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.

44
Dos preguntas: 1) En el caso de las aplicaciones móviles, ¿el requisito de autenticación del cliente lo hace más fuerte? Debido a que client_secret es parte del código fuente de la aplicación, no es en absoluto secreto. Suponiendo que el token de acceso también se comparte solo a través de TLS (y su primer punto de viñeta no se aplica), ¿hay alguna seguridad adicional? 2) Suponiendo que todo esto se cumple en nuestro escenario (solo TLS, sin tokens irrevocables autocodificados), ¿está bien emitir tokens de acceso que no caduquen?
Thilo

44
¿Qué es un token de portador y qué tiene que ver con los tokens de actualización y acceso?
allyourcode

77
@Thilo Creo que la idea es que los tokens de acceso no necesitan ser revocables. Como señala Eran, esto hace posible que el servicio solicitado decida si atender una solicitud <em> sin tener que buscar el token de acceso en alguna base de datos </em>. AFAICT, ese es el beneficio real de separar los tokens de actualización y los tokens de acceso.
allyourcode

55
¿Cómo es un token de acceso (portador) de corta duración? Si hago una solicitud con un token de portador caducado, el token de actualización devolverá un token de portador nuevo. Del mismo modo, si robo el token de alguien de sus cookies y falsifico mi propia cookie con ese token, lo envío al servidor, se actualizará y me enviará uno nuevo. ¿Qué va a detener eso? No digas dirección IP o incluso MAC, porque eso no es razonable.
Suamere

3
@Suamere, eso ya se explicó. Los tokens de portador se validan mediante un proceso criptográfico que no toca la base de datos de autenticación, lo que los hace mucho más eficientes para el acceso frecuente a los recursos. Los tokens de actualización se validan en un proceso que implica verificar la base de datos para asegurarse de que sigue siendo válida. Ahora piense en cómo funciona gmail. Si alguien inicia sesión en su cuenta desde una ubicación geográfica inesperada, puede recibir una alerta. Puede ver todas las ubicaciones que pueden tener tokens de actualización válidos actualmente. Puede cerrar sesión en todas las ubicaciones, invalidando todos esos otros tokens de actualización.
Bon

33

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.

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


sobre ESCENARIO MÓVIL no importa si almacena la identificación del cliente en su servidor. por lo que cualquier otra aplicación sólo puede enviar la petición a su servidor y podría tener acceso a los usuarios los recursos del servidor throug la suya, por lo que su mismo
Amir Bar

Es cierto, pero solo tienen acceso a las instalaciones que proporciona, en lugar de tener acceso completo al token subyacente. Es decir, pueden hacerse pasar por su aplicación. A menudo, los tokens pueden tener permisos amplios, mientras que solo necesita un subconjunto. Mantener el token en el backend proporciona más restricciones, en caso de que lo necesite.
Ed Sykes

11

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.


De alguna manera, tocaste esto, pero enfatizaría que la superficie de ataque más grande para obtener (o inversamente divulgar) tokens está en registros de aplicaciones o servicios de recursos agregados de manera nefasta (no es un ataque MITM hoy). Casi en todas partes en un backend de API común tiene acceso al token de acceso utilizado (si tiene acceso al objeto HttpRequest, etc.). Solo DOS rutas de código en el sistema tienen acceso al token de actualización: el que lo genera en primer lugar y el que lo intercambia por un nuevo token de acceso. Esa es una diferencia significativa en la superficie de ataque.
Tom Dibble

9

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.


45
¿Pero el atacante tampoco tendría acceso al token de actualización? ¿y puede usar eso para crear un nuevo token de acceso?
levi

10
@levi, el pirata informático no puede usar el token de actualización para crear un nuevo token de acceso porque se necesita el ID del cliente y el secreto del cliente junto con el token de actualización para generar el nuevo token de acceso.
Spike

9
@Spike True, pero ¿la aplicación no tiene la identificación y el secreto del cliente incrustados también?
Andy

9
Entonces, ¿proporciona alguna protección contra el rastreo de paquetes, siempre y cuando la intercepción solo capture solicitudes de datos normales (Chuck solo obtiene el token de acceso)? Eso suena un poco débil; el sombrero negro solo tiene que esperar un poco hasta que el usuario solicite un nuevo token de acceso y luego obtendrá el ID del cliente, el secreto y el token de actualización.

3
Esto solo puede retrasarme aquí, pero si esto se envía a través de SSL, eso no se agrega a otra posible capa de seguridad. Supongo que supongo que todos saben lo que es SSL.
Damon Drake
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.