oauth - funciona - twitter api key

¿Por qué caducan los tokens de acceso? (4)

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 conlleva un riesgo de robo y reproducción de token 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 rastreos HTTP, registros, etc., que se recopilan legítimamente para fines de diagnóstico en los servidores de recursos o clientes. Esos rastreos se pueden intercambiar en lugares públicos o semipúblicos (rastreadores de errores, servicio de asistencia, etc.).
Las aplicaciones de 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 a través de los cables, y siempre entre el cliente y el servidor de autorización: una vez que el cliente la obtiene, y una vez que la usa el cliente durante la actualización (efectivamente "expira" la actualización anterior simbólico). Esta es una oportunidad drásticamente limitada para la intercepción y la reproducción.

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

Acabo de empezar 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 el token de acceso caduca, puedo enviar mi token de actualización a Google y me darán un token de acceso nuevo.

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 de larga duración en lugar del token de actualización?

Además, ¿expira 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.

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

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

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 hacer que sean de corta duración y requieran 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 en cada llamada a la API, por lo que, en su lugar, emiten un token de acceso autocodificado que puede verificarse mediante descifrado. Sin embargo, esto también significa que no hay forma de revocar estos tokens, por lo que se emiten por poco tiempo y se deben actualizar.
El token de actualización requiere la autenticación del cliente, lo que la hace más fuerte. A diferencia de los tokens de acceso anteriores, generalmente se implementa con una búsqueda de base de datos.

Un par de escenarios podrían ayudar a ilustrar el propósito del acceso y actualización de tokens y las concesiones 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 tienes un par de opciones:

si tiene su propia administración de sesión, almacene tanto access_token como refresh_token contra 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 requiere que usted acceda al recurso, use access_token y si access_token ha caducado, use refresh_token para obtener la nueva.

Imaginemos que alguien se las arregla para secuestrar tu sesión. Lo único que es posible es solicitar tus páginas.

Si no tiene administración de sesión, coloque access_token en una cookie y úselo como una 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 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 el servidor de su aplicación. Esto se haría en un canal seguro. Un pirata informático podría secuestrar la sesión, pero solo podrían interactuar con su aplicación web. En 2, el hacker 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 pirata informático se apodera de access_token, solo tendrán una pequeña ventana en la que podrán acceder a los recursos.

De cualquier manera, refresh_token y 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 establecer un tiempo de espera largo en el token de acceso:

En 1) No hay mucha diferencia entre un token de acceso corto y uno 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 movil

En el móvil, hay un par de escenarios que conozco:

Almacene clientid / secret en el dispositivo y haga que el dispositivo orqueste para obtener acceso a los recursos del usuario.
Use un servidor de aplicaciones back-end para guardar el ID de cliente / secreto y haga que haga la orquestación. Utilice access_token como un tipo de clave de sesión y pásela entre el cliente y el servidor de aplicaciones.

Comparando 1 y 2

En 1) Una vez que tiene un ID de cliente / secreto en el dispositivo, ya no son secretos. Cualquiera puede descompilar y luego comenzar a actuar como si fueras tú, 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 proporcione sus credenciales. En este escenario, la longitud de access_token no hace ninguna diferencia en cuanto a la capacidad de pirateo, ya que refresh_token está en el mismo lugar que access_token. En 2) el ID de cliente / secreto ni el token de actualización están comprometidos. En este caso, la duración de la caducidad de access_token determina durante cuánto tiempo un hacker podría acceder a los recursos de los usuarios, en caso de que lo obtengan.

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 access_token. Si es algo particularmente valioso para el usuario, debería ser corto. 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 la caducidad es una compensación entre la facilidad y la seguridad del usuario. La duración del token de actualización está relacionada con la longitud de devolución 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 en que se revocan es con una revocación explícita. Normalmente, un inicio de sesión no se revocaría.

Espero que el post bastante largo sea útil.