¿Deben caducar los tokens de acceso OAuth2 para una aplicación móvil?

Question

La respuesta aceptada aquí como a why OAuth2 access tokens expire:

• Muchos proveedores de apoyo fichas al portador que son muy débiles en cuanto a la seguridad. Al hacer que sean efímeros y que requieran actualización, limitan el tiempo que un atacante puede abusar de un token robado. () ¿Qué significa esto? Supongo que permite la transmisión sin TLS? ¿Algo más?).
• La implementación a gran escala no desea realizar una búsqueda de base de datos en cada llamada API, por lo que en su lugar se emite 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 durante un breve período de tiempo y deben actualizarse.
• El token de actualización requiere autenticación de cliente que lo hace más fuerte. A diferencia de los tokens de acceso anteriores, por lo general se implementa con una búsqueda en la base de datos.

Suponiendo que no admitimos la transmisión no encriptada del token de acceso, nos ocupamos del primer punto.

Suponiendo que estamos bien haciendo una búsqueda de base de datos en contra de un revookable, token de acceso completamente aleatorio se ocupa de la segunda.

Para las aplicaciones móviles, la autenticación del cliente no puede ser más fuerte, porque "client_id y client_secret obtenidos durante el registro están incrustados en el código fuente de su aplicación. En este contexto, el client_secret obviamente no se trata como un secreto". (Google). Eso elimina la tercera preocupación.

¿Cuál es la ventaja de separar los tokens de acceso de corta vida y los tokens de actualización de larga duración en este escenario? ¿Está "bien" emitir tokens de acceso sin vencimiento e ignorar toda la parte del token de actualización?

Answer 1

La diferencia entre un token de actualización y un token de acceso que no expira en términos de seguridad es una llamada adicional al servidor de autorización.

Si un atacante obtiene acceso a su token de acceso que no expira, puede llamar directamente a su servidor de recursos y obtener datos confidenciales como respuesta.
Ahora, si roba su token de actualización , primero tiene que llamar al servidor de autorización y recibir un token de acceso en respuesta. Luego puede consultar el servidor de recursos para obtener datos confidenciales.

Cada vez que se solicite un token de acceso desde el servidor de autorización con un token de actualización, la especificación OAuth 2 (al menos la última versión por ahora) requiere el servidor a check the client identity and if it is bound to the token, si es posible.

Como el enfoque normal con un secreto de cliente no funciona para identificar definitivamente una aplicación instalada en una plataforma abierta, la plataforma que ejecuta la aplicación debe proporcionar métodos para hacerlo. Google, por ej. requiere que las aplicaciones de Android sean firmadas por el desarrollador. Al solicitar credenciales para una aplicación de Android usando el Google API Console, por lo tanto, debe especificar the fingerprint of the certificate you used for signing the application y solo obtener un ID de cliente, pero no hay ningún secreto en respuesta. Al emitir tokens, Google puede decidir si la aplicación fue autorizada por el desarrollador para solicitar tokens a su nombre.

Si definitivamente no puede verificar la identidad del cliente, al menos es posible en algunos casos reconocer que se robó un token de actualización. La especificación tiene un example for this:

Cuando la autenticación del cliente no es posible, el servidor de autorización DEBERÍA implementar otros medios para detectar el abuso del token de actualización.

Por ejemplo, el servidor de autorizaciones podría emplear la rotación de token de actualización en la que se emite un nuevo token de actualización con cada respuesta de actualización de token de acceso. El token de actualización anterior es invalidado pero retenido por el servidor de autorizaciones. Si un token de actualización se ve comprometido y utilizado tanto por el atacante como por el cliente legítimo, uno de ellos presentará un token de actualización invalidado, que informará al servidor de autorización de la violación.

Answer 2

El problema más importante con un token de acceso que no expira es que no hay ningún mecanismo para reemplazar un token que se ha robado. Si obtengo acceso a su token de acceso que no expira, entonces soy efectivamente usted para ese sistema. Si el token tiene una vida corta y caduca, entonces hay un mecanismo para reemplazar el token robado y un límite en la ventana que tengo para romper tu token.

Supongamos que me lleva 3 horas crackear un paquete y obtener el token, pero el token de acceso solo es válido durante dos horas. Luego, cuando no puedo acceder a su cuenta, el token ha cambiado y tengo que comenzar de nuevo. Si el token no expira, entonces tengo acceso completo a su cuenta y no tiene forma de reemplazarlo, salvo eliminar el token y forzar una nueva autorización.

