Almacenamiento de acceso OAuth y actualización de tokens en cookies que no son de HttpOnly

1

Estoy utilizando el flujo de código de autenticación de OAuth para generar acceso y actualizar tokens, y luego las guardo en dos cookies del navegador que son no HttpOnly y las envío también al cliente.

Las cookies no deben ser HttpOnly porque el cliente debe saber si existe un token de acceso para saber si debe hablar con el servidor de autorización y realizar un flujo de token de actualización para obtener nuevos tokens.

¿Qué tan mala es esta seguridad? ¿Cuáles son los riesgos cuando el token de actualización / acceso es robado? ¿Cuáles son algunas formas de mitigar estos riesgos?

EDIT

Además, ¿cree que PKCE puede mejorar la seguridad del token de actualización de alguna manera? Por lo que entiendo, solo puede mejorar la seguridad del flujo de código de autenticación, pero después de obtener un token de actualización y acceso no es muy diferente, simplemente no necesita usar un secreto al intercambiar el token de actualización por un nuevo par de tokens. . Gracias

    
pregunta Michael 13.09.2018 - 13:41
fuente

2 respuestas

2

El principal elemento de riesgo es de XSS. Si hay algún XSS en tu aplicación, entonces puede usarse para robar de forma trivial tus tokens.

Tan pronto como se robe un token, el atacante puede hacerse pasar por el usuario.

Lo que no me queda claro es por qué necesita tener estas cookies disponibles fuera de HTML: ¿no puede usar otra cookie para almacenar el elemento público de la cookie (tal vez toda la carga útil o simplemente la caducidad y lo que necesite? para que su cliente averigüe si necesita ir al portal de autenticación) y mantener los tokens de JWT en cookies solo de HTTP?

    
respondido por el Stephane 13.09.2018 - 13:54
fuente
0

Me gustaría mucho pensar en tener un token de actualización disponible del lado del cliente sin protección. Para una aplicación del lado del servidor, normalmente se almacena dentro de una cookie HTTPS protegida (es decir, cifrada y firmada).

Para una aplicación del lado del cliente como la que describe en Open ID Connect, usaría el flujo implícito (sin token de actualización) y para renovar usaría una llamada silenciosa prompt=none al punto final autorizado para obtener un nuevo (breve vivido) token de acceso. Este escenario aún es vulnerable a XSS ya que el token de acceso se almacenará en un almacenamiento local o de sesión o similar, pero no habrá un token de actualización disponible.

¿Puede usar OIDC con su IDP?

    
respondido por el mackie 18.09.2018 - 10:36
fuente

Lea otras preguntas en las etiquetas