Participe do balta.io Experience, um evento online, ao vivo e gratuito que vai reunir grandes nomes da internet em uma experiência única! 👉 balta.io/experience
Um tutorial completo, incluindo, armazenamento em cookie, identity, armazenamento na tabela de tokens do identity... seria fantástico! Eu comprei um curso no udemi de identity, mas não explica jwt em profundidade
Obrigado André Baltieri por este e todos os outros videos que tens publicado. Um optimo trabalho que tem clarificado muitas das minhas duvidas, sobretudo sobre arquitectura de API REST. Thanks
Não entendi uma coisa: Se você salvar os tokens em memoria num servico AddScoped, a lista do serviço vai ser gerada novamente a cada requisição. Como você fez pra memoria funcionar? AddSingleton?
Muito legal o vídeo...Balta, alguma possibilidade de você fazer um módulo nos seus cursos pagos ensinando a implementar essa parte de validação de forma robusta?! Talvez até integrando back com front...sempre que planejo alguns projetos pessoais, ou de estudo mesmo, fico muito inseguro com relação à segurança...um módulo destes, ajudaria demais a entendermos o passo a passo de como tornar uma autenticação/autorização realmente segura.
Olá Balta, primeiramente parabéns pelos vídeos!! Curtos e direto ao ponto. Uma dúvida que vc comentou sobre armazenar o token. Pra vc, onde seria o melhor lugar para armazenar o token? Pois hoje eu armazeno no localstorange. A cada requisição eu válido se o token está válido.
o RefreshToken ao contrário do Token normal ele persiste no banco de dados e precisa sempre atualizado a cada requisição? ou é necessario colocar uma lógica para ele atualizar o refreshtoken faltando X tempo para o token original expirar para evitar sobrecarga nas requisições?
Uma pergunta, eu poderia em vez de salvar esse refresh token, criar um token criptografado que estaria retornando dentro do token , e esse mesmo refresh token retornando normal ali no json? Ou ficaria algo meio estranho de se pensar
Balta, fiquei com uma dúvida. Pode me dizer um cenário em que o front-end requisita esse end-point de gerar um novo token a partir do refresh token? Tipo por um setTimeout pra fazer essa requisição a cada x horas seria uma abordagem interessante?
Balta, vc poderia mostrar um exemplo de como gerar e validar um token com múltiplos Roles? Se alguém ver essa minha mensagem, poderia me informar onde acho isso?
Excelente esse vídeo! Eu tenho uma dúvida: Eu quero configurar meu token para expirar em 2h, porém enquanto o usuário estiver em atividade deve manter a autenticação. Se ele ficar 2h sem qualquer interação com a api ai sim ele expira... Eu faço isso apenas com Refresh Token? Ou tem alguma outra forma? Pergunto isso porque imagino que o front end terá que sempre fazer 2 requisições: 1 para o refresh token e outra para o método desejado (GET, POST, etc). Muito obrigado pelo conteúdo!
Eu estou com uma dúvida relacionada a esse refresh token. Se a chave do JWT já me garante que aquele token foi criado pela minha aplicação, porque eu preciso de um refresh token? No meu modo de ver, isso leva a uma falha de segurança! O que é que eu ainda não consegui enxergar em relação ao refresh token? Qual a real necessidade dele? Eu não poderia simplesmente verificar a expiração do JWT na próxima requisição do usuário e caso estivesse próximo de expirar renovar aquele JWT? Não é mais ou menos essa a lógica das sessions?
O refresh token é uma chave extra, que assim como o Token, se cair nas mãos erradas, permite impersonar o usuário... Os dois tem issues de segurança, depende de como você armazena eles...
@@baltaio obrigado pelo retorno! O que eu imagino é que, vc definindo uma data de expiração do JWT não vejo porque ter o refresh token, pois se o usuário não fizer nenhuma requisição em por exemplo 15 minutos (aqui estou pesando semelhante ao funcionamento das sessions) na requisição no minuto 16 por exemplo o token dele estará vencido e consequentemente a "sessão" dele cairá, necessitando de um novo login. Como o JWT tem que ser decodificado e validado a cada requisição, nesse momento pode ser identificado que o JWT está próximo do vencimento e já renova-lo. E porque eu disse que o refresh token pra mim traz uma falha na segurança? Porque se o JWT na minha abordagem expirar e cair em mãos erradas, ele já terá perdido a validade e boas! Já na abordagem do refresh token se o JWT e o refresh token cair em mãos erradas, mesmo com o JWT vencido, o atacante conseguirá gerar um novo JWT com o refresh token. Obs.: Não é uma crítica a forma que está sendo feito tah? Só estou tentando entender o porquê do refresh token.
@@WalisonSoares entendo que para um frontend onde o usuário usar por horas, a cada token vencido você teria que descer no banco para recuperar usuário e senha para gerar um novo token. Isso se sua atenticação estiver sendo feita por usuários e não por aplicação, claro.
@@rafaelberto729 Eu já tenho o JWT, não precisaria autenticar o usuário novamente. Bastaria renovar o tempo de expiração do JWT gerando um novo JWT. Não entendi o sentido de trabalhar com 2 tokens. O JWT e o refresh token.
@@WalisonSoares mano, vc ia precisar fazer o login de novo. entrando com seu usuario e senha. com o refresh token, o front end se re-autentica e voce nao precisa digitar login e senha de novo. entendeu?
Não daria pra armazenar o refresh token diretamente como uma informação do JWT? Como ele é assinado com uma chave privada forjar os dados dentro do JWT seria criptograficamente impossível, então a integridade dos dados como foram criados seria assegurada pela própria assinatura
Seria conveniente que no frontend tivesse um setInterval() para a cada X tempo fazer uma requisição de refreshToken e em seguida atualiza-se o token no LocalStorage ?
No meu app com vue3 e axios, eu crio interceptadores para o request, assim que eu tentar acessar uma rota e o retorno for algo como 401, eu simplesmente envio um request para renovar o access token com o refresh token e em seguida tento repetir a operação, se esta falhar novamente, eu excluo o refresh token e redireciono o user para a tela de login, sendo que eu não tenho mais nada a fazer. Assim você persiste o usuário logado entre sessões, criando uma experiência de usuário bacana, mais ou menos como você tem com suas contas google por exemplo.
@@luan_maik Eu tinha feito uma resposta muito mais completa aqui, mas por alguma razão o youtube apagou o comentário, basicamente você precisa entender que existe uma diferença entre refresh token e access token.
2 года назад+1
o que fazer se vc precisa revogar o acesso de um usuário que já tem o token antes do vencimento do token? Tipo revogar um role ou um claim?
Deixa eu perguntar, é possível fazer algo parecido quando se usa autenticação por cookie? Eu estou precisando fazer uma implementação que é invalidar a sessão anterior do usuário quando ele faz login em um novo local. Eu acredito que para fazer isso eu preciso criar um token com uma expiração bem pequena, diria até de minutos, e daí a aplicação sempre vai estar gerando um token novo através do refresh-token, mas tem um custo de fazer um token expirar rápido né, tem outra técnica para fazer isso?
Opa Balta, sobre essa técnica que você usa pra gerar um novo token a partir do access token não expirado, não poderia ser uma falha de segurança? Porque se o token for roubado da maquina do usuário o cracker/hacker tecnicamente consegue manter o token vivo pra sempre requisitando o endpoint de renovação, uma vez que mesmo com o logout do user o token vai continuar válido. Eu geralmente uso um access token com tempo bem baixo de expiração (15 minutos) e mantenho o refresh token do user no meu banco de dados, quando o usuário faz logout eu simplesmente excluo o refresh token do db e em 15 minutos o access token não vai mais ter validade.
Se o token é a hash forem roubados já era! Mas não tem outra forma de gerar um token a partir de outro token expirado... é o risco que se corre... por isto vários lugares não tem refresh token
@@baltaio No caso não seria mais recomendado salvar a hash em um banco associando a id do usuário e ao passar o token ele faz a validação para fazer o refresh caso seja necessário?
Balta é possível subir uma API de Autenticação e utilizar o Token gerado por essa API para ter acesso as outras APIs? Estou um pouco travado com relação a Key. Como as demais APIs vão conseguir ler este Token? Desde já agradeço.
Sim é possível! Você pode ter um Endpoint que valida o token e que outras APIs podem consumir... Porém neste cenário, o que você procura pode ser algo parecido com Identity Server ou Keycloak
Participe do balta.io Experience, um evento online, ao vivo e gratuito que vai reunir grandes nomes da internet em uma experiência única!
👉 balta.io/experience
Como diz o Balta, "Direto ao ponto"! Simples, prático e rápido, muito boa didática, parabéns pelo conteúdo.
Muito obrigado 💜
Você poderia fazer vídeo explicação esta partes das validações. Ex: ValidIssuer, ValidAuthority, ValidAudiences.
Posso, claro!! Em breve
Um tutorial completo, incluindo, armazenamento em cookie, identity, armazenamento na tabela de tokens do identity... seria fantástico! Eu comprei um curso no udemi de identity, mas não explica jwt em profundidade
Obrigado André Baltieri por este e todos os outros videos que tens publicado. Um optimo trabalho que tem clarificado muitas das minhas duvidas, sobretudo sobre arquitectura de API REST. Thanks
Muito obrigado 💜
Obrigado, estou desenvolvendo uma API pro meu TCC da minha escola e seus vídeos estão me ajudando muito❤️
Parabéns balta, ótimo conteúdo, me ajudou bastante.
💜💜💜💜
Otimo video, muito simples e rápido!! Parabéns!!
Espero ter ajudado
Esse tópico é mto bom e mais complexo do que parece
Não entendi uma coisa: Se você salvar os tokens em memoria num servico AddScoped, a lista do serviço vai ser gerada novamente a cada requisição. Como você fez pra memoria funcionar? AddSingleton?
AddScoped só dura enquanto a requisição existir, AddSingleton enquanto a aplicação não for reiniciada.
No caso foi apenas uma demo!
Top demais! Valeu pelo teu conteúdo!
Show de bola!
💜
Parabéns !!
Obrigado 💜
Parabéns
Obrigado 😃
Muito legal o vídeo...Balta, alguma possibilidade de você fazer um módulo nos seus cursos pagos ensinando a implementar essa parte de validação de forma robusta?! Talvez até integrando back com front...sempre que planejo alguns projetos pessoais, ou de estudo mesmo, fico muito inseguro com relação à segurança...um módulo destes, ajudaria demais a entendermos o passo a passo de como tornar uma autenticação/autorização realmente segura.
Já está no curso novo de ASP.NET 6 que sai em novembro!
@@baltaio sempre a frente de seu tempo haha. Obrigado Dr. Não vejo a hora!
💜
Olá Balta, primeiramente parabéns pelos vídeos!! Curtos e direto ao ponto.
Uma dúvida que vc comentou sobre armazenar o token.
Pra vc, onde seria o melhor lugar para armazenar o token?
Pois hoje eu armazeno no localstorange.
A cada requisição eu válido se o token está válido.
LocalStorage 💜💜
o RefreshToken ao contrário do Token normal ele persiste no banco de dados e precisa sempre atualizado a cada requisição? ou é necessario colocar uma lógica para ele atualizar o refreshtoken faltando X tempo para o token original expirar para evitar sobrecarga nas requisições?
O RefreshToken é apenas uma chave extra, usada para gerar um token válido, já expirado!
Uma pergunta, eu poderia em vez de salvar esse refresh token, criar um token criptografado que estaria retornando dentro do token , e esse mesmo refresh token retornando normal ali no json? Ou ficaria algo meio estranho de se pensar
O que vem no token é apenas uma chave... não outro token...
Top man, vlw demais
Obrigado 💜
Balta, fiquei com uma dúvida. Pode me dizer um cenário em que o front-end requisita esse end-point de gerar um novo token a partir do refresh token? Tipo por um setTimeout pra fazer essa requisição a cada x horas seria uma abordagem interessante?
Pode ser um timeout ou mesmo gerar um tken novo a cada requisição e ter um tempo de expiração menor
Balta, vc poderia mostrar um exemplo de como gerar e validar um token com múltiplos Roles? Se alguém ver essa minha mensagem, poderia me informar onde acho isso?
Opa, mostro sim!
Vlw Balta
💜
Excelente esse vídeo! Eu tenho uma dúvida: Eu quero configurar meu token para expirar em 2h, porém enquanto o usuário estiver em atividade deve manter a autenticação. Se ele ficar 2h sem qualquer interação com a api ai sim ele expira... Eu faço isso apenas com Refresh Token? Ou tem alguma outra forma?
Pergunto isso porque imagino que o front end terá que sempre fazer 2 requisições: 1 para o refresh token e outra para o método desejado (GET, POST, etc).
Muito obrigado pelo conteúdo!
Não, você pode a cada requisição renovar este token... gerar um token novo e armazenar! É uma estratégia!
Eu estou com uma dúvida relacionada a esse refresh token. Se a chave do JWT já me garante que aquele token foi criado pela minha aplicação, porque eu preciso de um refresh token?
No meu modo de ver, isso leva a uma falha de segurança!
O que é que eu ainda não consegui enxergar em relação ao refresh token? Qual a real necessidade dele?
Eu não poderia simplesmente verificar a expiração do JWT na próxima requisição do usuário e caso estivesse próximo de expirar renovar aquele JWT?
Não é mais ou menos essa a lógica das sessions?
O refresh token é uma chave extra, que assim como o Token, se cair nas mãos erradas, permite impersonar o usuário... Os dois tem issues de segurança, depende de como você armazena eles...
@@baltaio obrigado pelo retorno!
O que eu imagino é que, vc definindo uma data de expiração do JWT não vejo porque ter o refresh token, pois se o usuário não fizer nenhuma requisição em por exemplo 15 minutos (aqui estou pesando semelhante ao funcionamento das sessions) na requisição no minuto 16 por exemplo o token dele estará vencido e consequentemente a "sessão" dele cairá, necessitando de um novo login.
Como o JWT tem que ser decodificado e validado a cada requisição, nesse momento pode ser identificado que o JWT está próximo do vencimento e já renova-lo.
E porque eu disse que o refresh token pra mim traz uma falha na segurança?
Porque se o JWT na minha abordagem expirar e cair em mãos erradas, ele já terá perdido a validade e boas! Já na abordagem do refresh token se o JWT e o refresh token cair em mãos erradas, mesmo com o JWT vencido, o atacante conseguirá gerar um novo JWT com o refresh token.
Obs.: Não é uma crítica a forma que está sendo feito tah? Só estou tentando entender o porquê do refresh token.
@@WalisonSoares entendo que para um frontend onde o usuário usar por horas, a cada token vencido você teria que descer no banco para recuperar usuário e senha para gerar um novo token. Isso se sua atenticação estiver sendo feita por usuários e não por aplicação, claro.
@@rafaelberto729 Eu já tenho o JWT, não precisaria autenticar o usuário novamente. Bastaria renovar o tempo de expiração do JWT gerando um novo JWT. Não entendi o sentido de trabalhar com 2 tokens. O JWT e o refresh token.
@@WalisonSoares mano, vc ia precisar fazer o login de novo. entrando com seu usuario e senha. com o refresh token, o front end se re-autentica e voce nao precisa digitar login e senha de novo. entendeu?
Não daria pra armazenar o refresh token diretamente como uma informação do JWT? Como ele é assinado com uma chave privada forjar os dados dentro do JWT seria criptograficamente impossível, então a integridade dos dados como foram criados seria assegurada pela própria assinatura
Acho que daria sim... nunca pensei desta forma, obrigado... vale um teste hein :D
Balta,
Como conseguirmos fazer endpoint d validação do token nas aplicações consumidoras deste Server de Auth?
Só criar um método com o atributo Authorize que retorna o valor que vc precisar...
Seria conveniente que no frontend tivesse um setInterval() para a cada X tempo fazer uma requisição de refreshToken e em seguida atualiza-se o token no LocalStorage ?
Já fiz isto uma vez... é uma saída mas não vejo como a melhor...
No meu app com vue3 e axios, eu crio interceptadores para o request, assim que eu tentar acessar uma rota e o retorno for algo como 401, eu simplesmente envio um request para renovar o access token com o refresh token e em seguida tento repetir a operação, se esta falhar novamente, eu excluo o refresh token e redireciono o user para a tela de login, sendo que eu não tenho mais nada a fazer. Assim você persiste o usuário logado entre sessões, criando uma experiência de usuário bacana, mais ou menos como você tem com suas contas google por exemplo.
@@diegorocha2186 pensei que quando o token expirava não dava mais para fazer o refresh.
@@luan_maik Eu tinha feito uma resposta muito mais completa aqui, mas por alguma razão o youtube apagou o comentário, basicamente você precisa entender que existe uma diferença entre refresh token e access token.
o que fazer se vc precisa revogar o acesso de um usuário que já tem o token antes do vencimento do token? Tipo revogar um role ou um claim?
Armazenar o Token e comparar o enviado com o armazenado a cada requisição para ver se ainda é válido!
Deixa eu perguntar, é possível fazer algo parecido quando se usa autenticação por cookie?
Eu estou precisando fazer uma implementação que é invalidar a sessão anterior do usuário quando ele faz login em um novo local.
Eu acredito que para fazer isso eu preciso criar um token com uma expiração bem pequena, diria até de minutos, e daí a aplicação sempre vai estar gerando um token novo através do refresh-token, mas tem um custo de fazer um token expirar rápido né, tem outra técnica para fazer isso?
Com certeza! É o modelo padrão que o ASP.NET usa (Não APIs)...
Balta, já te disseram que tu podia facilmente imitar o Vinheteiro?
Que honra!!!
Tive um erro com o token, posso postar aqui ? é com relação a data parece que o jwt esta pegando uma data que não é do meu computador.
Provavlemente UTC!
@@baltaio sim. Eu estava vendo outro vídeo sobre refrestoken. Mas não apliquei ainda. Obrigado pelo conteúdo.
Opa Balta, sobre essa técnica que você usa pra gerar um novo token a partir do access token não expirado, não poderia ser uma falha de segurança? Porque se o token for roubado da maquina do usuário o cracker/hacker tecnicamente consegue manter o token vivo pra sempre requisitando o endpoint de renovação, uma vez que mesmo com o logout do user o token vai continuar válido. Eu geralmente uso um access token com tempo bem baixo de expiração (15 minutos) e mantenho o refresh token do user no meu banco de dados, quando o usuário faz logout eu simplesmente excluo o refresh token do db e em 15 minutos o access token não vai mais ter validade.
Se o token é a hash forem roubados já era! Mas não tem outra forma de gerar um token a partir de outro token expirado... é o risco que se corre... por isto vários lugares não tem refresh token
@@baltaio No caso não seria mais recomendado salvar a hash em um banco associando a id do usuário e ao passar o token ele faz a validação para fazer o refresh caso seja necessário?
Balta é possível subir uma API de Autenticação e utilizar o Token gerado por essa API para ter acesso as outras APIs? Estou um pouco travado com relação a Key. Como as demais APIs vão conseguir ler este Token? Desde já agradeço.
Sim é possível! Você pode ter um Endpoint que valida o token e que outras APIs podem consumir...
Porém neste cenário, o que você procura pode ser algo parecido com Identity Server ou Keycloak
Link do repositório?????????
github.com/andrebaltieri