Jwt-auth: [pergunta] Caso de uso da API Headless

Criado em 12 dez. 2019 · 3Comentários · Fonte: WP-API/jwt-auth

A arquitetura do fluxo de autenticação neste plugin é ótima; Eu entendo as preocupações de segurança. Embora desabilite talvez o principal caso de uso de tal recurso: Wordpress como um CMS headless.

Desativa a autenticação CMS sem periféricos

Um CMS headless exigiria que os usuários fizessem login via username e password . Uma vez que o usuário tenha um JWT, ele pode enviar solicitações autenticadas para recursos protegidos, em um ambiente CMS headless seria proibitivo e contra-intuitivo pedir aos usuários para gerar tokens de API.

A segurança deve ser implementada através de privilégios RBAC, funções de usuário e responsabilidades ditando o que é protegido na API. As preocupações de segurança podem ser mitigadas por meio de padrões muito rígidos do RBAC. Já o Wordpress possui um ótimo framework de papéis e responsabilidades.

Para abordar as preocupações reais de segurança:

Símbolos de vida longa? Torná-los tokens de curta duração.
Preocupações de que tokens de longa duração possam ser roubados? Assim como os tokens de API, argumento nulo.
As práticas recomendadas do JWT determinam tokens de curta duração e $#$3 refresh_tokens tokens de longa duração (os tokens de atualização são revogáveis) Portanto, isso é mais seguro do que distribuir tokens de API de duração infinita que podem ser perdidos.

Isso não é apenas OAuth2?

Essa abordagem é essencialmente um cenário de concessão de token oAuth2 "personal access" . Assim, eu questionaria os méritos de uma abordagem de servidor de autenticação de token personalizado como essa sobre uma implementação padrão oAuth2 adequada? Se a segurança é a principal preocupação aqui, essa abordagem realmente apresenta riscos de segurança? por exemplo, uma implementação de oAuth2 testada em batalha, como php-league-oatuh-2

Vejo o único caso de uso viável para a autenticação atual do fluxo de autenticação application-to-application ? oAuth2 apresenta vários métodos de fluxo de autenticação para conceder tokens. Um sendo o que essa abordagem usa "personal access" e outro sendo o que estou descrevendo tokens "password access" . Uma implementação completa do oAuth2 permitiria esses dois cenários e muito mais...

Mais longe

Acreditamos que a aceitação do WP-API e, portanto, a modernização do ecossistema Wordpress em geral seria muito melhorada se coisas como autenticação de API sem estado fossem facilmente acessíveis aos desenvolvedores.

Estas são apenas reflexões e adoraria discutir e contribuir!

Ótimo trabalho!

equipe sem cabeça wp

Fonte

andrewmclagan

👍3 🚀1 ❤1

Comentários muito úteis

Eu tenho construído aplicativos nativos (ou tentando) desde antes da API REST chegar ao núcleo. (ou seja: anos)

Inicialmente, a única maneira de meu aplicativo autenticar e fazer upload/criar conteúdo era usar o plug-in 'OAuth1.0a' que a equipe da API iniciou.

Agora tenho as coisas funcionando para o OAuth2.0 (novamente, outro recurso que precisa de um plug-in extra instalado. Não faço ideia se isso chegará ao núcleo)

E agora temos o JWT que apresenta novos problemas em como conectar meu aplicativo. Naturalmente, um nome de usuário/senha funcionaria melhor, fornecendo um token. (Felizmente, esta versão 'WP-API' do JWT suporta a atualização do token. Outro plugin JWT amplamente usado não suporta)

Eu não posso acreditar na enorme quantidade de oportunidades perdidas (e tempo) que estão passando, sem ter uma implementação sólida 'sem cabeça'/móvel para autenticação 'fora da caixa' (no núcleo).

Meu aplicativo móvel requer seu próprio plug-in para fazer seu trabalho e suportar uma série de coisas relacionadas ao administrador e aprimoramentos de rota. blocos personalizados etc. Prefiro não ter que fazer com que os usuários/clientes do meu aplicativo tenham que baixar e instalar outro plug-in 'não totalmente concluído'.

Eu só gostaria que existisse uma solução sólida (e 'oficial').

kosso em 17 dez. 2019

👍3

Todos 3 comentários

Eu tenho construído aplicativos nativos (ou tentando) desde antes da API REST chegar ao núcleo. (ou seja: anos)

Inicialmente, a única maneira de meu aplicativo autenticar e fazer upload/criar conteúdo era usar o plug-in 'OAuth1.0a' que a equipe da API iniciou.

Agora tenho as coisas funcionando para o OAuth2.0 (novamente, outro recurso que precisa de um plug-in extra instalado. Não faço ideia se isso chegará ao núcleo)

Eu só gostaria que existisse uma solução sólida (e 'oficial').

kosso em 17 dez. 2019

👍3

Concordo plenamente. Wordpress está posicionado para se tornar um líder na arena de cms sem cabeça. Parece que a equipe principal faz incursões para isso, mas talvez apenas para servir um caso de uso específico para wordpress.com? Não tenho certeza.

Atualmente estamos desenvolvendo um cliente isomórfico para esta finalidade. Junto com ganchos e provedores de reação. https://github.com/wp-headless/fetch. Talvez tenhamos que escrever nosso próprio plugin de autenticação JWT. Meus pensamentos sobre como deve ser:

Siga as especificações do oAuth2 (por que criar um fluxo de autenticação personalizado?)
Tenha vários métodos de concessão de token: password , machine-to-machine , api-key etc.
dependem de pacotes líderes que são bem testados.

andrewmclagan em 18 dez. 2019

Aqui estou tentando implementar um sistema de registro/autenticação de usuários através da API REST do WP, apenas para descobrir que a equipe do WP está ~~reinventando a roda~~ inventando uma nova roda.