Jwt-auth: Token Flow UX atualizado

Obrigado por escrever tudo isso. Se você acha que alguma coisa que se segue é dura, não é essa a intenção, estou apenas dando minha opinião e não é a única, provavelmente há uma mistura delas e o debate é bom.

Estou preocupado que essa mudança torne a funcionalidade deste plug-in inacessível para a maioria dos usuários não técnicos, que esperam poder fazer login usando seu nome de usuário e senha.

Eu entendo o que você está tentando dizer aqui, mas ao mesmo tempo o que você está sugerindo é que exigir que um usuário faça login no WordPress e crie um par de chaves é de alguma forma difícil para usuários não técnicos que desejam gerar um token por meio da API REST programaticamente. Eu diria que esses não são usuários _não técnicos_.

Da mesma forma, em todo sistema seguro haverá barreiras de entrada que o usuário deve superar para usá-lo. O Google não permite que você crie uma conexão JWT ou OAuth usando seu nome de usuário e senha na solicitação de API. Isso não é seguro. Deve haver uma maneira de garantir que um token ou conexão de autenticação seja anexada a um usuário de uma forma que possa ser invalidada.

Não é intuitivo
Qualquer outro sistema que queira usar este método para integração com o WordPress precisará ter uma explicação / tutorial de como configurar um par de chaves para começar.

Para ter um modelo seguro que ofereça suporte à separação de acesso e autenticação, você precisa ter grades de proteção que evitem que tokens de longa duração se tornem um ponto de acesso infinito. Com a adição de tokens de atualização, um usuário mal-intencionado pode criar um token de acesso e atualização com uma combinação user:pass que nunca poderíamos invalidar se não houvesse um par de chaves, ou algum equivalente, contra o qual invalidar os tokens.

Dizer ao usuário para fazer login no WordPress e ir ao seu Perfil para gerar um par de chaves é um pequeno preço a pagar pela segurança. Além disso, as instruções são muito simples.

É difícil usar entre dispositivos
Se pretendo usar essa chave para um aplicativo no meu telefone, não há maneira fácil de fazer isso. Não quero digitar uma longa sequência de letras, números e caracteres especiais no meu telefone - provavelmente cometerei um erro de transcrição. Podemos remover o nível de dificuldade da transcrição gerando um código QR que as pessoas podem ler, mas então voltamos ao problema acima - as pessoas podem precisar baixar um aplicativo de código QR ou desenvolvedores de terceiros precisariam criar um código QR analisar a biblioteca em seu aplicativo para trabalhar conosco.

Descreva este aplicativo ao qual você sempre se refere, por que ele lidaria com toda a autenticação e login para você? Isso não é seguro. Você forneceria a este aplicativo todo o acesso e autenticação de que ele precisa para fazer o que quiser com o seu site. Você deve considerar que talvez a arquitetura dos aplicativos esteja incorreta e esse fluxo de autenticação seja para evitar exatamente o que você está descrevendo.

O que você descreveu para mim é um aplicativo que armazena seu nome de usuário e senha em texto simples para que possa fazer login no WordPress por meio da API REST para gerar um token que é usado para acessar recursos, mas também é totalmente capaz de despejar seu banco de dados por meio do mesmo meios de autenticação e acesso. Não vejo por que gostaríamos de oferecer suporte a algo remotamente próximo a este caso de uso, conforme você o descreveu.

Não incentiva uma boa higiene de segurança
O ideal é que os usuários mantenham suas chaves com cuidado para garantir que nenhuma esteja desatualizada, descomprometida etc. Infelizmente, não podemos contar com isso, e as chaves comprometidas são ainda mais perigosas do que os tokens comprometidos. Também é provável que um usuário comum crie uma nova chave cada vez que precisar, em vez de armazenar o segredo em um lugar seguro.

