Jwt-auth: Token Flow UX actualizado

Gracias por tomarse el tiempo para escribir todo esto. Si siente que algo de lo que sigue es duro, no tiene la intención de serlo, solo le estoy dando mi opinión y no es la única, es probable que haya una mezcla de ellos y el debate esté bien.

Me preocupa que este cambio haga que la funcionalidad de este complemento sea inaccesible para la mayoría de los usuarios no técnicos, que esperan poder iniciar sesión con su nombre de usuario y contraseña.

Entiendo lo que está tratando de decir aquí, pero al mismo tiempo lo que está sugiriendo es que requerir que un usuario inicie sesión en WordPress y cree un par de claves es de alguna manera difícil para los usuarios no técnicos que desean generar un token. a través de la API REST mediante programación. Yo diría que estos no son usuarios _ no técnicos_ en absoluto.

Además, en todo sistema seguro habrá barreras de entrada que el usuario deberá superar para utilizarlo. Google no le permite crear una conexión JWT u OAuth mediante el uso de su nombre de usuario y contraseña en la solicitud de API. Eso no es seguro. Tiene que haber una forma de garantizar que un token o conexión de autenticación se adjunte a un usuario de una manera que pueda invalidarse.

No es intuitivo
Cualquier otro sistema que desee utilizar este método para integrarse con WordPress deberá tener una explicación / tutorial de cómo configurar un par de claves para comenzar.

Para tener un modelo seguro que admita la separación del acceso y la autenticación, debe tener medidas de seguridad que impidan que los tokens de larga duración se conviertan en un punto de acceso infinito. Con la adición de tokens de actualización, un usuario malintencionado podría crear un token de acceso y actualización con una combinación user:pass que nunca podríamos invalidar si no hubiera un par de claves, o algún equivalente, para invalidar los tokens.

Decirle al usuario que inicie sesión en WordPress y vaya a su perfil para generar un par de claves es un pequeño precio a pagar por la seguridad. Además, las instrucciones son muy sencillas.

Es difícil de usar entre dispositivos
Si espero usar esta tecla para una aplicación en mi teléfono, no hay una manera fácil de hacerlo. No quiero escribir una cadena larga de letras, números y caracteres especiales en mi teléfono; es probable que cometa un error de transcripción. Podemos eliminar el nivel de dificultad de transcripción generando un código QR que la gente pueda escanear, pero luego volvemos al problema anterior: es posible que la gente necesite descargar una aplicación de código QR, o los desarrolladores de terceros tendrían que crear un código QR analizar la biblioteca en su aplicación para trabajar con nosotros.

Describe esta aplicación a la que sigues haciendo referencia, ¿por qué manejaría toda la autenticación y el inicio de sesión por ti? Eso no es seguro. Le estaría dando a esta aplicación todo el acceso y la autenticación que necesita para hacer lo que quiera en su sitio web. Debe considerar que tal vez la arquitectura de las aplicaciones sea incorrecta y este flujo de autenticación es para evitar exactamente lo que está describiendo.

Lo que me ha descrito es una aplicación que almacena su nombre de usuario y contraseña en texto plano para que pueda iniciar sesión en WordPress a través de la API REST para generar un token que se usa para acceder a los recursos, pero que también es totalmente capaz de descargar su base de datos a través de la misma. medios de autenticación y acceso. No veo por qué querríamos admitir algo remotamente parecido a este caso de uso como lo ha descrito.

No fomenta una buena higiene de seguridad.
Idealmente, los usuarios mantendrían cuidadosamente sus claves para asegurarse de que ninguna esté desactualizada, sin compromisos, etc. Desafortunadamente, no podemos contar con esto, y las claves comprometidas son incluso más peligrosas que los tokens comprometidos. También es probable que un usuario medio cree una nueva clave cada vez que la necesite, en lugar de almacenar el secreto en un lugar seguro.

