Perfeito!! Gostaria muito de um vídeo fazendo autenticação com nextjs 14 e nodejs no backend, lidando com toda a parte de autenticação com jwt. Tem vídeos no youtube ensinando, mas não é com a mesma qualidade da rocket.
Eu amo a capacidade que a Rocket tem de lançar um vídeo 1 dia antes de acontecer o meu problema KKKKK Fiquei com duvida nisso AGORA e o primeiro video q me aparece no UA-cam é a solução do meu problema kkkkk
Você pode usar token jwt , e quando precisar salvar algo, usar alguma estratégia de cache (como redis). E nas telas mais sensíveis , pedir uma segunda senha
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?
estou com dificuldades em assinar na platafoma da rocketseat, eu vivo em Angola e não tenho um cpf Brasileiro e o sistema não me permitir continuar com a assinatura sem inserir um cpf e um cep
Adoraria que tivesse um lib que cuidasse disso tudo automático pra NestJS e frontend. Tivemos que implementar isso na mão com Keycloak e foi várias horas arrumando bugs e a implementação em sí.
@@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.
Possuo uma aplicação do next que salva o jwt nos cookies com http only. Se eu precisar, pelo front-end, fazer uma requisição diretamente para a API do servidor, ela faz a requisição para a url /api/caminho-da-api. Ainda no Next, tenho um arquivo em /app/api/[..all]/route.ts. Este arquivo de rota pega tudo o que vier depois da /api/ e envia para a URL da API externa, junto com o jwt que só o back tem acesso, com todo o conteúdo da requisição.
😂😂😂😂 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 😂😂😂
no meu projeto, em qualquer requisição que envio pro back-end, preciso enviar o token no cabeçalho, até aí tudo bem, a dúvida é, o projeto tem diversas roles diferentes (perfil de acesso) e cada role muda muito as permissões ou páginas que aparecem. O back-end me envia pelo cabeçalho a role do usuário logado, mas eu sinceramente estou com dúvidas de qual a melhor forma de sempre verificar e mostrar as telas que são permitidas dependendo da role. No React a melhor maneira seria usando contexto global?
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.
Eae mano, blz ? Então, eu tava pensando em "reestudar" desenvolvimento web, mesmo que eu já esteja aprendendo ReactJs e TypeScript pra preenche algo que eu tenha não estudado, se você fosse recomenda um guia para estuda desse HTML até chega em ReactJs, TypeScript, nextjs pra eu chega em um nível de poder trabalhar, qual seria ?
Interessante, mas seguindo a premissa de que se eu der um f12 eu consigo pegar o token, daria pra tentar esconder o token do front-end com a funcionalidade do cross origen que você mencionou em um de seus videos sobre autenticaçã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).
Diegão estou com uma dúvida no next 14 men. Qual a melhor maneira para fazer uma requisição com fetch pasando o jwt que está nos cookies pegar os valores e renderizar no lado do client?
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.
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
@@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
Perfeito!! Gostaria muito de um vídeo fazendo autenticação com nextjs 14 e nodejs no backend, lidando com toda a parte de autenticação com jwt. Tem vídeos no youtube ensinando, mas não é com a mesma qualidade da rocket.
up!
UP 2 !
UP 3 😅
up 4
...com a parte do Refresh Token também esta faltando
Eu amo a capacidade que a Rocket tem de lançar um vídeo 1 dia antes de acontecer o meu problema KKKKK Fiquei com duvida nisso AGORA e o primeiro video q me aparece no UA-cam é a solução do meu problema kkkkk
Explicação muito boa man 👏🏻👏🏻👏🏻
Excelente resumo. Basicamente agora é só implementar a ideia porque a lógica já está explicada
Excepcional como sempre!! Diego faz um video ensinando a autenticação com JWT com AuthContext no Nextjs 14 🙏🏼🙏🏼
Você pode usar token jwt , e quando precisar salvar algo, usar alguma estratégia de cache (como redis). E nas telas mais sensíveis , pedir uma segunda senha
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?
estou com dificuldades em assinar na platafoma da rocketseat, eu vivo em Angola e não tenho um cpf Brasileiro e o sistema não me permitir continuar com a assinatura sem inserir um cpf e um cep
conseguiu mano?
Adoraria que tivesse um lib que cuidasse disso tudo automático pra NestJS e frontend. Tivemos que implementar isso na mão com Keycloak e foi várias horas arrumando bugs e a implementação em sí.
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.
esse cara sabe de algo!!
Que conteúdo top, Diegao!
Cursinho ótimo
Possuo uma aplicação do next que salva o jwt nos cookies com http only.
Se eu precisar, pelo front-end, fazer uma requisição diretamente para a API do servidor, ela faz a requisição para a url /api/caminho-da-api.
Ainda no Next, tenho um arquivo em /app/api/[..all]/route.ts. Este arquivo de rota pega tudo o que vier depois da /api/ e envia para a URL da API externa, junto com o jwt que só o back tem acesso, com todo o conteúdo da requisição.
Deveria ter um video fzd uma tela auth com React puro junto com auth de rotas publicas e privadas
Que maravilha ❤❤
Essas lives acontecem aonde?
up pra fazerem um vídeo com autenticação jwt + nextjs14
Esses cortes fazem parte de alguma live na twitch ou outra plataforma?
Um caso divertido, o antigo Orkut era na base do CSRF, você conseguia roubar sessões facilmente
😂😂😂😂 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
no meu projeto, em qualquer requisição que envio pro back-end, preciso enviar o token no cabeçalho, até aí tudo bem, a dúvida é, o projeto tem diversas roles diferentes (perfil de acesso) e cada role muda muito as permissões ou páginas que aparecem. O back-end me envia pelo cabeçalho a role do usuário logado, mas eu sinceramente estou com dúvidas de qual a melhor forma de sempre verificar e mostrar as telas que são permitidas dependendo da role. No React a melhor maneira seria usando contexto global?
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!!
Eae mano, blz ? Então, eu tava pensando em "reestudar" desenvolvimento web, mesmo que eu já esteja aprendendo ReactJs e TypeScript pra preenche algo que eu tenha não estudado, se você fosse recomenda um guia para estuda desse HTML até chega em ReactJs, TypeScript, nextjs pra eu chega em um nível de poder trabalhar, qual seria ?
Interessante, mas seguindo a premissa de que se eu der um f12 eu consigo pegar o token, daria pra tentar esconder o token do front-end com a funcionalidade do cross origen que você mencionou em um de seus videos sobre autenticaçã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).
Diegão estou com uma dúvida no next 14 men. Qual a melhor maneira para fazer uma requisição com fetch pasando o jwt que está nos cookies pegar os valores e renderizar no lado do client?
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.
No começo eu não tava entendendo..no final parecia que eu tava no começo kkkk obs: sou iniciante
Onde ele faz live?
Aulao
Parece que o Chrome vai cancelar alguns cookies no navegador, HttpOnly e signed serão cancelados ?
Não
Que navegador é esse?
Arc
@@diegocamara3775 Vlw!
CORS e cookie configurado com o SameSite: Lax já é suficiente pra mitigar o CSRF
To vendo geral elogiando ai mais ninguem ta falando a verdade pra galera!!! Fica esperto 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
jwt pra auth client server 🤢
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
Excepcional como sempre!! Diego faz um video ensinando a autenticação com JWT com AuthContext no Nextjs 14 🙏🏼🙏🏼