Em primeiro lugar, os pares de chaves não são anexados a uma data de expiração e a única coisa que eles podem fazer agora é criar tokens, então não consigo ver como eles são _mais perigosos_ do que um token comprometido, pois são o que invalida esse token. Em segundo lugar, os usuários não fazem nada com cuidado e nunca devemos esperar que eles entendam as implicações de segurança de suas ações. Temos que presumir que eles são extremamente incompetentes e provavelmente preguiçosos o suficiente para nunca se limparem. No entanto, a criação de pares de chaves adicionais não é um problema de segurança. O problema de segurança seria fornecer seu nome de usuário e senha em texto simples para um aplicativo estrangeiro.

Além disso - estou preocupado em adicionar um método adicional para revogar sessões - o WordPress já tem um botão "Log Out Everywhere Else" na página de perfil - como um usuário, eu esperaria que isso me desconectasse de todos os aplicativos também ( ou pelo menos me pergunte se eu gostaria de fazer isso?)

Podemos solicitar que o usuário exclua seus pares de chaves, mas eu nunca esperaria que um logout destruísse meu token. Esse não é o comportamento normal ou esperado de um sistema como este e provavelmente criaria o caos e toneladas de solicitações de suporte.

Não fornece nenhuma segurança adicional
Se eu, como um invasor, já tiver seu nome de usuário e senha, não há nada que eu não possa fazer como você (presumindo que não haja 2FA em vigor).

Eu discordo categoricamente. Essa abordagem fornece segurança adicional para acessar seus recursos REST e, se isso não for óbvio, precisamos de mais documentação para torná-lo óbvio. Você está argumentando que, se alguém já tem suas credenciais, você está ferrado, mas também está sugerindo que as utilizemos para dar acesso à API REST. Se é assim que você deseja acessar o REST, use o Basic Auth. Porque isso é exatamente o que estaríamos implementando se usarmos user:pass para criar tokens.

Isso leva ao fato de que, se eu, como um desenvolvedor de aplicativos novato, quiser tornar a vida do meu usuário mais fácil, posso tentar algo desaconselhável, como usar um navegador sem cabeça para fazer login na conta do usuário, criar um token, ler os detalhes e então puxá-los de volta para o meu aplicativo.

É aqui que gostaríamos de criar um fluxo de autenticação que permite dar a um aplicativo o par de chaves por meio do uso de um retorno de chamada. Acredito que algo assim já tenha sido implementado no plug-in de senhas do aplicativo.

Estou 100% aberto para a criação de um fluxo de autenticação para aplicativos que, quando você acessá-lo, será solicitado a fazer login no WordPress, com quaisquer extras como 2factor adicionados, que gerariam um par de chaves para você e, em seguida, usaria algum tipo de retorno de chamada dê ao aplicativo o par de chaves. Assim, os desenvolvedores de aplicativos não precisam criar toneladas de soluções ruins e o aplicativo não armazena seus user:pass .

O que poderia ser feito em vez disso?
A chave atualmente tem um propósito importante - ela é usada para permitir a revogação de um token, apesar dos tokens serem potencialmente de longa duração. No entanto, não precisamos necessariamente de um par de chaves para fazer isso.

Correto, você pode usar muitas abordagens diferentes.

Inspirando-se na entrada session_tokens do WordPress em usermeta - um conjunto armazenado de chaves de revogação específicas do JWT permitiria a mesma funcionalidade e tornaria trivial a implementação da funcionalidade "Log Out Everywhere Else" - apenas exclua essa entrada da tabela.

Isso nunca seria uma substituição da implementação atual que deveria ser adicionada. Eu, como desenvolvedor de software empresarial, nunca usaria esse método. Portanto, embora seja uma abordagem válida, ela não tem a capacidade de esperar que um token seja válido enquanto não expirar ou o token não for revogado. Em seu cenário, no segundo que você faz logoff, o token é inválido. Isso seria IMO uma deficiência no fluxo de autenticação que causaria inúmeros problemas com a capacidade de meus aplicativos de obter acesso a recursos, já que agora está fortemente acoplado ao usuário que está conectado.

