Tem um problema nessa abordagem. O objetivo do refresh token é garantir a segurança de quando alguém fizer a renovação, o refresh token antigo deixa de funcionar automaticamente, por estar armazenado no banco de dados. Na forma que você explicou, caso alguém roube meu refresh token mesmo que antigo (ainda não expirado), essa pessoa poderia multiplicar os refresh tokens, quando que na abordagem original, no momento que eu fizer a primeira renovação, o refresh token anterior já deixa de funcionar. No caso de meu refresh token for roubado antes de eu renovar, quando eu for tentar acessar um serviço vou ter erro na renovação, o que vai me fazer logar novamente. No login, o correto é que o refresh token da sessão anterior seja descartado e passe a valer o novo refresh token. Mas isso tudo não invalida a qualidade do seu vídeo. Parabéns e siga em frente.
Exato. Um vazamento de refresh token que não é persistido no banco pode ser catastrófico por permitir que o invasor gere novos ATs infinitamente. Neste caso, se não for persistir no banco eu iria preferir não utilizar RTs e usar apenas ATs.
Não existe só uma abordagem de refresh token e claramente vamos discordar em gênero, número e grau. O objetivo do refresh token segundo a Okta é: "um refresh token é um artefato de credencial que permite que uma aplicação cliente obtenha novos tokens de acesso sem precisar solicitar que o usuário faça login novamente". Exatamente como o video aborda. O seu exemplo recai sobre controle de sessão. Se há uma grande necessidade de controle sobre a sessão do usuário, esse video não atende esse propósito. E uma solução caseira não deveria nem ser cogitada, o ideal é buscar players profissionais. Por exemplo a Keycloak, e mesmo ele tem a opção de offline tokens. Que pode sofrer replay attack, mas há cenários em que ele é utilizado. Bem como a abordagem do video. Agora ao ponto sobre replay attack, é possivel mitigar utilizando a estrutura que as frameworks te dão sem a necessidade de adicionar código, tabelas e cerimonias a mais. Na linha que o video segue. O demo que está no github já está com a opção "One Time Only", respeitando as limitações impostas pela framework, caso contrário, voltamos a questão do paragrafo acima. O único ponto que vamos concordar é: se alguém for capaz de roubar o refresh token ele vai conseguir usar sua sessão e multiplicar. Mas não dá para falar do efeito sem uma explicação do vetor de ataque e quais ações práticas o atacante tem. Dependendo vetor, como um mitm, uma falha em que automatizou o ataque, em muitos cenários tanto um refresh token com proteção de replay ou sem, até mesmo aplicação que usa cookie vai sofrer o ataque igual. E nao querendo ser redundante, se está diante de um cenário que tem tanta necessidade de segurança e controle, utilize um player de mercado.
Ótimo vídeo e ótima explicação, uma dúvida: sempre que chamar a rota de refresh token irá gerar um access token e um refresh token, como o refresh token irá expirar?
Tenho essa mesma dúvida. Tipo, se eu uso um refresh token para conseguir tanto um novo access token quanto um novo refresh token, como que o antigo se torna inválido, sendo que ainda não venceu? Você tem encontrado essa resposta?
O principal fator de segurança do refresh token não é o tempo de expiração, pode ser 1 dia, 1 mês. O que torna o refresh token seguro é o fato dele ser utilizado uma unica vez, como consequencia a chance de um ataque mitm com sucesso é reduzido.
@@Trankiliss então o sistema continua sendo seguro, mesmo se eu trocar um refresh token por um novo access token e um novo refresh token sem tornar o antigo refresh token inválido?
@@pedrofaria7322 Ai buguei pq segundo o comentário do Bruno Brito não kkkkk. Pq o antigo refresh token ainda poderia ser usado mas fiquei nessa dúvida também.
No caso, ao usuario exemplo realizar login, voce entrega pra ele dois tokens, um access token e um refresh token, os dois gerados pelo jwt com payload de email? ai quando o access token expira, você verifica se existe um refresh token e valida ele, se tiver você gera outro access token e outro refresh token usando a mesma abordagem anterior e assim vai? é isso?
Sendo que os dois (access e refresh) tem o mesmo TokenValidationParameters. Nesse caso se usar o access no lugar do refresh (ou ao contrário) irá funcionar né? porq seria um problema o usuário ficar fazendo a requisição com refreshtoken (que pode ter muitos dias, e até meses, de validade). Qual seria a forma mais correta de corrigir isso?
Chaves de criptografia diferente, amigo. Seus serviços que apenas validam access token com uma public key, não vai conseguir validar um refresh token, pq ambos foram gerados com chaves privadas diferentes
Cara, uma dúvida que estou tendo e não vejo ninguém falar, é sobre o momento ideal para gerar o novo token a partir do refresh token. Imagine que na hora que estou enviando algum formulário o token está expirado. Eu preciso adicionar capacidade de gerar novo token e reenviar a requisição atual em todas as funções de requisição do meu front? Ou tem alguma prática melhor pra isso?
Show de bola! A única coisa que me vem em mente agora seria sobre como invalidar refresh tokens já utilizados. Não seria uma falha de segurança? Até porque nesse exemplo eles seriam validos por 30 dias. Obrigado pelo conteúdo!
Olá Fredi, vc tem razão, não abordei esse cenário. Atualmente existem dois tipos de abordagens para refresh token, One Time Use e ReUse. Acredito que a melhor forma de visualizar um RT ReUse é comparar ao Cookie emitido por um site que tem um tempo de 60 / 90 dias de vida. Definitivamente One Time Use vc precisa de uma persistencia.
Apenas complementando. Vc pode utilizar a estratégia de One Time Use através de uma claim no usuario, evitando criar uma estrutura de controle para isso.
Nesse caso você pode criar uma BlackList de refresh tokens. Depois de você utilizá-lo no refresh, você salva ele no REDIS e verifica se ele tá Blacklist antes de fazer o refresh, caso esteja lá, da um erro genérico para o usuário. Já implementei essa estratégia em cliente que necessitava de um "botão de emergência" para invalidar token. Como o acess_token era só de 1 minuto, então não precisou, só implementamos no refresh mesmo, mas se precisar, faz para o access também.
@@lucasreinaldo1063 A conta entre ter muito controle sobre os tokens e a facilidade de implementação é uma equação que nunca fecha. Os riscos de um Refresh Token vazado e um Cookie vazado são praticamente os mesmos. A abordagem de manter a sessão, mitigar o problema do JWT e garantir a facilidade de implementação atende aos princípios do Refresh Token. No entanto, se um Refresh Token for vazado, o dano pode ser tão ruim quanto o vazamento de um Cookie de sessão.
Sem contar que hoje em dia já existem empresas que oferecem esse serviço de "barramento", como por exemplo o da Sensedia, que já fazem todo esse controle e gerenciamento de Token para as APIs da empresa que trabalhamos.
Mas se você não armazena o token no banco não perde a capacidade de bloquear o token em vez do usuário? Suponha que um refresh token tenha vazado ai você vai e bloqueia o usuário enquanto ele não faz login novamente. Nesse intervalo quem roubou o refresh token vai ficar impossibilitado de fazer qualquer coisa porém se o usuário faz login de novo ele é desbloqueado e se o token roubado ainda estiver dentro da validade ele volta a funcionar para obtenção de access token.
Se o seu banco de dados vazou você já está lascado, mas eu conheço duas formas de invalidar os tokens sem precisar armazenar os tokens válidos: 1.criar uma blacklist apenas dos tokens inválidos (que não expiraram ainda. Por exemplo: você gerou um novo refresh token antes do antigo expirar, então, armazena o ANTIGO na blacklist). 2.Trocar o segredo no servidor (todos os tokens com segredo antigo se tornam inválidos). Acredito que se seu banco vazou, todos os usuários teriam que fazer a recuperação de conta e gerar uma senha e token novos, então, trocar o segredo poderia ser o caminho.
Renato, os vetores de ataque para um Refresh Token vazado são semelhantes aos de um Cookie vazado, nem por isso o Cookie é armazenado no banco de dados. Existem dois tipos de Refresh Token: one-time use (que você está se referindo) e reutilizável. Ambos têm seus próprios casos de uso e são suportados por muitos provedores de OAuth2. Se você deseja ter mais controle sobre seus tokens, pode considerar repensar seu sistema de autenticação e mudar para um provedor OAuth2, que oferece mecanismos e recursos de segurança adicionais. O video aborda o caso de reuso do refresh token que atende ao seu principio: Mitigar os vetores de ataque e facilitar a implementação.
Tem um problema nessa abordagem. O objetivo do refresh token é garantir a segurança de quando alguém fizer a renovação, o refresh token antigo deixa de funcionar automaticamente, por estar armazenado no banco de dados. Na forma que você explicou, caso alguém roube meu refresh token mesmo que antigo (ainda não expirado), essa pessoa poderia multiplicar os refresh tokens, quando que na abordagem original, no momento que eu fizer a primeira renovação, o refresh token anterior já deixa de funcionar.
No caso de meu refresh token for roubado antes de eu renovar, quando eu for tentar acessar um serviço vou ter erro na renovação, o que vai me fazer logar novamente. No login, o correto é que o refresh token da sessão anterior seja descartado e passe a valer o novo refresh token.
Mas isso tudo não invalida a qualidade do seu vídeo. Parabéns e siga em frente.
Sim! Bem observado. Seu raciocínio está correto, espero que todos também consigam entender. Parabéns!
Eu ia comentar exatamente isso. perfeita a sua observação.
Exato. Um vazamento de refresh token que não é persistido no banco pode ser catastrófico por permitir que o invasor gere novos ATs infinitamente. Neste caso, se não for persistir no banco eu iria preferir não utilizar RTs e usar apenas ATs.
Não existe só uma abordagem de refresh token e claramente vamos discordar em gênero, número e grau.
O objetivo do refresh token segundo a Okta é: "um refresh token é um artefato de credencial que permite que uma aplicação cliente obtenha novos tokens de acesso sem precisar solicitar que o usuário faça login novamente". Exatamente como o video aborda.
O seu exemplo recai sobre controle de sessão. Se há uma grande necessidade de controle sobre a sessão do usuário, esse video não atende esse propósito. E uma solução caseira não deveria nem ser cogitada, o ideal é buscar players profissionais. Por exemplo a Keycloak, e mesmo ele tem a opção de offline tokens. Que pode sofrer replay attack, mas há cenários em que ele é utilizado. Bem como a abordagem do video.
Agora ao ponto sobre replay attack, é possivel mitigar utilizando a estrutura que as frameworks te dão sem a necessidade de adicionar código, tabelas e cerimonias a mais. Na linha que o video segue. O demo que está no github já está com a opção "One Time Only", respeitando as limitações impostas pela framework, caso contrário, voltamos a questão do paragrafo acima.
O único ponto que vamos concordar é: se alguém for capaz de roubar o refresh token ele vai conseguir usar sua sessão e multiplicar.
Mas não dá para falar do efeito sem uma explicação do vetor de ataque e quais ações práticas o atacante tem. Dependendo vetor, como um mitm, uma falha em que automatizou o ataque, em muitos cenários tanto um refresh token com proteção de replay ou sem, até mesmo aplicação que usa cookie vai sofrer o ataque igual. E nao querendo ser redundante, se está diante de um cenário que tem tanta necessidade de segurança e controle, utilize um player de mercado.
@@VictorHugo-rj6sy Não usa RT e deixar o usuário logar a cada 1 hora 😂
Ótimo vídeo e ótima explicação, uma dúvida: sempre que chamar a rota de refresh token irá gerar um access token e um refresh token, como o refresh token irá expirar?
Tenho essa mesma dúvida. Tipo, se eu uso um refresh token para conseguir tanto um novo access token quanto um novo refresh token, como que o antigo se torna inválido, sendo que ainda não venceu? Você tem encontrado essa resposta?
O principal fator de segurança do refresh token não é o tempo de expiração, pode ser 1 dia, 1 mês. O que torna o refresh token seguro é o fato dele ser utilizado uma unica vez, como consequencia a chance de um ataque mitm com sucesso é reduzido.
@@Trankiliss então o sistema continua sendo seguro, mesmo se eu trocar um refresh token por um novo access token e um novo refresh token sem tornar o antigo refresh token inválido?
@@pedrofaria7322 Ai buguei pq segundo o comentário do Bruno Brito não kkkkk. Pq o antigo refresh token ainda poderia ser usado mas fiquei nessa dúvida também.
No caso, ao usuario exemplo realizar login, voce entrega pra ele dois tokens, um access token e um refresh token, os dois gerados pelo jwt com payload de email? ai quando o access token expira, você verifica se existe um refresh token e valida ele, se tiver você gera outro access token e outro refresh token usando a mesma abordagem anterior e assim vai? é isso?
Sendo que os dois (access e refresh) tem o mesmo TokenValidationParameters. Nesse caso se usar o access no lugar do refresh (ou ao contrário) irá funcionar né? porq seria um problema o usuário ficar fazendo a requisição com refreshtoken (que pode ter muitos dias, e até meses, de validade). Qual seria a forma mais correta de corrigir isso?
Chaves de criptografia diferente, amigo. Seus serviços que apenas validam access token com uma public key, não vai conseguir validar um refresh token, pq ambos foram gerados com chaves privadas diferentes
Cara, uma dúvida que estou tendo e não vejo ninguém falar, é sobre o momento ideal para gerar o novo token a partir do refresh token. Imagine que na hora que estou enviando algum formulário o token está expirado. Eu preciso adicionar capacidade de gerar novo token e reenviar a requisição atual em todas as funções de requisição do meu front? Ou tem alguma prática melhor pra isso?
Nesse caso você precisa criar uma fila de requisições que falharam e depois que conseguir atualizar o token chamar essa fila.
Vídeo top.
Meu nível como Dev subiu bastante com cursos de vocês.
Wow muito obrigado!
Que esse microfone ajude a ensinar muitos devs por ai ;)
mds como eu apanhei para aprender token e refresh token kkkkkkkk vc me ajudou muito professor thanks
Excelente explicação! Muito bom! Parabéns!
Obrigado. Consegui entender .
Legal mano agora eu consegui entender direitinho, muito obrigado pela aula esse conteúdo vale ouro.
Tava com saudades mesmos, seu vídeos são sempre excelentes, e o visual do cenário ficou top. Parabéns!
conteúdo top
Show de bola!
A única coisa que me vem em mente agora seria sobre como invalidar refresh tokens já utilizados. Não seria uma falha de segurança? Até porque nesse exemplo eles seriam validos por 30 dias.
Obrigado pelo conteúdo!
Olá Fredi, vc tem razão, não abordei esse cenário. Atualmente existem dois tipos de abordagens para refresh token, One Time Use e ReUse. Acredito que a melhor forma de visualizar um RT ReUse é comparar ao Cookie emitido por um site que tem um tempo de 60 / 90 dias de vida. Definitivamente One Time Use vc precisa de uma persistencia.
Apenas complementando. Vc pode utilizar a estratégia de One Time Use através de uma claim no usuario, evitando criar uma estrutura de controle para isso.
@@Trankiliss ainda assim seria meio complicado fazer a checagem, se vazar como saber quem fez o uso e gerou um novo é o próprio usuário?
Nesse caso você pode criar uma BlackList de refresh tokens. Depois de você utilizá-lo no refresh, você salva ele no REDIS e verifica se ele tá Blacklist antes de fazer o refresh, caso esteja lá, da um erro genérico para o usuário.
Já implementei essa estratégia em cliente que necessitava de um "botão de emergência" para invalidar token. Como o acess_token era só de 1 minuto, então não precisou, só implementamos no refresh mesmo, mas se precisar, faz para o access também.
@@lucasreinaldo1063 A conta entre ter muito controle sobre os tokens e a facilidade de implementação é uma equação que nunca fecha. Os riscos de um Refresh Token vazado e um Cookie vazado são praticamente os mesmos. A abordagem de manter a sessão, mitigar o problema do JWT e garantir a facilidade de implementação atende aos princípios do Refresh Token. No entanto, se um Refresh Token for vazado, o dano pode ser tão ruim quanto o vazamento de um Cookie de sessão.
Canal top, conheci hoje
Parabéns !!
Daria pra forçar uma única vez o uso do refresh token sem salvar no banco?
Essa é minha dúvida, pois uma vez utilizado ele deve expirar imediatamente e ser gerado um novo.
Sem contar que hoje em dia já existem empresas que oferecem esse serviço de "barramento", como por exemplo o da Sensedia, que já fazem todo esse controle e gerenciamento de Token para as APIs da empresa que trabalhamos.
Mas se você não armazena o token no banco não perde a capacidade de bloquear o token em vez do usuário? Suponha que um refresh token tenha vazado ai você vai e bloqueia o usuário enquanto ele não faz login novamente. Nesse intervalo quem roubou o refresh token vai ficar impossibilitado de fazer qualquer coisa porém se o usuário faz login de novo ele é desbloqueado e se o token roubado ainda estiver dentro da validade ele volta a funcionar para obtenção de access token.
Perfeito, Renato. Li vários comentários e o seu foi um dos maiores dentre os vários problemas dessa abordagem do vídeo.
Se o seu banco de dados vazou você já está lascado, mas eu conheço duas formas de invalidar os tokens sem precisar armazenar os tokens válidos:
1.criar uma blacklist apenas dos tokens inválidos (que não expiraram ainda. Por exemplo: você gerou um novo refresh token antes do antigo expirar, então, armazena o ANTIGO na blacklist).
2.Trocar o segredo no servidor (todos os tokens com segredo antigo se tornam inválidos).
Acredito que se seu banco vazou, todos os usuários teriam que fazer a recuperação de conta e gerar uma senha e token novos, então, trocar o segredo poderia ser o caminho.
Renato, os vetores de ataque para um Refresh Token vazado são semelhantes aos de um Cookie vazado, nem por isso o Cookie é armazenado no banco de dados. Existem dois tipos de Refresh Token: one-time use (que você está se referindo) e reutilizável. Ambos têm seus próprios casos de uso e são suportados por muitos provedores de OAuth2. Se você deseja ter mais controle sobre seus tokens, pode considerar repensar seu sistema de autenticação e mudar para um provedor OAuth2, que oferece mecanismos e recursos de segurança adicionais. O video aborda o caso de reuso do refresh token que atende ao seu principio: Mitigar os vetores de ataque e facilitar a implementação.
Perfeito,@@wesleybarbosasilva5891, poderia nos ajudar a melhorar e dizer quais foram os vários outros problemas? Obrigado.
Boa.
Valeu
Pra quem quer ir direto ao ponto: ruclips.net/video/t5iumvSNbgM/видео.html
boa pai
1:13 update sem delete
"Update sem delete" shduhsua
"Update sem delete", rs...
Opsss...
update sem delete, seria um novo comando SQL, ruclips.net/video/t5iumvSNbgM/видео.html