- OAuth 2.0 com google
- Token e Jwt
- Tipos de criprtografia
O que é:
OAuth 2.0 é um protocolo padrão para autenticação e autorização.
Ele permite que usuários concedam acesso limitado aos seus dados em um serviço (como um servidor ou API) sem precisar compartilhar a senha.
Como funciona:
- O usuário tenta acessar um recurso protegido.
- O servidor de autorização emite um token de acesso.
- O cliente usa esse token para acessar os recursos em nome do usuário.
Exemplo de uso:
APIs REST que exigem login com autenticação via token.
Características:
- 🔒 Usa access tokens em vez de credenciais diretas.
- 🧩 Permite controle granular de permissões (escopos).
- ⚙️ Amplamente suportado em aplicações web e mobile.
O que é:
É a implementação do OAuth 2.0 usando o provedor do Google como servidor de autenticação.
O usuário faz login com sua conta Google, e o Spring Security cuida de todo o fluxo de autenticação.
Como funciona no Spring:
- O usuário clica em “Login com Google”.
- O Spring redireciona para o Google para autenticação.
- Após o login, o Google retorna um token e informações do perfil.
- O Spring cria uma sessão autenticada automaticamente.
Características:
- 🚀 Implementação simples com
spring-boot-starter-oauth2-client. - 🔐 O Spring gerencia tokens e dados do usuário.
- ✅ Ideal para login social rápido e seguro.
| Tipo | Função Principal | Autenticação Externa | Exemplo de Uso |
|---|---|---|---|
| OAuth 2.0 | Autenticação genérica via token | ❌ Não obrigatória | APIs e microserviços |
| OAuth 2.0 com Google | Login social via Google | ✅ Sim (Google) | Login com conta Google |
Um token é uma credencial de acesso que representa a autorização para acessar recursos protegidos. É uma string que prova a identidade do usuário sem precisar enviar suas credenciais (usuário e senha) a cada requisição.
São strings aleatórias sem significado aparente que precisam ser armazenadas no servidor (banco de dados ou cache). Para validar um token opaco, o servidor precisa consultar onde ele está armazenado.
a8f5f167f44f4964e6c998dee827110c
São tokens auto-contidos que carregam informações dentro deles. Não precisam ser armazenados no servidor e podem ser validados apenas verificando a assinatura.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
JWT (JSON Web Token) é um padrão aberto (RFC 7519) que define uma maneira compacta e autocontida de transmitir informações entre partes como um objeto JSON de forma segura. O token é assinado digitalmente, o que garante sua integridade e autenticidade.
- Auto-contido: Contém todas as informações necessárias sobre o usuário
- Compacto: Pode ser enviado via URL, POST parameter ou HTTP Header
- Assinado: Garante que não foi alterado durante a transmissão
- Stateless: O servidor não precisa armazenar sessão ou estado
Um JWT é composto por três partes separadas por pontos (.):
HEADER.PAYLOAD.SIGNATURE
Contém o tipo do token e o algoritmo de criptografia usado para assinar o token.
{
"alg": "HS256",
"typ": "JWT"
}Esta parte é codificada em Base64URL.
Contém as claims (declarações) - informações sobre o usuário e metadados do token.
{
"sub": "1234567890",
"name": "João Silva",
"email": "joao@example.com",
"role": "ADMIN",
"iat": 1516239022,
"exp": 1516242622
}Esta parte também é codificada em Base64URL.
- iss (Issuer): Emissor do token
- sub (Subject): Identificador do usuário
- aud (Audience): Destinatário do token
- exp (Expiration Time): Data de expiração do token
- iat (Issued At): Data de emissão do token
- nbf (Not Before): Token não é válido antes desta data
- jti (JWT ID): Identificador único do token
Garante que o token não foi alterado. É criada combinando o header e payload codificados com uma chave secreta usando o algoritmo especificado no header.
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)
- Login: O usuário envia suas credenciais (usuário e senha) para o servidor
- Validação: O servidor valida as credenciais no banco de dados
- Geração: Se válido, o servidor gera um JWT contendo informações do usuário
- Retorno: O servidor retorna o JWT para o cliente
- Armazenamento: O cliente armazena o JWT (localStorage, sessionStorage ou cookie)
- Envio: Em cada requisição subsequente, o cliente envia o JWT no header
Authorization - Validação: O servidor valida o JWT verificando a assinatura
- Autorização: Se válido, o servidor processa a requisição e retorna a resposta
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
- Stateless: O servidor não precisa armazenar sessões, reduzindo a carga no banco de dados
- Escalabilidade: Fácil de escalar horizontalmente pois não há dependência de sessão
- Cross-domain: Funciona entre diferentes domínios e origens
- Mobile-friendly: Ideal para aplicações mobile que não suportam cookies facilmente
- Performance: Não requer consultas ao banco de dados para validação
- Descentralizado: Pode ser validado por qualquer serviço que tenha a chave secreta
- Padrão aberto: Amplamente suportado em diferentes linguagens e frameworks
- Tamanho: JWTs são maiores que tokens opacos, especialmente com muitas claims
- Revogação difícil: Uma vez emitido, o token é válido até expirar (não pode ser revogado facilmente)
- Dados expostos: O payload pode ser decodificado por qualquer um (Base64 não é criptografia)
- Secret compartilhado: Todos os serviços precisam compartilhar a mesma chave secreta
- Vulnerável a replay attacks: Se interceptado, o token pode ser reutilizado até expirar
- Sem controle centralizado: Difícil implementar logout global ou controle de dispositivos
Sempre transmita JWTs através de conexões HTTPS para evitar interceptação.
Configure o token para expirar em 15 minutos a 1 hora. Para sessões mais longas, use refresh tokens.
{
"exp": 1516242622,
"iat": 1516239022
}- Recomendados: RS256 (RSA com SHA-256), ES256 (ECDSA)
- Evitar:
none(sem assinatura) - Com cuidado: HS256 (apenas se o secret for extremamente forte)
Nunca exponha a chave secreta no código. Use variáveis de ambiente ou serviços de gerenciamento de secrets.
Nunca coloque senhas, números de cartão de crédito ou outros dados sensíveis no payload. O JWT pode ser decodificado por qualquer pessoa.
{
"sub": "user123",
"role": "ADMIN",
"name": "João"
}Use dois tipos de tokens:
- Access Token: Curta duração (15 minutos) para acesso a recursos
- Refresh Token: Longa duração (7 dias) para renovar o access token
Sempre valide:
- Assinatura do token
- Data de expiração (exp)
- Emissor (iss)
- Audience (aud)
- Tempo de emissão (iat)
Evite armazenar JWTs em localStorage se possível. Use cookies com flags HttpOnly, Secure e SameSite para maior segurança.
Se usar cookies, implemente proteção CSRF adicional:
- Tokens CSRF
- Verificação de headers Origin/Referer
- SameSite cookies
Use sempre HTTPS para evitar que o token seja interceptado durante a transmissão.
Implemente:
- Tokens de curta duração
- Binding do token ao dispositivo/IP
- Rotação de tokens
- Lista negra de tokens comprometidos
- Armazenamento no servidor (memória, banco de dados, Redis)
- Revogação imediata possível
- Menor tamanho (apenas ID da sessão)
- Requer consulta ao banco de dados
- Dificulta escalabilidade horizontal
- Mais controle centralizado
- Armazenamento no cliente
- Revogação difícil (até expirar)
- Maior tamanho (dados completos)
- Sem consulta ao banco de dados
- Facilita escalabilidade horizontal
- Menos controle centralizado
- APIs RESTful stateless
- Aplicações mobile
- Sistemas distribuídos e microserviços
- Single Sign-On (SSO)
- Aplicações com múltiplos domínios
- Sistemas que precisam escalar horizontalmente
- Sistemas que exigem revogação imediata
- Aplicações com dados altamente sensíveis no token
- Sistemas monolíticos simples
- Quando controle centralizado de sessão é crítico
- Aplicações onde o tamanho da requisição é problema
O padrão de refresh token resolve o problema de expiração curta do JWT mantendo a segurança:
-
Usuário faz login e recebe:
- Access Token: Expira em 15 minutos
- Refresh Token: Expira em 7 dias
-
Cliente usa o access token para acessar recursos
-
Quando o access token expira, o cliente envia o refresh token para obter um novo access token
-
Se o refresh token também expirar, o usuário precisa fazer login novamente
- Access tokens de curta duração reduzem janela de exposição
- Refresh tokens podem ser armazenados com mais segurança
- Refresh tokens podem ser revogados no servidor
- Melhor experiência do usuário (menos logins)
- HS256, HS384, HS512
- Usa chave secreta compartilhada
- Mesma chave para assinar e verificar
- Mais rápido
- Todos os serviços precisam da mesma chave
- RS256, RS384, RS512
- Usa par de chaves (pública/privada)
- Chave privada para assinar
- Chave pública para verificar
- Mais seguro para sistemas distribuídos
- Chave pública pode ser compartilhada
- ES256, ES384, ES512
- Usa criptografia de curva elíptica
- Mais eficiente que RSA
- Assinaturas menores
- Crescente adoção
- Estrutura: Verificar se tem 3 partes separadas por pontos
- Decodificação: Decodificar header e payload de Base64URL
- Assinatura: Verificar se a assinatura é válida usando a chave secreta
- Expiração: Verificar se o token não expirou (claim
exp) - Not Before: Verificar se o token já pode ser usado (claim
nbf) - Emissor: Verificar se o emissor é confiável (claim
iss) - Audience: Verificar se o token é para sua aplicação (claim
aud)
Se qualquer etapa falhar, o token deve ser rejeitado e o acesso negado. O servidor deve retornar status 401 (Unauthorized).
- Acessível por JavaScript
- Vulnerável a XSS
- Persiste entre sessões
- Não enviado automaticamente
- Acessível por JavaScript
- Vulnerável a XSS
- Perdido ao fechar aba
- Não enviado automaticamente
- Pode ter flag HttpOnly (não acessível por JavaScript)
- Enviado automaticamente
- Requer proteção CSRF
- Mais seguro se configurado corretamente
Use cookies com as seguintes flags:
HttpOnly: Impede acesso via JavaScriptSecure: Apenas transmitido via HTTPSSameSite=Strict: Proteção contra CSRF
JWT é frequentemente usado como formato de token em implementações OAuth 2.0:
Pode ser um JWT contendo permissões e informações do usuário.
No OpenID Connect (extensão do OAuth 2.0), o ID Token é sempre um JWT contendo informações de identificação do usuário.
Geralmente um token opaco usado exclusivamente para obter novos access tokens.
Quanto mais claims no payload, maior o token. Isso impacta:
- Tamanho da requisição HTTP
- Armazenamento no cliente
- Largura de banda
A validação de JWT é rápida comparada a consultas de banco de dados, mas ainda tem custo:
- Decodificação Base64
- Verificação de assinatura criptográfica
- Parsing do JSON
Em sistemas que usam RSA/ECDSA, fazer cache das chaves públicas melhora significativamente a performance.
Site oficial que permite decodificar, verificar e depurar JWTs. Útil para desenvolvimento e troubleshooting.
- Java: jjwt, java-jwt, nimbus-jose-jwt
- JavaScript/Node: jsonwebtoken, jose
- Python: PyJWT, python-jose
- C#: System.IdentityModel.Tokens.Jwt
- Go: golang-jwt
Nunca logue o JWT completo em produção. Se necessário, logue apenas:
- Identificador do usuário (sub)
- Timestamp de emissão
- Claims não sensíveis
JWT é uma solução poderosa para autenticação e autorização em aplicações modernas, especialmente em arquiteturas distribuídas e APIs RESTful. Sua natureza stateless facilita a escalabilidade, mas requer cuidados especiais com segurança e implementação correta de práticas recomendadas.
A escolha entre JWT e session-based authentication deve considerar os requisitos específicos da aplicação, incluindo necessidades de segurança, escalabilidade, e controle de acesso.
O que é:
A criptografia simétrica utiliza a mesma chave para criptografar e descriptografar os dados.
É rápida e eficiente, ideal para proteger grandes volumes de informação.
Exemplo:
- Algoritmo: AES (Advanced Encryption Standard)
- Uso: sistemas que armazenam ou transmitem dados sensíveis internamente.
Características:
- 🔑 Uma única chave secreta.
- ⚡ Alta performance.
- 🚫 Necessário proteger bem a chave, pois quem a obtiver pode descriptografar os dados.
O que é:
A criptografia assimétrica usa duas chaves diferentes:
- Chave pública: usada para criptografar.
- Chave privada: usada para descriptografar.
Exemplo:
- Algoritmo: RSA (Rivest–Shamir–Adleman)
- Uso: autenticação, troca de chaves, certificados digitais.
Características:
- 🗝️ Par de chaves (pública/privada).
- 🛡️ Aumenta a segurança na troca de informações.
- 🐢 Mais lenta que a simétrica, usada geralmente para proteger pequenas mensagens ou chaves de sessão.
O que é:
O hashing transforma um texto (como uma senha) em uma sequência irreversível de caracteres.
Diferente da criptografia, não é possível descriptografar um hash.
Exemplo:
- Algoritmo: BCrypt
- Uso: armazenamento seguro de senhas em bancos de dados.
Características:
- 🔄 Sempre gera um hash diferente, mesmo para a mesma senha (usa salt aleatório).
- 🧱 Unidirecional — não há como obter o texto original.
- 🧠 Ideal para autenticação segura de usuários.
| Tipo | Pode ser revertido? | Chaves usadas | Exemplo de uso | Desempenho |
|---|---|---|---|---|
| Simétrica (AES) | ✅ Sim | 1 (mesma chave) | Criptografar dados locais | ⚡ Rápido |
| Assimétrica (RSA) | ✅ Sim | 2 (pública/privada) | Troca segura de chaves, API | 🐢 Lento |
| Hash (BCrypt) | 🚫 Não | Nenhuma | Armazenar senhas | ⚡ Rápido (com custo ajustável) |