¿Qué debo usar para la autenticación de mi API de Django Rest?

4

Acabo de leer este artículo sobre por qué JWT está chupando. Ahora no estoy seguro de qué debo usar para la autenticación.

Para contexto: la API que escribí se usa principalmente en aplicaciones móviles (iOS y Android). En el futuro también se accederá a través de una interfaz React.

En el pasado, solo usé la compilación de DRF en la autenticación Token. El teléfono simplemente almacenaría este token en el almacenamiento de la aplicación correspondiente.

Hace poco me dijeron que esto no es seguro y que debería usar JWT. Mientras investigaba JWT, encontré el artículo anterior, que explica por qué la autenticación de sesión básica y la succión de JWT es mejor. Pero hasta donde sé, cuando se utiliza como API no puedo usar la autenticación de sesión con DRF, ¿verdad?

Entonces mi pregunta es? ¿Qué herramientas de DRF debo usar para la autenticación, para que sea seguro?

    
pregunta J. Hesters 29.04.2018 - 17:16
fuente

2 respuestas

3

Soy el autor de ese artículo, así como la charla sobre tecnología más popular que ofrezco acerca de por qué los JWTs apestan y son estúpidos (todos los cuales @ joepie91 ha escrito con elocuencia de manera mucho mejor de lo que podría: enlace ).

Teniendo en cuenta los requisitos de su aplicación (aplicación móvil + aplicación única de front-end JS que ambos hablan con una API de back-end), le sugiero que use el flujo de Código de Autorización de OpenID Connect (con PKCE para su aplicación móvil).

Para su aplicación móvil, específicamente, recomiendo usar la fabulosa biblioteca AppAuth: enlace (tiene bibliotecas geniales para iOS + Android ).

Ahora, quizás se esté preguntando por qué recomendaría usar OpenID Connect (y, por lo tanto, JWTs) para algo cuando yo tan públicamente reúno a las personas en contra de usar JWTs: le diré, para la mayoría de las cosas no importa. .

Aquí está la cosa: sí, los JWT son bastante difíciles de usar cuando se crean aplicaciones seguras. Son complicados, la mayoría de las bibliotecas actualmente no están completas, y es casi seguro que el uso de funciones más avanzadas como el cifrado JWT le causará grandes dolores de cabeza y problemas de compatibilidad entre sus servicios.

Además, la razón principal por la que los JWT se han hecho populares para la autenticación es que se utilizan con frecuencia para autenticar CACHE y los datos de autorización, toda esta práctica es un gran NO NO en el mundo de la seguridad.

El almacenamiento en caché de datos confidenciales (como datos de autenticación y autorización) es lo peor que puede hacer por seguridad: está confiando en información obsoleta. TODOS los sistemas de autenticación actuales construidos sobre JWTs sufren esta ingenuidad.

Una vez que haya pasado por el agujero de los conejos al tratar de "acelerar" su sitio / API mediante el uso de JWT, ya cometió un pecado de seguridad y ahora está en riesgo.

Además, una vez que las personas comienzan a usar JWT y se dan cuenta de que están en riesgo, intentan volver a centralizar todo (como ha sugerido otro comentarista) y comienzan a usar las listas de revocación para poder revocar tokens cuando suceden cosas malas. Esto da como resultado las mismas penalizaciones de velocidad que la administración de sesión tradicional, pero con mayores penalizaciones de velocidad debido a que los JWT son más "pesados" que las cookies de sesión, y más frágiles.

Lo siento por la perorata, pero aquí está mi consejo:

  • Si desea seguridad real , debe usar sesiones del lado del servidor. En su caso, esto implicaría el uso de cookies de sesión de soporte desde su backend API, de modo que cuando su aplicación reaccione se autentique en su API, la API establece una cookie segura que la aplicación reacciona utiliza automáticamente cada vez que responde al servicio API para autenticarse. También deberías usar una API basada en cookies desde tu aplicación móvil (no estoy familiarizado con la creación de aplicaciones móviles nativas, por lo que no puedo comentar sobre este componente).
  • Si desea simplicidad y la misma cantidad de seguridad que en casi todas las demás aplicaciones web principales, utilice OIDC y salga con las soluciones de código abierto listas para usar. Esta es la forma más sencilla de hacerlo actualmente y, si bien no es perfecta, si resuelve su problema, probablemente no sea un gran problema.

Si está creando algo sensible, intente usar cookies de sesión del lado del servidor cuando sea posible. ¿De otra manera? No se preocupe por los detalles y siga la corriente.

    
respondido por el rdegges 30.04.2018 - 23:32
fuente
1

Tienes dos buenas opciones IMO:

  1. Use una cadena aleatoria, que corresponderá con una sesión almacenada en la base de datos. Esta es la mejor opción si es posible. Aunque estas sesiones no deben ser a largo plazo. Use una nueva autenticación usando el token JWT si necesita un inicio de sesión a largo plazo.
  2. Use un JWT firmado con clave simétrica (HMAC). Esto es más rápido mientras está seguro. Sin embargo, esta opción aún es mucho más exigente en ancho de banda y generalmente es más lenta que una cadena aleatoria.
respondido por el Peter Harmann 29.04.2018 - 21:37
fuente

Lea otras preguntas en las etiquetas