JWT, algumas dúvidas do fluxo para os mais experientes

[wilsongomes-swe]

Fala galera, implantando o fluxo de autenticação e autorização em minha primeira aplicação fullstack com node e reactjs, e surgiram algumas dúvidas:

(E antes de alguém falar que JWT é apenas o token e não o fluxo, ok! As dúvidas são sobre o fluxo rs)

1 - A resposta da api com o token salvo no cookie ou no local storage? (pelo que vi a maioria utiliza no cookie, mas por quê?)

2 - Como eu implemento aqueles "Reminder me" ou "Se lembrar do login"? Para o usuário não precisar logar sempre, eu altero a expiração do token de 1h para 30 dias por exemplo?

3 - Como protegem as rotas lá no node/express? Vi alguns exemplos em que o pessoal ia em cada rota fazendo a validação mas primeiras linhas do controller/handler protegidos, mas teria de fazer isso em todas as funções... Tem alguma maneira de fazer com um middleware ou um middleware já pronto para isto?

Bom, é isso, se alguém puder me ajudar com estas questões.

Abraços!

[kazzkiq]

1. Assunto amplo com pontos positivos e negativos para os dois lados, recomendo ler a Issue Autenticação: cookies vs local storage vs session storage #1471
2. Um token com tempo de expiração muito grande (30 dias, infinito, etc) não é uma boa ideia na maioria dos casos. O ideal seria criar um token que expire, digamos, a cada 24h(*n) e criar um endpoint de renovação de token, onde você possa requisitar um novo passando o antigo como parâmetro. Quem faria esse trabalho de verificar se o token atual está expirando seria seu front-end. O processo é simples:

1. Front-end verifica se token está expirando (loop);
2. Caso esteja, requisita novo token via API passando o antigo como parametro;
3. Pega o novo token e salva no lugar do antigo na aplicação front-end;
4. Começa a verificar novamente se token está expirando (loop).

3. O controle de acesso de autenticação vai depender muito da tecnologia que você está utilizando. Frameworks como Nest.js ou Adonis já possuem soluções prontas pra isso. Se você estiver fazendo sua API sem uso de frameworks "parrudos", vai ter que implementar na mão. O que não é difícil se pensar que, como você mesmo disse, seria apenas adicionar um middleware nas suas rotas verificando se você recebeu um token JWT e se ele é valido antes de executar qualquer coisa. O Express por exemplo permite que você adicione um middleware em todas as rotas com apenas uma linha de código, o que evita esforço desnecessário.

[victorferreira]

Tem um post excelente do pessoal do Hasura sobre como lidar JWTs. Esse guia aborda todos os assuntos importantes sobre como lidar com JWT, desde onde guardar o token, até como usar o token com SSR. https://blog.hasura.io/best-practices-of-using-jwt-with-graphql/

[kavalcante]

Fala mano! Ótimas perguntas, vou responder com o que eu acredito. Estamos passando justamente por esse processo atualmente. Vou descrever como estamos implementando nosso fluxo e porque optamos por cada etapa.

Ao se logar via API, ela retorna um cookie e um usuário, vou fazer o seguinte com essa informação:

• Armazenar o token no Cookie. As pessoas com quem conversei, armazenam no localStorage, pois ele é mais performático e a cada request ele não recarrega isso. Particularmente eu não sei dizer isso. No nosso caso, não existe outra opção, pois possuímos uma aplicação Server Side Rendered.
• Armazenar o usuário em questão no Vuex (ou Redux) para uso pela aplicação
• Armazenar as roles/permissions e qualquer outra informação que a API retorne no Vuex
• Ao trocar de página, chamamos um endpoint que valida se o token é válido para a versão da API em produção e para manter a segurança da aplicação. Se por algum motivo, fizermos um deploy que quebra o usuário de alguma forma, precisamos relogar ele, aí nesse caso a gente expira o token na mão e o validateToken desloga o cara.
• Ao relogar a página, se identificarmos que existe um token, enviamos para a API um request que me retorna dizendo de quem é aquele token e se ele é válido. Dessa forma, eu armazeno o usuário logado no Vuex novamente (e dessa forma eu não gravo o usuário no cookie).
• O mesmo acontece para as roles dele, ao recarregar, buscamos as roles atuais e armazenamos no Vuex e a aplicação consome do Vuex.

Então, resumindo suas dúvidas:

1. Utilizamos Cookie, mas normalmente recomendam localStorage ou sessionStorage.
2. Validamos se o token está válido conforme os parametros atuais da API (se não houve breaking change do usuário, no caso). Se sim, retornamos o usuário logado para o front saber quem é e não precisar guardar ele no Cookie.
3. No nosso caso, o front-end consulta se o token está válido ao entrar na página (tem um middleware no front). Se ele não estiver, o front desloga ele automaticamente. Eu não sei dizer se temos um middleware na entrada da nossa API, pois eu sou front e não backend. Mas a lógica deve ser a mesma, só não sei te explicar com implementar isso.

OBS: Não estou dizendo que nossa implementação seja a melhor, quis compartilhar justamente pra trocar experiências e você ter uma noção de como as pessoas fazem. Acho que existem muitas formas, pra gente essa foi a que achamos a melhor.

[wilsongomes-swe]

Show galera, muito obrigado!
Implementei a API já rs

Se puderem dar uma olhada:
https://github.com/wilsonneto-dev/Login_JWT_Example_Node_API

A única dúvida que resta é a questão de como fazer o refresh, que já até implementei na api, no login ela responde com o token de chamada e o token de refresh.

Vou guardar o token apenas em memória e mandar nos headers, e o token de refresh vou deixar no localStorage, assim que a requisição voltar com erro 403 cliente verifica se tem token de refresh e envia ele para obter um novo token.

O que acham deste fluxo, correto?

Muito obrigado, abraços.

---

By: ☺️ Wilson Neto
Linkedin
Blog
Github

[dattebayorob]

E como vocês lidam com o tamanho do token? Em um cenário em que muitas permissões impossibilitam o envio dele via cookie e mesmo via header

[wilsongomes-swe]

@dattebayorob boa pergunta, para ser sincero ainda não passei por este cenário... Alguém vai dar uma dica ai

[kazzkiq]

@dattebayorob Por curiosidade eu gerei um token com um payload contendo 100 entradas, e o token gerado pesa ~2.7kb.

Apesar das especificações HTTP não definirem um tamanho máximo para cabeçalhos, os servidores foram lá e implementaram um limite mesmo assim. Dos famosos o que aceita o menor tamanho é o nginx, com 4kb.

Sendo assim, em média, a tendência é que você consiga enviar um payload com umas 150 entradas (~4kb) sem ter nenhum problema com erros de servidor. Acima disso já fica arriscado.

Só um adendo: se você realmente possui uma aplicação com esse número de permissões, talvez valha a pena reavaliar a arquitetura da sua aplicação ou mudar a forma como você lê essas permissões (transformando em um serviço separado ao invés de enviar por payload, por exemplo).