Estava fazendo algumas pesquisas e me deparei com essa dúvida. Vi em algum lugar (GPT) que o accessToken é stateless e não precisa ser salvo no banco de dados, diferente do refreshToken, que dura mais e precisa ser salvo no banco de dados. Se alguém puder me ajudar, eu agradeço muito!
estou fazendo um projeto meu mesmo comunicação front & back. nodejs
Olá, sempre vejo os métodos de autenticacão sendo implementados de uma foma não padronizada e isso é bem ok. A necessidade de cada produto ou empresa é diferente. Mas recentemente tenho visto aumento do uso do Keycloack. É um serviço que cuida dessa parte pra você. Ah, dica, não amrmazena token no banco, e de preferência tenha um cache só pra isso.
Dá um olhada no keycloak
Uma característica importante dos tokens, sejam eles os accessToken ou refreshToken é que eles tem vida útil, isto é, eles expiram, no caso do refreshtoken o tempo de expiração é maior.
Por ambos terem a característica de ter uma vida útil, eu acredito que eles podem ser salvos em um banco de dados em memória, como o Redis, dessa forma o próprio Redis se encarrega de expirar os tokens quando necessário. Ainda possui a vantagem de ser mais rápido que um banco persistente e usa-lo vai diminuir a carga de trabalho do seu banco principal.
Poderia dar mais contexto?
Se a aplicação é cliente de um serviço externo eu geralmente salvo no DB.
Se é comunicação do front com o back não salvo.
A comunicação é entre o front e o back, sendo mais específico em uma SPA. Meu amigo diz que é bom salvar o accessToken no banco de dados, porém, nas minhas pesquisas, só é necessário salvar o refreshToken, utilizando apenas o verify do JWT no accessToken por ser StateLess. Estou usando Node.js.
só to com problemas de achar informações relacionadas ou não sei a palavra chave.
Eu mesmo estou desenvolvendo tudo.
Na minha opinião salvar tokens no banco de dados não é viável e nem faz sentido.
Na verdade, para a maior parte dos sistemas os jsonwebtokens ou equivalentes (até mesmo um SWT) atendem perfeitamente.
Isso porque a validação do token não ocorre durante uma varredura de uma lista (com checagem de um para um), mas sim através de um algorítimo específico.
Isso é extremamente importante para poupar tráfego e processamento em um banco de dados, mesmo que ainda fosse um Redis você ainda precisaria o gerenciar e acredite em mim, menos serviços é mais.
Contudo, com o algorítimo você delega essa função para o próprio server que processará as requests. Isso é mais interessante financeiramente falando e ainda promove que sua aplicação seja stateless, ou seja, você pode ter mais de uma instância em paralelo facilitando a escalabilidade, lembre-se "facilitando", não que isso determine que seu sistema seja escalável.
Construir autenticações não deveria ser sua prioridade, você precisaria estudar muito sobre segurança e ainda falharia em algo. Procure bibliotecas prontas, ou até mesmo soluções prontas, mas ao contratar um serviço externo considere aquilo que mencionei no primeiro item, menos serviços é mais.
Somente validar que o usuário está autenticado é algo simples mas esta tarefa pode e deve complexar na medida que o sistema cresça, incluindo as famigeradas roles e tudo o que envolve níveis de acesso, ai você adentrará no que constitui o payload do token e por ai vai...
Aliás, é no payload de um JWT que você obtém a informação de qual usuário está logado, informações específicas do login e etc..
Creio que não seja uma boa prática armazenar o accessToken no banco de dados, pois já existem tokens que você pode armazenar localmente que já armazenam a autenticação do usuário. Salvar token como refresh ou access pode não ser totalmente seguro.