¿Es seguro usar el mismo token como token de actualización y token de acceso?

5

Según tengo entendido en OAuth, hay un token de actualización y hay un token de acceso. El token de acceso no se puede revocar, pero es de corta duración y, en la próxima actualización, no habrá token de acceso si se revoca. Tengo una aplicación sencilla en la que emito tokens y me consumo en una sola aplicación (tanto móvil como web, pero con la misma API), por lo que no necesito ningún OAuth complejo o OpenIdConnect para fiestas en 3D. Quiero usar este esquema con un solo token para simplificar, pero también quiero actualizarlo por razones de rendimiento (no para verificar la revocación de cada llamada):

  1. Un cliente proporciona un nombre de usuario y una contraseña para un punto final especial y recibe un JWT que está firmado pero no encriptado (eso es lo suficientemente bueno como lo entiendo, el usuario puede leer pero no falsificar). Utilizo JwtSecurityTokenHandler en .NET para emitir token por mi cuenta sin los servidores Oauth o OpenIdConenct para hacerlo. El token se firma utilizando RSA SHA 256 con el certificado que yo mismo creé. El token es de corta duración, por ejemplo. 1 hora.
  2. Todas las llamadas a la API están modificadas con la autenticación del Portador y leo el token en el servidor y verifico la firma y el vencimiento (nada más como Audience, etc.). El servidor confiará en este token y no comprobará la revocación.
  3. Si el servidor detecta que un token ha caducado, devolverá unos 40x para que el cliente sepa que debe actualizar el token. (El cliente puede realizar la verificación previa de la fecha de caducidad ya que el token no está cifrado para guardar algunas llamadas del servidor).
  4. Si el token ha caducado, el cliente llamará a refresh y le pasará el mismo token. La diferencia será que esta vez se verifica el estado de revocación (tengo una simple revocación de todos los tokens para la política del usuario, no por token). Revisaré la marca de tiempo adicional del problema inicial que no se cambia con las actualizaciones y verificaré que sea mayor que la marca de tiempo del usuario que se establece, por ejemplo. cuando un usuario cambia la contraseña. El resultado es otra ficha del mismo tipo con la misma marca de tiempo inicial y el mismo tiempo de caducidad de 1 hora más. Si se revoca, el usuario tendrá que volver a iniciar sesión.

Realmente necesito actualizar solo debido a consideraciones de rendimiento, pero me pregunto ¿quizás me esté faltando algo y realmente haya un problema de seguridad o quizás otros problemas con este flujo simplificado con un solo token?

    
pregunta Ilya Chernomordik 25.01.2016 - 10:50
fuente

1 respuesta

2

Si controla tanto el cliente como el servidor y puede asegurarse de que ambos tokens siempre se transmitan de forma segura, no hay inconveniente en usar el mismo token para ambos.

Normalmente, el token de actualización es el token crítico a proteger, ya que esto permite el acceso indefinido a la aplicación. También es más fácil controlar qué transportes se transmiten. Sin embargo, en su caso, si puede aplicar la misma seguridad al token de acceso, no hay ningún riesgo adicional en que sean iguales.

También vea esta respuesta .

    
respondido por el SilverlightFox 26.01.2016 - 10:07
fuente

Lea otras preguntas en las etiquetas