Autenticação via tokens


8

Sou relativamente novo no jwt.io e na autenticação e estou usando o JWT.io da seguinte maneira.

Lado do servidor

Depois que o usuário faz login, eu gero um token useridincorporado e o passo de volta para o usuário no corpo da mensagem

Navegador / JS do cliente Estou armazenando o token no localStorage e, para cada solicitação subsequente, estou passando o token nos cabeçalhos.

Authorization: Basic someEncryptedValue

Eu também usei

X-Auth-Token: someEncryptedValue

Eu poderia usar isso em um cookie?

Em seguida, no lado do servidor, estou verificando o token em relação ao segredo, verificando a validade, obtendo o ID do token e servindo a solicitação.

Está tudo correto neste fluxo de trabalho?


Algum motivo para não seguir um padrão como o OAuth2? Btw: você não deve passar o token como cabeçalho básico auth, em vez usar Authorization: Bearer
Arne Burmeister

Sim, o portador é o certo, o OAuth2 é que eu assumo que é para autenticar usuários por meio de terceiros como google, Facebook etc. Considerando que esse é o meu próprio esquema de autenticação contra a senha do usuário, por favor me esclareça mais se estiver errado
user2727195

1
3rd party auth é apenas uma característica de OAuth, o trabalho perfeitamente com JWT e um servidor de autenticação própria
Arne Burmeister

ok, por favor, me ilumine com alguns tutoriais fáceis de implementar
user2727195

2
Não há necessidade do oAuth, a menos que você precise de aplicativos que compartilhem informações entre eles. Para recursos tão básicos como autenticação, o Jwt é suficiente.
Laiv

Respostas:


1

Seu fluxo de trabalho está correto (supondo que você esteja usando HTTPS) e, sim, você pode simplesmente armazenar seu token em um cookie em vez de passá-lo no cabeçalho da autorização.

Não recomendo usar o OAuth2. Implementar até mesmo o fluxo mais simples corretamente adicionaria muita complexidade ao seu processo de login, e parece-me que você não precisa dele, pois as partes do "lado do servidor" estão todas no mesmo domínio.

Se fosse eu, eu usaria cookies. A adesão a esquemas bem compreendidos deixa menos oportunidades de confusão e significa que o navegador se encarrega de enviar e atualizar seu cookie (por exemplo, considere como você pode lidar com sessões com um tempo limite inativo)


1
Você já considerou as diferenças entre um ataque XSS e CSRF? Eu respeitosamente sugiro que o uso de cookies sozinho possa resultar em uma vulnerabilidade de CSRF mais fácil de explorar do que em um ataque no estilo XSS, enquanto uma autenticação baseada em token, embora ainda vulnerável, é mais difícil de explorar. De qualquer forma, para se proteger totalmente dos dois tipos de ataque, você precisa do cookie e do token de cabeçalho presentes na solicitação para considerar com segurança o usuário autenticado e autorizado.
RibaldEddie

@RibaldEddie Não, eu não tinha - acho que assumi que algum outro mecanismo seria usado para impedir o CSRF. Alguma chance de você entrar em mais detalhes? Como a autenticação baseada em token ainda é vulnerável? E como o uso dos dois métodos protege contra o CSRF?
23717 Justin

O padrão de token criptografado é uma solução. O mesmo ocorre com o cookie de envio duplo. Ambos precisam de outro valor enviado com a solicitação ao usar cookies para passar as credenciais.
RibaldEddie

0

Uma boa leitura. Ele fala sobre como salvar tokens no armazenamento local e depois enviar de volta via javascript na solicitação http.

: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage


6
Por favor, não faça o link apenas para sites externos para evitar a podridão do link. Se o artigo contiver informações valiosas, forneça um resumo do artigo e publique-o aqui.
Andy

1
Há muitas informações valiosas, um resumo dos pontos altos seria bom (como tirar proveito da assinatura JWT, usar cookies e algumas outras etapas).
Berin Loritsch

0

Todos os navegadores agora suportam Digest Auth, que é seguro mesmo através de HTTP. Dependendo dos requisitos exatos, isso pode ser suficiente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.