Primero, los pares de claves no están vinculados a una fecha de vencimiento y lo único que pueden hacer en este momento es crear tokens, por lo que no veo cómo son _más peligrosos_ que un token comprometido, ya que son lo que invalida ese token. En segundo lugar, los usuarios no hacen nada con cuidado y nunca debemos esperar que comprendan las implicaciones de seguridad de sus acciones. Tenemos que asumir que son extremadamente incompetentes y probablemente lo suficientemente perezosos como para nunca limpiar lo que ensucian. Sin embargo, la creación de pares de claves adicionales no es un problema de seguridad. El problema de seguridad sería dar su nombre de usuario y contraseña en texto plano a una aplicación extranjera.

Además, me preocupa agregar un método adicional para revocar sesiones. WordPress ya tiene un botón "Cerrar sesión en cualquier otro lugar" en la página de perfil. Como usuario, espero que también me desconecte de cualquier aplicación ( o al menos preguntarme si me gustaría hacer eso?)

Podemos pedirle al usuario que elimine sus pares de claves, pero nunca esperaría que un cierre de sesión destruyera mi token. Ese no es el comportamiento normal o esperado de un sistema como este y probablemente crearía caos y toneladas de solicitudes de soporte.

No proporciona ninguna seguridad adicional.
Si yo, como atacante, ya tengo su nombre de usuario y contraseña, no hay nada que no pueda hacer como usted (suponiendo que no haya 2FA en su lugar).

No estoy de acuerdo categóricamente. Este enfoque proporciona seguridad adicional para acceder a sus recursos REST y, si eso no es obvio, entonces necesitamos más documentación para hacerlo obvio. Está argumentando que si alguien ya tiene sus credenciales, entonces está jodido, pero también está sugiriendo que las usemos para dar acceso a la API REST. Si así es como desea acceder a REST, use la autenticación básica. Porque eso es exactamente lo que estaríamos implementando si usamos user:pass para crear tokens.

Esto lleva al hecho de que, si yo, como desarrollador de aplicaciones novato, quiero facilitar la vida de mi usuario, podría intentar algo desaconsejable, como usar un navegador sin cabeza para iniciar sesión en la cuenta del usuario, crear un token, leer los detalles y luego volver a colocarlos en mi aplicación.

Aquí es donde querríamos crear un flujo de autenticación que permita darle a una aplicación el par de claves mediante el uso de una devolución de llamada. Creo que algo como esto ya se ha implementado en el complemento de contraseñas de la aplicación.

Estoy 100% abierto a crear un flujo de autenticación para aplicaciones que cuando accedes a él se te pide que inicies sesión en WordPress, con cualquier extra como 2factor agregado, que generaría un par de claves para ti y luego usaría algún tipo de devolución de llamada. dale a la aplicación el par de claves. Entonces, los desarrolladores de aplicaciones no tienen que crear toneladas de malas soluciones y la aplicación no almacena su user:pass .

¿Qué se podría hacer en su lugar?
Actualmente, la clave tiene un propósito importante: se usa para permitir la revocación de un token, a pesar de que los tokens pueden tener una vida útil muy larga. Sin embargo, no necesitamos necesariamente un par de claves para hacer esto.

Correcto, podrías usar muchos enfoques diferentes.

Inspirándose en la entrada session_tokens de WordPress en usermeta, un conjunto almacenado de claves de revocación específicas de JWT permitiría la misma funcionalidad, y sería trivial implementar la funcionalidad "Cerrar sesión en cualquier otro lugar", simplemente elimine esa entrada de la tabla.

Esto nunca reemplazaría la implementación actual a la que tendría que ser adicional. Como desarrollador de software empresarial, nunca usaría este método. Entonces, aunque es un enfoque válido, carece de la capacidad de esperar que un token sea válido mientras no esté vencido o el token no se revoque. En su escenario, en el momento en que cierre la sesión, el token no es válido. En mi opinión, esto sería una deficiencia en el flujo de autenticación que causaría innumerables problemas con la capacidad de mis aplicaciones para obtener acceso a los recursos, ya que ahora está estrechamente relacionado con el usuario que inicia sesión.

