DAT (Distributed Access Token) ​

1. Visão geral ​

À medida que o número de usuários conectados simultaneamente aumenta, o número de sessões (Session) também cresce, gerando uma carga excessiva no servidor de sessões.

O DAT é uma especificação de token concebida para resolver esse problema de sobrecarga do servidor de sessões e implementar uma autenticação eficiente que não compartilha estado entre servidores (Stateless).

O DAT é uma string composta por 5 campos fixos separados por ponto (.). É possível recortar cada campo apenas pela posição dos separadores, sem análise JSON, e o momento de expiração e a região criptografada fazem parte da própria especificação.

2. Formato wire ​

expire . cid . plain . secure . signature

2.1. Especificação detalhada por campo ​

Tempo de Expiração : uint64 (Unix Time)

• Representa o momento de expiração do token como um inteiro de 64 bits sem sinal, em segundos (Seconds).
• Somente dígitos decimais puros são aceitos. Sinal, espaço ou separador incluídos são erro de formato.

CID : Hex (uint64)

• É o ID do certificado (Certificate ID) usado na verificação do token.
• Somente dígitos hexadecimais puros são aceitos, e o prefixo 0x não é usado.

Dados em Texto Simples : Base64Url (Binary)

• Contém os dados a serem expostos ao cliente. Suporta não apenas strings, mas também dados binários, e o cliente pode decodificá-los e conferi-los.
• Não é criptografado. Não devem ser colocados valores sensíveis aqui.

Dados Criptografados : Base64Url (Binary)

• Contém os dados a serem mantidos privados em relação ao cliente. Estão criptografados com o algoritmo de criptografia do certificado, de modo que um cliente sem o certificado não consegue descriptografar o conteúdo.
• Sua estrutura interna é IV(96bit) + texto cifrado, e o IV é gerado novamente a cada criptografia.

Assinatura : Base64Url (Binary)

• É o dado de assinatura para verificar adulteração e falsificação do token. É gerado assinando os campos anteriores com o algoritmo de assinatura do certificado.
• Nenhum campo de um token cuja verificação de assinatura falhou deve ser considerado confiável.

3. Regras canônicas (Canonical Rules) ​

Para que clientes implementados em várias linguagens interpretem o mesmo token da mesma forma, as regras abaixo não podem divergir entre implementações. A implementação de referência é o Rust (dat-rust), e todas as demais implementações estão alinhadas a essas regras.

3.1. Análise dos campos numéricos ​

expire e cid são interpretados de forma estrita. Todas as entradas abaixo são rejeitadas como erro de formato.

3.2. Determinação da expiração ​

O token DAT e o certificado têm limites de expiração diferentes. Não os confunda.

O token torna-se inválido no exato momento em que chega o instante de expiração, enquanto o certificado permanece válido até esse instante. Isso porque o certificado precisa viver um tique a mais do que o token para conseguir verificar os tokens emitidos na fronteira.

3.3. Payload secure vazio ​

Se não houver dados a criptografar, secure é uma string vazia.

• encrypt(entrada vazia) → saída vazia (não são adicionados nem IV nem tag GCM)
• decrypt(entrada vazia) → saída vazia
• Se não estiver vazio, mas tiver tamanho menor ou igual ao do IV (12 bytes), é erro de descriptografia.

1893456000.1a.SGVsbG8..T3RoZXItc2lnbmF0dXJl
                      ↑ token normal com a posição de secure vazia

4. Emissão e verificação ​

4.1. Procedimento de emissão ​

1. Entre os certificados que o gerenciador possui, escolhe-se um certificado apto a emitir (issuable).
2. Calcula-se expire = now + dat_ttl_seconds.
3. Codifica-se plain em Base64Url e, para secure, criptografa-se e depois codifica-se em Base64Url.
4. Assina-se a string expire.cid.plain.secure e anexa-se o resultado como último campo.

4.2. Procedimento de verificação ​

1. Divide-se em 5 campos pelo ponto (.). Se a quantidade de campos for diferente, é erro de formato.
2. Verifica-se expire. Um token expirado é rejeitado antes da verificação da assinatura.
3. Busca-se o certificado pelo cid. Se não existir, a verificação é impossível.
4. Verifica-se a assinatura sobre o trecho expire.cid.plain.secure.
5. Somente após o sucesso da verificação é que secure é descriptografado.

5. Comparação com o JWT ​

O DAT e o JWT (JSON Web Token) compartilham a estrutura de token separada por ponto (.) e o método de verificação por assinatura, mas apresentam as seguintes diferenças fundamentais no design interno.

5.1. Comparação das diferenças estruturais ​

• Estrutura JWT

  header	body	signature
  Base64Url (JSON String)	Base64Url (JSON String)	Base64Url (Binary)

• Estrutura DAT

  Tempo de Expiração	CID	Dados em Texto Simples	Dados Criptografados	Assinatura
  Unixtime (uint64)	Hex (uint64)	Base64Url (Binary)	Base64Url (Encrypt Binary)	Base64Url (Binary)

5.2. Principais diferenças ​

• Leveza baseada em Binary: o JWT trata Header e Body como strings JSON, enquanto o DAT manipula dados binários (Binary) diretamente, otimizando o tamanho dos dados e aumentando a eficiência da análise.
• Segurança integrada (campo Dados Criptografados): no JWT, o Payload é por padrão exposto em texto simples, exigindo a aplicação de uma especificação separada como o JWE quando é necessária criptografia. Já o DAT suporta criptografia no próprio token por meio do campo Dados Criptografados.
• Restrição de expiração imposta: no JWT o campo exp (Claims) é opcional, mas no DAT o campo Tempo de Expiração é obrigatório na estrutura do token, tornando a validação do prazo de validade imprescindível.
• Sem negociação de algoritmo: como o JWT carrega no próprio token o valor alg do cabeçalho, surge a superfície de ataque de confusão de algoritmo. No DAT, o algoritmo é decidido pelo certificado, e o token não contém informação de algoritmo.