Devo salvar o acess token no banco de dados ?
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
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.
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.
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.
Na minha opinião salvar tokens no banco de dados não é viável e nem faz sentido.
A primeria perguntar que eu faria é, por que?
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.
Procure soluções prontas
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.
Autenticação tende a complexar com o tempo
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..