Continuação sobre Dúvidas ao Token de Acess

Olá Cauã! Como vai?

Fico feliz em ver seu interesse em entender mais sobre segurança de tokens de acesso. Vamos por partes:

1. Local Storage vs. Session Storage: Em termos de segurança, tanto o localStorage quanto o sessionStorage são vulneráveis a ataques XSS (Cross-Site Scripting). Por isso, não é recomendado armazenar tokens de acesso neles. Uma prática mais segura é utilizar cookies com a flag HttpOnly, pois eles não são acessíveis via JavaScript e, portanto, são menos suscetíveis a ataques XSS.

2. Risco de Armazenamento em Local Storage: Como você mencionou, se um invasor conseguir executar um script malicioso na sua aplicação, ele pode acessar o localStorage ou sessionStorage e roubar o token. Isso permitiria que ele fizesse requisições autenticadas em nome do usuário, potencialmente acessando dados sensíveis ou realizando ações não autorizadas.

3. O que um invasor pode fazer com o token: Com um token de acesso, um invasor pode fazer requisições à API como se fosse o usuário legítimo. Isso pode incluir acessar dados pessoais, modificar informações ou realizar transações. É por isso que a proteção desses tokens é crucial.

4. Boas práticas de segurança:

   • Utilize cookies seguros: Configure seus cookies com as flags HttpOnly e Secure para mitigar ataques XSS e garantir que eles sejam enviados apenas em conexões HTTPS.
   • Implementar Content Security Policy (CSP): Isso ajuda a mitigar ataques XSS ao restringir quais fontes de scripts podem ser executadas na sua página.
   • Renovação de Tokens: Utilize tokens de curta duração e implemente um mecanismo de renovação seguro, como um refresh token armazenado de forma segura.
   • Monitoramento e Logs: Mantenha um sistema de monitoramento para detectar atividades suspeitas e revise logs regularmente para identificar possíveis brechas de segurança.

Espero ter ajudado e bons estudos!

então a melhor forma seria:

• armazenar token de acesso e o refresh em http only ?
• meio estranho porque nesse caso não iria usar bearer ou header
• programadores usam tudo http only ? não entendi

Opa, Cauã!

A melhor maneira, pensando em segurança, sim, é a utilização de token de acesso com o refresh em Http Only. E sim, nesse caso não haveria necessidade de usar o Bearer token sendo passado no header, pois durante a autenticação do usuário você criaria um token que será chamado toda vez que ser necessária a autenticação.

Agora sobre os programadores usarem tudo Http Only, não. Normalmente não é por norma utilizar apenas o Http Only ou a autenticação com o Bearer Token, depende muito do que será feito, como será feito e com quais tecnologias serão feitas.

Pegando como exemplo, se tivermos fazendo um projeto FullStack em Django, onde todo acesso ao banco e autenticação acontece no mesmo ambiente onde estabelece uma página Web, o melhor seria criar um Token de acesso tendo o Http Only, pois, diminuiria o retrabalho que seria receber o Bearer Token do mesmo serviço para autenticar a página ser acessada ou recurso.

Outro exemplo, onde eu faço um projeto Backend em Spring Boot/Java e Frontend em Angular, o recomendado, geralmente, é utilizar o Bearer Token. Pois, quando a rota do Backend for consumida pelo Frontend ele poderá trabalhar com mais liberdade dessa forma, podendo estabelecer a segurança personalizada.

Resumindo, cada caso é um caso, não existe uma lei geral para todas as coisas na programação, entenda o que o projeto seu pede e tente ajustar as formas de segurança e autenticação para esse caso.

Espero ter ajudado e fico a disposição!

Então se eu fizesse um projeto Spring Boot + Js puro seria de um jeito, e Spring Boot + Angular ou React seria de outro jeito ?? Qual jeito seria melhor para cada abordagem ?

Oi, Cauã!

Sim, a escolha da abordagem de autenticação muda conforme o tipo de aplicação — principalmente quando falamos de projetos FullStack versus aplicações desacopladas (Frontend separado do Backend).

No caso do Spring "Boot + JS puro" ele seria igual ao "Spring Boot + alguma framework" a aplicação acoplada que temos no Spring é usando o Thymeleaf para renderização de páginas HTML, sendo assim um projeto FullStack. Nesse caso, é melhor usar cookies com HttpOnly para armazenar o token. Nesse cenário, como tudo roda sob o mesmo domínio, é seguro e prático deixar o navegador enviar o token automaticamente via cookie a cada requisição.

• Vantagens: Mais seguro contra XSS (JavaScript não consegue acessar o token).
• Desvantagens: Mais difícil de lidar com CORS se o frontend estiver em outro domínio (o que não é seu caso com JS puro).

Spring Boot + Angular ou React (SPA com Frontend separado). Mais comum usar Bearer Token no header e armazenar em memória ou em localStorage (com cuidados). O que dar mais controle ao Frontend para lidar com autenticação e renovação do token.

• Vantagens: Mais flexível. Ideal para SPAs. Permite lidar com múltiplos backends.
• Desvantagens: Exige cuidado extra com segurança (ex: proteger contra XSS e CSRF).

Dica final para evoluir na carreira: estude sobre CORS, CSRF, XSS, JWT, e OAuth2. Esses são temas essenciais no dia a dia de quem trabalha com autenticação moderna.

Fico à disposição.