Emita e use tokens de API com segurança

O modelo mental: o token é uma senha que você nunca guarda

Um token de API é uma credencial bearer (portador): quem o possui é o
chamador. Isso o torna tão sensível quanto uma senha — e você deve tratá-lo
como tal. A regra mais importante deste playbook é:

Nunca guarde o token em texto puro. Guarde só o digest (um hash
SHA-256). O texto puro existe por um instante — no momento da emissão —
onde você o mostra uma vez e depois o esquece. Ele nunca é logado e nunca
pode ser re-exibido.

Por que um digest e não o token cru? Se o seu banco vazar, um atacante com os
tokens crus consegue chamar sua API na hora. Com apenas digests, ele tem
hashes que não podem ser revertidos em tokens funcionais. É o mesmo raciocínio
por trás de fazer hash de senhas — um token é apenas a senha de uma máquina.

Um bom token tem um prefixo reconhecível para ser fácil de identificar em
logs, scanners de segredo e tickets de suporte, seguido de entropia aleatória
suficiente para ser impossível de adivinhar:

dare_9f2c1a7b4e08d3...   ← prefixo "dare_" + hex aleatório longo
└──┘ └──────────────┘
tag       segredo

O ciclo de vida que você vai construir aqui:

emitir   → mostrar o texto puro UMA vez, guardar só o digest
usar     → cliente envia Authorization: Bearer <token>
           servidor faz o hash, busca a chave ativa pelo digest
authz    → autenticar (quem?) E autorizar (pode?) → 401 vs 403
revogar  → setar revoked_at; authenticate() retorna nil para sempre depois

Este playbook é concept-first e stack-agnóstico. Os exemplos usam
pseudocódigo e HTTP; traduza-os para a biblioteca de hash, o ORM e o
framework web da sua linguagem.