E quanto ao 2FA?
Gostaria de saber se seria possível permitir um gancho que os plug-ins 2FA pudessem usar para dizer ao cliente "por favor, tente novamente, fornecendo um token 2FA" se um for necessário, mas não fornecido. Além disso, outro gancho (ou talvez o mesmo?) Poderia ser usado para permitir que o plug-in 2FA verifique se o código fornecido está correto. O sistema JWT não faria suposições sobre como o 2FA é implementado - isso seria deixado para outro plug-in - apenas forneceríamos os ganchos para tornar isso possível.

Isso iria IMO adicionar uma camada desnecessária de complexidade que tem o potencial de criar muitas solicitações de suporte.

Obrigado por ler até aqui - tudo acima é IMHO, mas espero que possamos simplificar um pouco esse processo para os usuários, para que funcione realmente bem pronto para uso para todos.

Tenho certeza de que perdi pelo menos algo, então fico feliz em ouvir qualquer feedback que as pessoas possam ter sobre isso!

Postagem épica. Obrigado por anotar tudo isso. Você realmente pensou muito sobre isso. Quero dizer que não estou tentando derrubar nada. Apenas que, se vamos permitir que tokens sejam criados com uma combinação de user:pass então a maneira como fazemos isso precisa ser muito segura e ter potencial zero para que os aplicativos armazenem suas credenciais de login.

O ponto de separar o acesso e autenticação é proposital e não deve ser considerado levianamente. Estamos construindo a autenticação REST potencial para 1/3 da Internet. Então, até que tenhamos um caminho a seguir, removi a capacidade de criar tokens com credenciais de usuário. Isso não significa que não podemos adicioná-lo de volta, apenas que precisa de muita discussão antes de o fazermos.

Oi! Pelo que entendi, o principal ponto fraco da conversa aqui é a usabilidade. Na verdade, ter usuários indo ao site para fazer o login e criar os pares de chaves será uma fonte de problemas, ou inconveniência, para alguns usuários.

Os desenvolvedores provavelmente tentarão encontrar maneiras não seguras de evitar isso, da mesma forma que hoje eles removem funcionalidades que exigem senhas fortes para o bem de seus usuários.

Embora eu entenda o aspecto de segurança na decisão, e concordo com isso. Mas precisamos encontrar uma maneira que funcione para ambos.

Parece que o que você disse aqui @valendesigns pode ser uma solução possível:

Estou 100% aberto para a criação de um fluxo de autenticação para aplicativos que, quando você acessá-lo, será solicitado a fazer login no WordPress, com quaisquer extras como 2factor adicionados, que gerariam um par de chaves para você e, em seguida, usaria algum tipo de retorno de chamada dê ao aplicativo o par de chaves. Assim, os desenvolvedores de aplicativos não precisam criar toneladas de soluções ruins e o aplicativo não armazena seu usuário: pass.

Pelo que entendi, basicamente manteríamos o fluxo atual, que é mais seguro, pois não precisamos fornecer nossa senha para o aplicativo, em vez de fornecer apenas o par de chaves para gerar o token, mas isso pode ser um obstáculo para alguns .

Mantendo esse outro fluxo onde não precisaríamos dar nossa senha para o aplicativo estrangeiro. Em vez disso, solicitando que eles façam logon no WordPress e gerem o par de chaves.

Eu gostaria de mais informações sobre esta parte:

Podemos solicitar que o usuário exclua seus pares de chaves, mas eu nunca esperaria que um logout destruísse meu token. Esse não é o comportamento normal ou esperado de um sistema como este e provavelmente criaria o caos e toneladas de solicitações de suporte.

Parece que se eu estiver logado no site.com através do navegador e do aplicativo, se eu clicar em "Log Out Everywhere Else" no navegador, também serei desconectado do aplicativo, não ?! Posso ver aplicativos em que essa seria a suposição. A expectativa de que você seria desconectado em todos os lugares.

O mesmo precisa acontecer quando uma conta é excluída.

