Autorização Biscuit

Artigo original ↗ Discussão no Hacker News ↗

Biscuit é um novo formato de token de autorização que busca melhorar JWTs e macaroons ao oferecer “atenuação” — a capacidade de derivar tokens mais limitados e de curta duração offline, ainda assim verificáveis com chaves públicas. Os comentaristas exploram como isso viabiliza controle de acesso no estilo capability, delegação e minimização por requisição, mas observam que a revogação ainda exige mecanismos com estado e que o ecossistema e a especificação do Biscuit são menos maduros do que os padrões estabelecidos. Muitos o veem como uma opção promissora quando se precisa de lógica de autorização rica e descentralizada, enquanto JWTs mais simples ou tokens de sessão continuam preferíveis para cenários de autenticação centralizada e direta.

Visão geral

  • Biscuit é apresentado como um token de autorização no estilo capability, com atenuação offline, verificação por chave pública e uma linguagem de autorização baseada em lógica embutida.
  • Vários comentaristas acham o conceito “bacana” e gostam da clareza da documentação, mas apontam lacunas em relação a trade-offs não destacados e à ausência de orientação sobre “quando não usar isso”.

Comparação com JWT, OAuth2, Macaroons

  • JWTs:
    • Pontos fortes: transporte simples de pequenas claims, amplo suporte, fácil validar papéis/permissões sem chamadas ao banco.
    • Pontos fracos: armadilhas históricas (manuseio de algoritmos, algoritmo “none”), complexidade e superfície maior em comparação com cookies de sessão criptografados simples.
    • Biscuit tenta evitar as armadilhas do JWT por meio de uma especificação mais rígida e de uma suíte de testes, mas os tokens podem ser maiores e mais lentos para verificar (uma assinatura por bloco).
  • OAuth2:
    • A delegação padrão é centralizada e online; não permite verdadeira atenuação/minimização offline.
    • Biscuit pode se integrar com OAuth/OIDC como um formato de access token.
  • Macaroons:
    • Conceitualmente semelhantes (atenuação, caveats), mas macaroons são abstratos, baseados em chave simétrica e percebidos como mais difíceis de implementar e usar.
    • Biscuit adiciona codificação concreta (protobuf), uma linguagem de lógica e verificação por chave pública.

Atenuação e Delegação

  • A atenuação offline é amplamente vista como o principal diferencial do Biscuit:
    • Partindo de um token poderoso, os detentores podem derivar tokens mais restritos (menos escopo, vida útil menor etc.) sem contatar um IdP.
    • Isso é visto como particularmente útil para minimização por requisição e delegação em microsserviços.

Revogação e Statelessness

  • Biscuit usa IDs de revogação por bloco; revogar um bloco revoga aquele token e todos os derivados.
  • A revogação real ainda requer estado (listas de revogação, caches), o mesmo problema fundamental dos JWTs.
  • Vários comentaristas enfatizam que a “revogação totalmente stateless” é impossível; no melhor caso, você centraliza e minimiza o estado necessário.

Linguagem de Autorização e DSL de Política

  • A linguagem no estilo Datalog do Biscuit carrega tanto fatos quanto verificações dentro dos tokens e nos verificadores.
  • Há alguma confusão em torno de check if versus allow if / deny if, indicando uma curva de aprendizado.
  • Alguns veem isso como uma abordagem promissora de “DSL de política” para descrever quem/o quê/quando/onde/por quê, mas também observam o risco de complexidade excessiva.

Ecossistema, Maturidade e Implementações

  • Existem implementações em várias linguagens, muitas vezes via bindings de Rust ou WASM; algumas bibliotecas estão atrasadas.
  • Há uma suíte de testes de conformidade, mas seções da especificação ainda estão marcadas como TODO e casos-limite estão evoluindo.
  • As preocupações incluem comportamento inconsistente entre bibliotecas, limites de execução definidos pelo usuário e falta de testes de fuzz/property testing.
  • Consenso: forte potencial, mas o ecossistema ainda está amadurecendo.