O que é e como funciona um Refresh Token?

Sempre que usamos autenticação via tokens, uma boa prática é utilizarmos um tempo de expiração baixo. Com isso vem a necessidade da renovação desse token e uma das técnicas para isso é a utilização de Refresh Token. Nesse vídeo, eu falo sobre o que é e como funciona a dinâmica utilizando Refresh Token.

---------------------------------

Siga-me também nas plataformas:

#JWT #RefreshToken #Autenticação

[HerlonCosta]

Cara, é de longe a explicação mais clara que eu já vi sobre o assunto.

[ThiagoPablicio]

Foi um dos vídeos mais curtos, porém mais esclarecedores sobre o assunto, muito obrigado!

[henriqueyun]

Cara, o vídeo realmente foi muito didático e completinho pra entender o básico da dinâmica de uso de refresh tokens. Maso que mais me elucidou realmente foram as dúvidas nos comentários e suas respostas, que me ajudaram a pensar e compreender como esse tema é mais aberto do que parece (sem lá ele).

[ErivandoAndrade]

Curto, direto e didático. Entendi o que estava procurando. Muito obrigado!

[rafaelferreira]

Parabéns pelo video amigo. Dos videos que encontrei no youtube o seu foi o unico que nao teve enrrolacao e ficou extremamente claro o funcionamento.

Muito obrigado

[ltbatis]

Ótimo vídeo para entender o conceito/técnica.

[pedrocamaforte]

Ótimo vídeo! Parabéns!
Uma dúvida: Como a aplicação teria uma referência sobre qual é o JWT referente àquele access token? Já vi duas abordagens diferentes: salvar, como você disse, em um banco de dados, e colocar a referência dentro do próprio JWT, para saber qual token é de quem. Porém, se o token for sequestrado, um usuário poderia muito bem se passar por algum outro usando seu token, e este seria renovado automaticamente pelo refresh token, já que as informações necessárias para renová-lo estão dentro do próprio JWT, não é? Então como essa implementação seria feita de maneira segura?
A outra abordagem, é salvar o refresh token no próprio navegador do usuário, juntamente com o access token, e enviá-lo nas requisições para atualizar o access token quando necessário. Porém, da mesma forma que um JWT está vulnerável a ataques de XSS, por exemplo, o refresh token também estaria. Dessa forma, se ambos access token e refresh token forem roubados e enviados na requisição, um usuário malicioso teria acesso constante à conta do usuário alvo.

Esse meu pensamento procede? Tem algo que estou deixando passar? Estou a bastante tempo estudando sobre refresh token, e ainda não encontrei nada que respondesse a essas questões. Você teria alguma ideia para me ajudar?

[victorferreira]

bom, eu acho que a pergunta mais profunda é a seguinte:

Se um token de acesso é valido por 1 hora e um refresh token por 1 mes,

Porque esse esquema é mais seguro do que fazer o Token ser válido por 1 mês, já que o RT também pode vazar e nesse caso o invasor teria acesso a API indeterminadamente (já que ele sempre recebe um novo RT token quando pede um novo token de acesso) ?

[matheusdiniz]

Poderia explicar a parte de logout? Como eu posso invalidar um token, para que após o logout, o token fique inválido para acessar a API.

Parabéns pelo vídeo! Obrigado por compartilhar conhecimento.

[mutv]

Eu posso imbutir o refresh token dentro do jwt? o front-end deserializa o jwt e pode recuperar o refresh token para usa-lo, depois que é gerado um novo token ele invalida o token antigo.

[jonathanemanuel]

Se tanto um token jwt quanto um refresh token me dão acesso ao sistema, por que o primeiro deve ter um tempo de expiração curto e o segundo longo?
Não seria mais simples retirar o segundo e aumentar o tempo de expiração do primeiro?
Estou pesquisando, mas ainda não entendi a necessidade do refresh token

[gabrielmariano]

A chamada do refresh token pode ser colocado em algum middleware?

[lucasdechenier]

Eu simplesmente não entendo o ganho dessa abordagem, pq simplesmente se minha aplicação antes era uma falha ter um access_token de longa duração, ele ser roubado geraria uma falha de segurança, agora da mesma forma um refresh_token ao ser roubado também gera outra, uma vez que o usuário malicioso através do refresh_token pode gerar um access_token válido. Não consigo entender o ganho dessa abordagem