¿Qué pasa con 2FA?
Me pregunto si sería posible permitir un enlace que los complementos 2FA podrían usar para decirle al cliente "por favor, inténtelo de nuevo, proporcionando un token 2FA" si se requiere uno, pero no se proporciona. Además, ¿podría usarse otro gancho (¿o quizás el mismo?) Para permitir que el complemento 2FA verifique que el código proporcionado es correcto. El sistema JWT no haría suposiciones sobre cómo se implementa 2FA, eso se dejaría a otro complemento, solo proporcionaríamos los ganchos para hacer posible tal cosa.

En mi opinión, esto agregaría una capa innecesaria de complejidad que tiene el potencial de crear muchas solicitudes de soporte.

Gracias por leer hasta aquí, todo lo anterior es en mi humilde opinión, pero espero que podamos simplificar un poco este proceso para que los usuarios funcionen realmente bien para todos.

Estoy seguro de que me he perdido al menos algo, ¡así que estoy feliz de escuchar cualquier comentario que la gente pueda tener sobre esto!

Publicación épica. Gracias por tomarse el tiempo de escribir todo esto. Realmente pensaste mucho en esto. Quiero decir que no estoy tratando de derribar nada. Solo que si vamos a permitir que se creen tokens con una combinación de user:pass entonces la forma en que lo hagamos debe ser muy segura y tener cero posibilidades de que las aplicaciones almacenen sus credenciales de inicio de sesión.

El punto de separar el acceso y la autenticación tiene un propósito y no debe tomarse a la ligera. Estamos construyendo la posible autenticación REST para 1/3 de Internet. Entonces, hasta que tengamos un camino a seguir, eliminé la capacidad de crear tokens con credenciales de usuario. Eso no significa que no podamos volver a agregarlo, solo que necesita mucha discusión antes de hacerlo.

¡Hola! Por lo que tengo entendido, el principal problema de la conversación aquí es la usabilidad. De hecho, hacer que los usuarios accedan al sitio para iniciar sesión y crear los pares de claves será una fuente de problemas o inconvenientes para algunos usuarios.

Es probable que los desarrolladores intenten encontrar formas no seguras de evitarlo de la misma manera que hoy eliminan la funcionalidad que requiere contraseñas seguras por el bien de sus usuarios.

Aunque entiendo el aspecto de seguridad en la decisión y estoy de acuerdo con él. Pero tenemos que encontrar una forma que funcione para ambos.

Parece que lo que dijiste aquí @valendesigns podría ser una posible solución:

Estoy 100% abierto a crear un flujo de autenticación para aplicaciones que cuando accedes a él se te pide que inicies sesión en WordPress, con cualquier extra como 2factor agregado, que generaría un par de claves para ti y luego usaría algún tipo de devolución de llamada. dale a la aplicación el par de claves. Entonces, los desarrolladores de aplicaciones no tienen que crear toneladas de malas soluciones y la aplicación no almacena su usuario: pase.

Por lo que tengo entendido, básicamente mantendríamos el flujo actual, que es más seguro ya que no necesitamos dar nuestra contraseña a la aplicación en lugar de dar solo el par de claves para generar el token, pero eso podría ser un obstáculo para algunos. .

Manteniendo este otro flujo en el que no tendríamos que dar nuestra contraseña a la aplicación externa. En su lugar, pedirles que inicien sesión en WordPress y generen el par de claves.

Me gustaría obtener más información sobre esta parte:

Podemos pedirle al usuario que elimine sus pares de claves, pero nunca esperaría que un cierre de sesión destruyera mi token. Ese no es el comportamiento normal o esperado de un sistema como este y probablemente crearía caos y toneladas de solicitudes de soporte.

Aparece si estoy conectado a site.com a través del navegador y la aplicación, si hago clic en "Cerrar sesión en cualquier otro lugar" en el navegador, también cerraré la sesión en la aplicación, ¿no? Puedo ver aplicaciones donde esta sería la suposición. La expectativa de que se desconectara en todas partes.

Lo mismo debería suceder cuando se elimina una cuenta.

Tengo que estar de acuerdo con lo que se dijo acerca de que el par de claves UX es muy poco amigable para el usuario.

