Estratégias de autenticação entre front-end e back-end com JWT (cookies storage) 

conseguiu mano?

up!

UP 2 !

UP 3 😅

up 4

...com a parte do Refresh Token também esta faltando

Eu estou criando um token quando o usuário se cadastra, esse token é armazenado no banco de dados, e quando ele se autentica os dados são gerados. Tem algum problema nesta abordagem ?

@@trechosdelivros4445 Mano acho que na prática o maior problema vai ser o consumo do banco sem muita necessidade (já que isso meio que significaria pagar mais quando tivesse no ar e estivesse crescendo), o JWT funciona de uma forma que você nunca vai precisar armazenar ele, já que ele só precisa ser valido para funcionar e quando não for mais (expirou) o backend já vai conseguir invalidar aquela requisição, a única coisa que vejo sentido em armazenar é o refresh token caso você queira utilizar no seu projeto.

@@filipesantos8001 Eu usei o JWT para autenticação e o session storage para armazenar o ID para fazer o push de dados após a autenticação… você vê algum problema nessa abordagem?

Vc pode proteger as paginas que vc quiser com conditional rendering.

Guarda dentro do JWT a role, ou permissões, caso queira mais escalabilidade. No frontend, faz um decode do JWT e controla a renderização da tela baseada na role ou na permissão, crie um contexto global e no seu router, consuma isso e renderize as rotas condicionalmente, dá para escalar isso muito bem. No backend, crie um middleware que também faça esse decode e guarde no contexto do usuário a role ou as permissões. Com essa informação, você consegue restringir endpoints e mudar comportamentos como resposta, etc.

obrigado, meus manos!!

Tô com essa dúvida também, para quebrar o galho, eu armazeno o id do token criado no registro diretamente em um campo do banco de dados e para fazer a renderização eu puxo por esse campo.

Eu uso o next-auth ou clerk que já gerencia isso tudo via cookies, inclusive com login social

@@maykonsousa84 não podia usar o Clerk, regra do projeto, next-auth deu mais problema do que ajudou pq ele é pro next e não integrou tão bem com nestjs.

Não

Ao meu ver, todos os métodos de autenticação servem apenas para assegurar que a origem da requisição está sendo de quem realmente era pra ser (do próprio usuário autenticado). Partindo do pressuposto que o próprio usuário pode abrir o dev tools e pegar o token dele (ou um terceiro invade a máquina do usuário), mesmo que o token seja usado indevidamente depois disso, a autenticação fez o que ela tinha que fazer que era assegurar que para ter um token, o usuário precisa provar que é ele: se autenticando com suas credenciais antes. Na minha opinião, daí em diante cabe outras estratégias para serem combinadas com a validação do token, como algum tipo de fingerprint básico do usuário, contendo informações como user agent, ip, e mais algumas informações que deem para de certa forma servir como uma impressão digital do usuário que se autenticou, como forma de “minimizar” o risco de uso indevido. Também caberia uma estratégia de rate-limit (seja a nível de IP ou a nível de ID de usuário, pois também seria possível um usuário mal intencionado (ou como citei, alguém que teve seu dispositivo invadido) utilizar proxies rotativos para fazer flood de requisições com IPs diferentes a cada request). Enfim, fica perceptível que quanto mais proteção, mais vão adicionando camadas extras o que envolve códigos mais complicados e cada vez mais usos de recursos para mitigar a segurança. Como o Diego falou, TUDO é um trade-off. Eu acredito que para 99% das aplicações um JWT de curto prazo (5 minutos de duração, por exemplo) aliado a um refresh token de maior duração (por exemplo, 7 dias, assim se o usuário voltar a usar a aplicação antes de 7 dias do último acesso, ele não vai precisar se autenticar novamente, pois o refresh token vai fazer o trabalho dele). Com essa estratégia, você a nível de backend tem o poder de invalidar o refresh token do usuário a hora que você quiser e ele vai ter no máximo 5 minutos antes de perder acesso total a aplicação. Aí onde tem esses 5 minutos, em uma aplicação mais delicada você pode diminuir ainda mais esse tempo.

Se a aplicação é de alto risco (como aplicações que envolvem transações financeiras), eu adotaria a estratégia do JWT + refresh e um 2FA para todas as requisições delicadas. Mais do que isso eu acho completamente exagerado e uma aplicação que PRECISA de mais do que isso para garantir segurança, eu acho que só um reconhecimento facial muito avançado (que também é burlável se o fraudador estiver muito focado 😂😂). Se até impressão digital tem gente que usa molde de silicone pra “clonar” pra outra pessoa bater ponto no relógio com biometria em órgãos públicos, é a prova de que não existe sistema de segurança perfeito 😂😂😂

Ah, e a resposta da sua pergunta se tem como esconder o token é não. A nível de client side, SEMPRE é possível interceptar/editar qualquer coisa que você envia ou recebe utilizando proxy (como o charles proxy).

Arc

@@diegocamara3775 Vlw!

😂😂😂😂 voltei no tempo agora… eu devia ter uns 11 anos, achei numa comunidade do Orkut um tutorial de como roubar os cookies de usuários que usavam mozilla firefox na época, pelo que eu me lembro, o usuário só precisava copiar uma url bem cabulosa e colar na barra de endereços e dar enter (clicar não fazia funcionar). Depois disso, não lembro como pois faz muito tempo, mas eu tinha acesso a um código (que agora, parando pra pensar, provavelmente era apenas os cookies) que eu utilizava uma extensão chamada greasemonkey (algo assim) e quando salvava esses dados da vítima na extensão (que devia injetar nos cookies do meu navegador) automaticamente eu tinha acesso ao Orkut dela, e mesmo que ela mudasse a senha, eu continuava com acesso. Felizmente usei só pra trollar alguns amigos e postar scraps falando besteira, teve até um que não gostou e me deu uns cacetes (merecido 😂😂😂). Nunca tinha parado pra pensar que isso era essa técnica de CSRF pois eu só tinha 11 anos e só sabia que simplesmente funcionava 😂😂😂

Esqueceu de uma palavra ai no meio em mano

So pra constar jwt tem um macetizinho que ninguem te conta!!! e se você e senior e ainda nao chegou no seu ouvido, provavelmente você nao tem os contatos certos

Habla pa nois então

Qual seria uma alternativa melhor?

@@jorgeluizdutraandrade605 session, opaque tokens… jwt tem um caso de uso muito específico onde ele é muito bom (auth entre apis + serviços para client). Não é o caso pra client auth. Não ter revoke já é suficiente pra não usar pra auth do client

Também gostaria de saber, quem sabe você pode gravar um vídeo pra gente ver sua alternativa.

hahaha