Usando JTWs en la implementación de OAuth

Question

Usando JTWs en la implementación de OAuth

#1 de Pascal (2 votos)
#2 de CipherX (0 votos)

2

Actualmente estoy creando una api para que una aplicación se comunique. Los puntos finales de API estarán protegidos, por lo que me gustaría usar un flujo de OAuth con JWT para la seguridad. Mi flujo será algo como esto:

Recibir y validar las credenciales de usuario
Emita un token de acceso (JWT) y actualícelo para obtener credenciales válidas
Verifique la integridad del token de acceso y luego verifique la caducidad
- Si está vencido: envíe un 401 y espere recibir un token de actualización que luego se validará y se emitirá un nuevo token de acceso
- De lo contrario, utilice la reclamación de ID de usuario para recopilar más contexto y continuar con la solicitud \

Mis preguntas:

Integridad de JWT: Un JWT compacto consta de tres partes: encabezado, carga útil y firma. La firma se verifica aplicando el alg especificado en la sección del encabezado al encabezado codificado en base64url y las secciones de la carga útil separadas por un '.' y luego base64url codificando el valor producido. ¿Significa esto que es posible crear un token de acceso falso? Un token de acceso robado podría estar sin codificar, la identificación del usuario fue robada e insertada en un token de acceso muy similar, pero falso. Este token falso se firma como un JWT normal. Cuando el servidor reciba este token de acceso, ¿este token no mantendrá su integridad?
Flujo de OAuth: ¿Parece que este es un flujo adecuado? Los tokens de actualización de un usuario se almacenarán en una base de datos para que puedan verificarse en el futuro (tendrán una larga vida útil ). El token de acceso se basará en su propia integridad y en la información que contiene, ya que su vida útil es muy breve.

authentication oauth api jwt

pregunta Gavin 23.11.2016 - 01:20

fuente

2 respuestas

0

Integridad JWT : si usa una clave simétrica para firmar su token y esta clave es robada, la respuesta a su primera pregunta es: SÍ. Pero si usa criptografía asimétrica, puede firmar el token con su clave privada (almacenar esta clave privada en un lugar seguro) y enviar el token al usuario (use TLS entre el cliente y el servidor). La firma se aplica a todo el token, por lo que si un usuario malintencionado recibe el token, no puede manipularlo porque no conoce la clave privada utilizada para renunciar al token completo.

Flujo de OAuth : Sí.

respondido por el CipherX 23.11.2016 - 10:55

fuente

Lea otras preguntas en las etiquetas authentication oauth api jwt

WPS PBC Security ¿Hay un RCE PoC para el CVE-2012-0002 / MS12-020?

score 2 · Accepted Answer

¿Parece que esto es un flujo adecuado?

No veo nada malo en ello. Sin embargo, tenga cuidado con la palabra 'flujo', tiene un significado específico cuando se habla de OAuth, y se debe tener en cuenta que se usa de acuerdo con lo que significa "flujo de OAuth".

¿Esto significa que es posible crear un token de acceso falso?

Para firmar un JWT, necesitas saber un secreto. JWT admite firmas a través de HMAC (que requiere un secreto simple y precompartido) o con criptografía de clave pública [1]. Todos los proveedores con los que he trabajado, especialmente Google y Microsoft, utilizan la criptografía de clave pública (RSA) para crear la firma digital.

Entonces, el ataque que usted describe depende de que el atacante tenga acceso a la clave privada de la institución que firmó el JWT. El acceso a la clave pública no es suficiente; puede usar esto para verificar si la firma es válida, pero no puede usar la clave pública para volver a firmar un token modificado.

Si el JWT en cuestión utilizó hmac simple en lugar de la criptografía de clave pública para crear la firma, entonces tanto el firmante como la parte que necesitaba el secreto para verificar la firma podrían firmar correctamente un JWT modificado. Pero en ese caso, si el token de acceso fue robado, el ladrón aún no tendría el secreto. Solo veo un posible peligro cuando la persona a la que está destinado el token de acceso lo cambia voluntariamente y lo renuncia al uso del secreto compartido. No estoy seguro de cuáles serían las implicaciones de seguridad de tal ataque, pero supongo que es por eso que los grandes proveedores de OAuth utilizan la criptografía de clave pública.

[1] enlace