Hace que sea muy difícil crear una aplicación móvil nativa que pueda utilizar este método de autenticación.

• Hice un complemento personalizado hace un tiempo para el complemento (antiguo) OAuth1a que mostraba un código QR cifrado (con una contraseña corta y configurable) en la página de administración de Aplicaciones (cuando el nombre de la aplicación y la URL de devolución de llamada coincidían con mi aplicación), que luego pasó la información de la aplicación cliente a la aplicación móvil, para luego permitir que el usuario se autentique.

Concedido (juego de palabras), JWT es mucho más fácil que OAuth1a;)

Dado que un usuario tiene que iniciar sesión en Wordpress (con suerte a través de https) en primer lugar, usando un nombre de usuario y contraseña, realmente no veo cuál es el problema de seguridad de que el par de nombre de usuario / contraseña pueda obtener un token de acceso ? ¿Todo se envía por el mismo "cable" al final del día? ¿Seguramente?

Hacer cumplir el par de claves de la aplicación actualmente implementado hace que este método de autenticación sea absolutamente imposible (en el mundo real) para su uso en aplicaciones móviles.

Simplemente no hay una forma sensata de obtener una aplicación móvil para ingresarlos.

Probé OAuth1a, OAuth2 y ahora dos complementos JWT para implementar mis aplicaciones nativas con acceso y todas fallan 'listas para usar', sin tener que piratear para intentar que las cosas funcionen para un usuario. Se supone que esto es más fácil, ¿no?

El complemento JWT de terceros que existe (con más de 10,000 instalaciones) admite usuario / pase y funciona bien para una aplicación móvil nativa que he estado construyendo. Pero falla por la falta de tokens de actualización a través del complemento, lo que obliga al usuario a 'iniciar sesión' nuevamente. (también requiere la edición manual de wp-config)

Este complemento 'pronto a ser oficial' (¡espero!) Falla debido a la falta de facilidad de uso para el usuario móvil y aparentemente ignora qué tipo de aplicaciones se pueden desarrollar de manera realista para él. Y eso parece muy miope.

Hay una razón por la que faltan aplicaciones móviles nativas para publicar en los sitios de wp.org. Y es esto.

Por favor, por favor, ¿podemos movernos un poco sobre esto? (He estado trabajando en una aplicación nativa durante años, esperando una forma 'adecuada' de autenticar a los usuarios, desde la introducción de la API REST)

:)

La UX del flujo de tokens es una locura y poco práctica para el uso en el mundo real, los usuarios deberían poder iniciar sesión con un nombre de usuario y contraseña en el sistema, pedir un par de claves API no tiene ningún sentido, no está empleando abstracción aquí, se supone para proteger a los usuarios de los aspectos técnicos del uso de su aplicación, ¿cómo sentirá que para iniciar sesión en Facebook en su teléfono necesita iniciar sesión en un portal de administración en Facebook y crear un par de claves API y luego usar el par de claves API? para iniciar sesión, no estamos desarrollando para desarrolladores, estamos desarrollando para el cliente que no sabe en qué consiste el aspecto técnico de su servicio, desinstalando de inmediato. Realmente no veo cómo este complemento es útil para la autenticación.

Este problema con el inicio de sesión de usuario> flujo de token está retrasando seriamente el desarrollo de TANTAS aplicaciones que podrían estar usando JWT.

Los meses y los meses siguen pasando y simplemente no se está abordando.

Como dije anteriormente, el hecho de que los usuarios usen un par de nombre de usuario / contraseña para iniciar sesión en el administrador hace que cualquier argumento para no usar pares de nombre de usuario / contraseña para obtener un token parezca algo inválido. ¿Seguramente?

Solo para actualizar este hilo, parece que este proyecto está siendo reemplazado por uno para implementar un flujo OAuth completo en el núcleo de WP. Debería abordar las desventajas de los enfoques discutidos aquí mientras conserva todas las fortalezas.

Si desea involucrarse con eso, no dude en saltar a # core-restapi en Slack .