Tenho que concordar com o que foi dito sobre o UX do par de chaves ser muito hostil ao usuário.

Isso torna muito difícil construir um aplicativo móvel nativo que possa usar este método Auth.

• Eu tinha feito um plug-in personalizado há algum tempo para o (antigo) plug-in OAuth1a que exibia um código QR criptografado (com uma senha curta e configurável) na página de administração de aplicativos (quando o nome do aplicativo e o URL de retorno correspondiam ao meu aplicativo), que então passou as informações do aplicativo cliente para o aplicativo móvel para permitir a autenticação do usuário.

Concedido (trocadilho intencional), JWT é muito mais fácil do que OAuth1a;)

Já que um usuário tem que fazer login no Wordpress (esperançosamente via https) em primeiro lugar, usando um nome de usuário e senha, eu realmente não vejo qual é o problema de segurança de ter o par nome de usuário / senha sendo capaz de obter um token de acesso ? Está tudo sendo enviado pelo mesmo 'telegrama' no final do dia? Certamente?

Aplicar o par de chaves do aplicativo atualmente implementado torna esse método de autenticação absolutamente impossível (no mundo real) para ser usado para aplicativos móveis.

Simplesmente não há uma maneira sensata de fazer com que um aplicativo móvel entre neles.

Eu tentei o OAuth1a, OAuth2 e agora dois plug-ins JWT para implementar meus aplicativos nativos com acesso e todos eles falham 'out-of-the-box', sem alguns hacks para tentar fazer as coisas funcionarem para um usuário. É para ficar mais fácil, certo?

O plugin JWT de terceiros (com mais de 10.000 instalações) oferece suporte a usuário / senha e funciona bem para um aplicativo móvel nativo que venho construindo. Mas falha na falta de tokens de atualização por meio do plug-in, forçando o usuário a 'efetuar login' novamente. (também requer edição manual de wp-config)

Este plugin 'em breve-oficial' (espero!) Falha na falta de facilidade de uso móvel e aparentemente ignora que tipo de aplicativos podem ser desenvolvidos para ele de forma realista. E isso parece muito míope.

Há uma razão para a falta de aplicativos móveis nativos para postar em sites wp.org. E é isso.

Por favor, por favor, podemos começar um movimento sobre isso? (Venho trabalhando em um aplicativo nativo há anos, esperando por uma maneira 'adequada' de autenticar usuários, desde a introdução da API REST)

:)

O fluxo de token UX é maluco e impraticável para uso no mundo real, os usuários devem ser capazes de fazer login com nome de usuário e senha no sistema pedindo um par de chaves de API não faz sentido, você não está empregando abstração aqui, você deve para proteger os usuários dos aspectos técnicos do uso de seu aplicativo, como você se sentirá? Para fazer login no Facebook em seu telefone, você precisa fazer login em um portal de administração no Facebook e criar um par de chaves API e, em seguida, usar o par de chaves API para logar, não estamos desenvolvendo para desenvolvedores, estamos desenvolvendo para o cliente que não sabe em que consiste o aspecto técnico do seu serviço, desinstalando imediatamente. Eu realmente não vejo como este plugin é útil para autenticação.

Este problema com login de usuário> fluxo de token está atrapalhando seriamente o desenvolvimento de tantos aplicativos que poderiam estar usando JWT.

Meses e meses continuam passando e isso simplesmente não está sendo resolvido.

Como eu disse acima, o fato de os usuários usarem um par de nome de usuário / senha para realmente fazer login no Admin faz com que qualquer argumento para não usar pares de nome de usuário / senha para obter um token pareça um tanto inválido? Certamente?

Apenas para atualizar este tópico - parece que este projeto está sendo substituído por um para implementar um fluxo OAuth completo no núcleo WP. Deve abordar as desvantagens das abordagens discutidas aqui, mantendo todos os pontos fortes.

Se você gostaria de se envolver com isso, sinta-se à vontade para pular para # core-restapi no Slack .