Auth não é uma decisão de biblioteca

A primeira pergunta que recebo em um projeto novo costuma ser 'qual biblioteca de auth a gente usa?'. É a primeira pergunta errada. A biblioteca é a última decisão, e quando você chegar nela, a maioria das escolhas importantes já deveria estar escrita.

Autenticação é um conjunto de compromissos arquiteturais sobre identidade, sessões, revogação e fronteiras. Uma biblioteca implementa esses compromissos. Ela não pode assumi-los por você, e todo incidente de auth que investiguei veio de um compromisso que ninguém assumiu.

De quem é a identidade

Decida se o seu sistema é a fonte da verdade para usuários ou um consumidor da fonte de outra pessoa. Se você é o dono, você é dono do armazenamento de senhas, dos fluxos de reset, da verificação de email e da recuperação de conta, e cada um desses é um lugar onde já encontrei vulnerabilidades críticas. Se um provedor de identidade é o dono, você é dono do mapeamento entre o subject id dele e o seu registro de usuário, e o modo de falha passa a ser o que acontece quando esse mapeamento está errado ou quando o provedor está fora.

Nenhum dos dois é errado. Ambos são decisões com consequências que duram mais que a biblioteca. Um produto que começa em um provedor hospedado e depois precisa migrar vai descobrir que seus ids de usuário, seu formato de sessão e suas regras de autorização foram todos moldados por aquele provedor.

Onde a sessão vive

Há duas opções honestas. Uma sessão com estado, guardada em banco ou cache e referenciada por um cookie opaco, pode ser revogada na hora e inspecionada à vontade, ao custo de uma consulta a cada requisição. Um token sem estado, assinado e carregado pelo cliente, custa nada para verificar e não pode ser revogado até expirar.

A maioria dos times escolhe sem estado porque é fácil, e depois descobre que não consegue deslogar um usuário pelo servidor, não consegue invalidar sessões depois de uma troca de senha e não consegue ver quem está logado. O meio-termo comum é access token de vida curta com refresh token guardado no servidor, para que a revogação faça efeito em minutos em vez de nunca. Tudo bem, desde que você decida isso em vez de herdar.

O cookie em si tem regras que não dependem de biblioteca nenhuma: HttpOnly para scripts não lerem, Secure para nunca viajar em texto claro, SameSite definido de propósito e um escopo que bate com seus domínios. Confiro esses quatro atributos nos primeiros dez minutos de qualquer revisão de segurança, e um deles está errado na maioria das vezes.

Onde a checagem acontece

No Next.js, a tentação é autenticar uma vez na camada de middleware e confiar que tudo atrás dela está protegido. Essa camada é boa para decisões baratas: redirecionar um usuário anônimo, rejeitar uma requisição sem cookie nenhum. Não é o lugar para autorização, porque roda antes de os dados serem carregados e não sabe o que o usuário está tentando tocar.

A checagem de verdade fica ao lado dos dados. Todo Server Component que renderiza dado privado, toda Server Action que o modifica, todo route handler, lê a sessão e verifica que este usuário pode acessar este recurso. Não só que está logado. Que é dono do pedido que está pedindo. Insecure direct object references são a vulnerabilidade mais comum que encontro em aplicações React modernas, e uma tela de login não faz nada para impedi-las.

Eu centralizo isso em uma pequena camada de acesso a dados: funções que recebem uma sessão e um id, e ou retornam o registro ou lançam erro. Componentes nunca consultam o banco diretamente. Se a checagem está em um lugar, está em todos.

Para que serve a biblioteca

Depois que propriedade da identidade, modelo de sessão, política de cookie e posicionamento da autorização estão escritos, a escolha da biblioteca é pequena. Ela cuida das danças do OAuth, dos formatos de token, dos adaptadores de provedor. Escolha a que bate com as decisões que você já tomou e cujo código-fonte você consegue ler em uma tarde.

Se escolher a biblioteca primeiro, ela vai tomar essas decisões por você, em silêncio, e você vai descobrir quais foram durante o incidente.