Olá!
Fiquei com uma dúvida sobre essa hidratação da autenticação do usuário via localStorage. Achei bem pouco seguro. Há outra forma de fazer essa hidratação?
Solucionado
Olá!
Fiquei com uma dúvida sobre essa hidratação da autenticação do usuário via localStorage. Achei bem pouco seguro. Há outra forma de fazer essa hidratação?
Olá, Jobe, tudo bem?
Ótima observação.
O uso de localStorage em autenticação realmente merece cuidado. O principal risco é o XSS. Se um script malicioso rodar na aplicação, ele consegue ler tudo que estiver salvo ali, inclusive dados sensíveis.
No contexto da aula, o localStorage aparece mais como uma solução didática. Ele ajuda a manter o estado visual da aplicação, como exibir o nome do usuário após um refresh, enquanto a validação real acontece no servidor. Inclusive, o próprio instrutor comenta que o ideal seria esse salvamento acontecer no backend e deixa o token mais sensível em cookie.
Em aplicações reais, o caminho mais seguro costuma ser outro. Em vez de depender do localStorage, a autenticação fica toda baseada em cookies HttpOnly. No login, o servidor salva o token no cookie. Quando a página carrega ou é atualizada, o frontend faz uma requisição para um endpoint como /me. O cookie vai junto automaticamente, o servidor valida e devolve os dados do usuário. Esses dados ficam apenas em memória, no estado da aplicação.
Isso reduz bastante o risco, já que scripts maliciosos não conseguem acessar o cookie nem ler diretamente o estado da aplicação. O custo é apenas um pequeno carregamento inicial ao atualizar a página, algo comum e esperado em sistemas reais.
Resumindo, para o exercício, usar localStorage para guardar dados simples do usuário é aceitável. Para projetos de produção, a boa prática é clara: tokens sensíveis em cookies HttpOnly e os dados do usuário vindo sempre de uma chamada ao backend ao iniciar a aplicação.
Espero que isso esclareça o cenário.
Bons estudos!
Sucesso ✨
Olá, Victor!
Perfeito, agora ficou mais claro. Muito obrigado.