Answer 3

Los tokens de acceso OAuth2 no tienen que caducar (o más bien lo hacen, pero pueden pasar muchos años).

Un token de acceso se puede usar UNA VEZ para adquirir ciertos recursos del servidor de recursos, en particular, permite la adquisición de esos recursos aprobados por el usuario. Un token de actualización, por otro lado, permite un acceso repetido. Por lo tanto, no se pueden eliminar los tokens de actualización sin requerir la interacción del usuario entre cada acceso.

En general, a veces los tokens pueden ser robados por otras aplicaciones maliciosas en el mismo dispositivo o por ataques MITM en el teléfono. SSL es compatible con MITM si se puede hacer que el teléfono confíe en un certificado dudoso. Esto a veces es requerido por las compañías para acceder a las redes internas (requieren la aceptación de un certificado autofirmado, lo que les permite MITM todo el tráfico cifrado que ocurre en la red de la compañía.) Asumir el envío de los tokens cifrado significa que no pueden ser robados en el camino peligroso

Los tokens de portador no son más débiles que cualquier otra forma de token per se, como se demuestra en un montón de documentos (incluido uno mío, al que publicaré el enlace cuando lo pueda desenterrar). Sin embargo, los tokens de portador solo son apropiados en los casos en que los supuestos son válidos. La suposición de que el token puede mantenerse en secreto es una suposición principal de tokens de portador en general. Si esto no es cierto, los tokens de portador NO afirman NINGUNA propiedad de seguridad (aunque algunos aún se mantienen). Consulte NIST Level 3 tokens, que define qué ataques deben superar los tokens de portador, como s pecificado en OAuth Bearer Tokens. En resumen, los tokens de portador no deben derrotar el robo del token.

Los tokens de portador no se pueden revocar, es cierto. Sin embargo, dado que el patrón de acceso habitual es utilizar el token de acceso inmediatamente después de la adquisición, uno debe expirar los tokens de acceso con bastante rapidez para evitar posibles abusos, incluso si no se puede pensar en un caso de abuso actualmente. Mientras más tiempo tenga una ficha, más probabilidades habrá de que sea robada. De hecho, es mucho más peligroso robar un token de actualización, ya que proporciona acceso de repetición en un marco de tiempo más largo, si no puede proteger el ID del cliente. OAuth2 puede proporcionar acceso a los recursos en general y, por lo tanto, podría usarse para exponer las API a un cliente por un tiempo. Con un token de actualización se puede hacer mucho más daño, a diferencia de un token de uso único.

La autenticación del cliente de hecho puede hacerse más segura de varias maneras, por ejemplo, dando a cada cliente la descarga de una clave diferente. Esto evita ataques generalizados donde la ingeniería inversa de un token en un dispositivo rompe la seguridad para todas las instancias del cliente. Otras técnicas potenciales incluyen el uso de OAuth para verificar el cliente con su servidor, que luego realiza una segunda ejecución del protocolo OAuth con el servidor de autorización al que desea acceder. Esto le permite tener clientes que actualicen sus claves con regularidad, y para que todos ellos tengan claves diferentes, mientras que no colocan una carga excesiva en los sistemas utilizados por el servidor de Autorización propiedad de Facebook o Google, por ejemplo.

Al usar una aplicación móvil, los tokens de actualización de larga duración son más seguros que tener algún tipo de token de portador multiuso, incluso si no se toman medidas para proteger al cliente. Esto se debe a que el usuario no puede caducar el token. Si el token de actualización no es robado y el usuario simplemente desea revocar el acceso, puede hacerlo. Un token de portador de usos múltiples no puede revocarse incluso si el usuario simplemente desea revocar el acceso. Un token de referencia de base de datos de usos múltiples puede ser revocado obviamente, pero esto no es para lo que está diseñado el protocolo y, por lo tanto, los análisis de seguridad que se han realizado en OAuth no dicen nada sobre la seguridad de este sistema híbrido.

En conclusión, recomendaría utilizar tokens de actualización y tokens de base de datos, ya que es más probable que sea seguro. Si puede hacer algo para garantizar que el cliente sea una bonificación, las situaciones a las que protege son mínimas. Si desea asegurarse de que el cliente considere tokens suaves, a la google authenticator, ya que esta es una implementación sólida que ha resistido el análisis de algunas personas muy inteligentes.