Tipos de Token: API Key, JWT, PAT e OAuth
Um token e um pedaco de texto secreto que prova quem voce e para um servico. Em vez de digitar usuario e senha toda vez, voce apresenta o token e a porta abre. Existem varios tipos, cada um para uma situacao. Saber qual usar evita dor de cabeca e mantem tudo mais seguro.
🔑 API Key
Uma chave simples e fixa, tipo sk_live_a1B2c3.... Identifica o aplicativo, nao um usuario. Otima para servicos como envio de email, mapas ou IA. Quando usar: integracao simples maquina-com-maquina.
🎫 JWT
"JSON Web Token". Um token assinado que carrega informacoes (quem e o usuario, ate quando vale) dentro dele mesmo. Tem prazo de validade curto. Quando usar: sessoes de login em apps web e mobile.
👤 PAT
"Personal Access Token". Uma chave pessoal que age em seu nome (ex: token do GitHub para fazer push). Substitui a senha em scripts e ferramentas. Quando usar: automacao no seu nome, como deploy via CI.
🔗 OAuth
Nao e um token unico, e um fluxo. O usuario clica em "Entrar com Google" e autoriza seu app sem nunca te dar a senha. No fim, voce recebe um token de acesso. Quando usar: login social e acesso a dados de terceiros.
🧠 Analogia: As Chaves de um Hotel
Pense num hotel grande:
- •API Key = a chave mestra de servico da copa: abre tudo daquele setor, sempre a mesma.
- •JWT = o cartao magnetico do quarto: vale so por uns dias e depois para de funcionar.
- •PAT = a chave do seu armario pessoal: e sua, age por voce.
- •OAuth = o manobrista: voce da a chave do carro por um instante e ele estaciona, sem virar dono do carro.
Guardando Tokens no Servidor com Seguranca
Ter o token e so metade do trabalho. A outra metade e onde guardar. A regra de ouro: token nunca fica escrito no codigo. Ele vai para um arquivo separado, o .env, que so o servidor le e que o Git ignora.
O arquivo .env
Um arquivo de texto simples, no formato CHAVE=valor, uma por linha:
# Criar e editar o arquivo no servidor
$ nano .env
# Dentro dele, suas chaves:
DATABASE_URL=postgres://user:senha@host/db
API_KEY=sk_live_a1B2c3d4e5
JWT_SECRET=um-segredo-bem-longo-e-aleatorio
Trancando o arquivo: chmod 600
Por padrao, outros usuarios do servidor podem ler seus arquivos. O comando chmod 600 diz: "so o dono pode ler e escrever, mais ninguem".
# Ver as permissoes atuais
$ ls -l .env
-rw-r--r-- 1 deploy deploy 180 jun 16 10:00 .env
# Restringir: so o dono le e escreve
$ chmod 600 .env
$ ls -l .env
-rw------- 1 deploy deploy 180 jun 16 10:00 .env
👁 O que voce vai ver na tela
Leia as letrinhas do ls -l. As primeiras 10 contam quem pode mexer no arquivo:
-rw------- (depois do chmod 600)
# rw- = dono pode ler e escrever
# --- = grupo nao pode nada
# --- = outros nao podem nada
Se ainda aparecer -rw-r--r--, qualquer um no servidor consegue ler. Rode o chmod.
⚠️ Erro Comum
Problema: "Subi meu projeto pro GitHub e o token apareceu publico."
Solucao: O .env foi para o repositorio porque nao estava no .gitignore. Adicione a linha .env ao .gitignore ANTES do primeiro commit. Se ja vazou, considere o token comprometido: revogue e gere outro (ver topico 3). Apagar o arquivo nao basta, ele continua no historico.
Rotacao e Expiracao: Trocar Antes do Problema
Um token que nunca muda e uma bomba-relogio. Quanto mais tempo ele vive, mais chances de vazar (num log, num print, num backup velho). Rotacionar e gerar uma chave nova de tempos em tempos e descartar a antiga. Expiracao e o token morrer sozinho depois de um prazo.
🧠 Analogia: Trocar a Fechadura
Quando voce perde uma chave de casa, voce nao reza para ninguem achar: voce troca a fechadura. Rotacionar token e a mesma ideia, so que feito de forma preventiva, de tempos em tempos, mesmo sem ter certeza de que vazou. Assim, se um dia uma copia da chave antiga aparecer por ai, ela ja nao abre mais nada.
O ciclo da rotacao, passo a passo
Gere a chave nova
No painel do servico, crie um novo token. Nao apague o antigo ainda.
Atualize o servidor
Troque o valor no .env e reinicie a aplicacao.
$ nano .env
# Troque API_KEY pelo valor novo, salve
$ systemctl restart minha-app
Confirme que funciona
Teste o app com a chave nova. So avance se estiver tudo certo.
Revogue a chave antiga
Agora sim, apague o token velho no painel. A fechadura velha deixou de abrir.
⚠️ Erro Comum
Problema: "Revoguei o token antigo e o site caiu."
Solucao: Voce revogou antes de confirmar que a chave nova estava funcionando. Sempre siga a ordem: gera nova, atualiza, testa, e SO ENTAO revoga a antiga. Manter as duas validas por um curto periodo evita derrubar o servico no meio da troca.
✓ O que FAZER
- ✓Definir um prazo (ex: trocar a cada 90 dias)
- ✓Revogar na hora qualquer token que vazou
- ✓Preferir tokens com expiracao automatica
✗ O que NAO fazer
- ✗Usar a mesma chave por anos sem trocar
- ✗Ignorar um vazamento "porque parece pequeno"
- ✗Revogar o antigo antes de testar o novo
Secrets Managers: O Cofre Profissional
O .env resolve bem para um servidor. Mas quando voce tem varios servidores, varias pessoas no time e dezenas de segredos, copiar arquivos a mao vira um pesadelo. E ai que entram os secrets managers: programas dedicados a guardar e entregar segredos com seguranca.
👁 O que voce vai ver na tela
Em vez de abrir um arquivo, voce pede o segredo por comando, e ele vem na hora (e fica registrado quem pediu):
# Exemplo com Vault
$ vault kv get secret/minha-app
==== Data ====
API_KEY sk_live_a1B2c3d4e5
# Exemplo com Doppler
$ doppler secrets get API_KEY --plain
sk_live_a1B2c3d4e5
🛡 Vault (HashiCorp)
Cofre robusto e open source. Guarda segredos, controla quem acessa cada um e pode ate gerar credenciais temporarias que expiram sozinhas. Mais poderoso, exige mais configuracao.
📦 Doppler
Servico mais simples e amigavel. Voce centraliza os segredos num painel e ele injeta nos seus apps e ambientes. Otimo ponto de partida para times pequenos.
🧠 Analogia: O Cofre do Banco
Guardar dinheiro debaixo do colchao (o .env solto) funciona ate certo ponto. Um secrets manager e o cofre do banco: um lugar so, com porta blindada, que registra cada vez que alguem abre e pode ate ter chaves que so funcionam por um dia. Voce nao guarda o segredo de verdade na sua maquina, voce pede ao cofre quando precisa.
💡 Dica: Comece simples
Para um projeto pessoal num so VPS, o .env com chmod 600 ja e muito bom. So adote um secrets manager quando a dor aparecer: muitos ambientes, muita gente, ou segredos demais para controlar a mao. Ferramenta certa para o tamanho certo.
Auditoria: Quem Usou o Que, e Quando
De nada adianta trancar tudo se voce nao consegue ver o que aconteceu. Auditoria de acesso e manter um registro (log) de cada uso: qual token, qual acao, de onde, em que horario. Quando algo der errado, esses logs sao a sua camera de seguranca.
Lendo um log de acesso
Cada linha conta uma historia: quem, quando, o que e o resultado.
# Ver os ultimos acessos registrados
$ tail -n 5 /var/log/minha-app/access.log
10:01 token=deploy acao=push ip=200.1.1.5 ok
10:04 token=backup acao=read ip=200.1.1.5 ok
10:09 token=deploy acao=delete ip=45.9.9.9 ok
10:12 token=deploy acao=delete ip=45.9.9.9 FALHA
Repare na linha 3: o token deploy apagou algo de um IP estranho (45.9.9.9). Sinal de alerta.
👁 O que voce vai ver na tela
Para investigar um token especifico, filtre o log. O grep mostra so as linhas que interessam:
$ grep "token=deploy" access.log
10:01 token=deploy acao=push ip=200.1.1.5 ok
10:09 token=deploy acao=delete ip=45.9.9.9 ok
# Filtrar so as falhas
$ grep "FALHA" access.log
10:12 token=deploy acao=delete ip=45.9.9.9 FALHA
🧠 Analogia: O Livro de Visitas do Predio
Um predio bem cuidado tem porteiro e livro de registro: nome, horario de entrada e saida de cada visitante. Se sumir algo, voce consulta o livro e descobre quem passou. O log de acesso e esse livro de visitas dos seus tokens. Sem ele, voce so descobre que foi roubado, nunca por quem.
💡 Dica: Nunca registre o segredo em si
No log, anote o nome do token (ex: token=deploy), nunca o valor completo. Se voce escrever a chave inteira no log, o proprio registro de seguranca vira um vazamento. Logs costumam ser lidos por muita gente.
Boas Praticas: Menor Privilegio e Um Token por Servico
Reunindo tudo, duas regras carregam o resto nas costas: menor privilegio (cada token so pode o minimo que precisa) e um token por servico (nunca compartilhe a mesma chave entre coisas diferentes). Seguindo isso, um vazamento vira um arranhao, nao uma catastrofe.
🧠 Analogia: O Molho de Chaves do Zelador
Imagine um predio onde uma unica chave abre TODAS as portas: apartamentos, cofre, garagem. Se ela cair na rua, acabou. Um predio bem gerido da a cada pessoa so a chave da SUA porta. Perdeu uma? Troca so aquela fechadura. Tokens funcionam igual: um por servico, cada um com o minimo de poder.
✓ O que FAZER
- ✓Um token para cada servico (deploy, backup, monitor)
- ✓Dar so a permissao necessaria (leitura, se nao precisa escrever)
- ✓Nomear o token de forma clara (token-backup-diario)
- ✓Revogar tokens de quem saiu do time na hora
✗ O que NAO fazer
- ✗Uma chave "admin total" usada por tudo
- ✗Mandar token por WhatsApp ou email sem cuidado
- ✗Deixar tokens de ex-funcionarios ainda ativos
- ✗Colar token direto no codigo "so para testar rapido"
Exemplo: separando por servico no .env
# Cada servico, sua propria chave com seu nome
DEPLOY_TOKEN=ghp_xxxxx # so faz push, nada mais
BACKUP_TOKEN=bk_yyyyy # so leitura do banco
EMAIL_API_KEY=re_zzzzz # so envia email
# Se EMAIL_API_KEY vazar, o deploy e o backup seguem seguros
🏆 Voce chegou ao fim da Trilha 3
Voce contratou um VPS, conectou por SSH, fechou as portas com firewall e agora sabe gerir as chaves dos seus servicos. Voce tem um servidor proprio, seguro e sob controle. Na proxima trilha, voce vai colocar suas aplicacoes para rodar dentro dele de forma organizada, com Docker e automacao.
📚 Resumo do Modulo
Proxima Trilha:
Trilha 4 - Docker & Automacao (empacote e rode suas aplicacoes no servidor de forma organizada)