Jwt-auth: [pregunta] Caso de uso de API sin cabeza

Creado en 12 dic. 2019 · 3Comentarios · Fuente: WP-API/jwt-auth

La arquitectura del flujo de autenticación en este complemento es excelente; Entiendo las preocupaciones de seguridad. Aunque deshabilita quizás el caso de uso principal de dicha característica: Wordpress como un CMS sin cabeza.

Deshabilita la autenticación de CMS sin cabeza

Un CMS sin cabeza requeriría que los usuarios inicien sesión a través username y password . Una vez que el usuario tiene un JWT, puede enviar solicitudes autenticadas a recursos protegidos; en un entorno de CMS sin encabezado, sería prohibitivo y contradictorio pedir a los usuarios que generen tokens de API.

La seguridad debe implementarse a través de privilegios RBAC, funciones de usuario y responsabilidades que dicten lo que está protegido en la API. Las preocupaciones de seguridad podrían mitigarse a través de valores predeterminados muy estrictos de RBAC. Wordpress ya tiene un gran marco de funciones y responsabilidades.

Para abordar las preocupaciones de seguridad reales:

¿Fichas de larga duración? Conviértalos en fichas de corta duración.
¿Le preocupa que se puedan robar tokens de larga duración? También pueden hacerlo los tokens de API, argumento nulo.
Las mejores prácticas de JWT dictan tokens de corta duración tokens refresh_tokens duración (los tokens de actualización son revocables). Por lo tanto, esto es más seguro que entregar tokens API de vida infinita que se pueden perder.

¿No es esto solo OAuth2?

Este enfoque es esencialmente un escenario de concesión de token oAuth2 "personal access" . Por lo tanto, cuestionaría los méritos de un enfoque de servidor de autenticación de token personalizado como este sobre una implementación estándar oAuth2 adecuada. Si la seguridad es la principal preocupación aquí, ¿entonces este enfoque realmente presenta riesgos de seguridad? por ejemplo, una implementación probada en batalla de oAuth2 como php-league-oatuh-2

Veo el único caso de uso viable para el flujo de autenticación actual application-to-application ¿autenticación? oAuth2 presenta múltiples métodos de flujo de autenticación para otorgar tokens. Uno es lo que este enfoque usa "personal access" y otro es lo que estoy describiendo "password access" tokens. Una implementación completa de oAuth2 permitiría estos dos escenarios y más...

Más

Creemos que la adopción de WP-API y, por lo tanto, la modernización del ecosistema de Wordpress en general mejoraría enormemente si cosas como la autenticación de API sin estado fueran fácilmente accesibles para los desarrolladores.

¡Estas son solo reflexiones y me encantaría discutir y contribuir!

¡Buen trabajo!

equipo wp-sin cabeza

Fuente

andrewmclagan

👍3 🚀1 ❤1

Comentario más útil

He estado creando aplicaciones nativas (o intentándolo) desde antes de que la API REST llegara al núcleo. (es decir: años)

Inicialmente, la única forma en que mi aplicación autenticaba y cargaba o creaba contenido era usar el complemento 'OAuth1.0a' que inició el equipo de la API.

Ahora tengo cosas que funcionan para OAuth2.0 (nuevamente, otra característica que necesita un complemento adicional instalado. No tengo idea si esto alguna vez llegará al núcleo)

Y ahora tenemos JWT que presenta nuevos problemas sobre cómo conectar mi aplicación. Naturalmente, un nombre de usuario/contraseña funcionaría mejor, proporcionando un token. (Afortunadamente, esta versión 'WP-API' de JWT admite la actualización del token. Otro complemento JWT ampliamente utilizado no lo hace)

No puedo creer la gran cantidad de oportunidades perdidas (y tiempo) que están pasando, al no tener una implementación sólida 'sin cabeza'/móvil para la autenticación 'lista para usar' (en el núcleo).

Mi aplicación móvil requiere su propio complemento para hacer su trabajo y admitir una gran cantidad de cosas relacionadas con la administración y mejoras de ruta. bloques personalizados, etc. Prefiero no tener que hacer que los usuarios/clientes de mi aplicación tengan que descargar e instalar otro complemento 'no del todo terminado'.

Solo desearía que existiera una solución sólida (y 'oficial').

kosso en 17 dic. 2019

👍3

Todos 3 comentarios

He estado creando aplicaciones nativas (o intentándolo) desde antes de que la API REST llegara al núcleo. (es decir: años)

Inicialmente, la única forma en que mi aplicación autenticaba y cargaba o creaba contenido era usar el complemento 'OAuth1.0a' que inició el equipo de la API.

Ahora tengo cosas que funcionan para OAuth2.0 (nuevamente, otra característica que necesita un complemento adicional instalado. No tengo idea si esto alguna vez llegará al núcleo)

Solo desearía que existiera una solución sólida (y 'oficial').

kosso en 17 dic. 2019

👍3

Estoy totalmente de acuerdo. Wordpress está posicionado para convertirse en líder en el campo de cms sin cabeza. Parece que el equipo central hace avances en eso, pero ¿quizás solo para servir un caso de uso específico para wordpress.com? No estoy seguro.

Actualmente estamos desarrollando un cliente isomorfo para este propósito. Junto con ganchos de reacción y proveedores. https://github.com/wp-headless/fetch. Tal vez tengamos que escribir nuestro propio complemento de autenticación JWT. Mis pensamientos sobre cómo debería verse:

Siga las especificaciones de oAuth2 (¿por qué crear un flujo de autenticación personalizado?)
Tener múltiples métodos de concesión de tokens: password , machine-to-machine , api-key etc.
depender de los principales paquetes que están bien probados.

andrewmclagan en 18 dic. 2019

Aquí estoy atascado tratando de implementar un sistema de registro/autenticación de usuarios a través de la API REST de WP, solo para descubrir que el equipo de WP está ~~reinventando la rueda~~ inventando una nueva rueda.