HTTP | JWT

O JWT (JSON Web Token) normalmente consiste em header + payload + signature.

 

Header

 

Contém as informações de metadados sobre o JWT.

 

• alg: o algoritmo usado para assinar o token.

• typ: o tipo do token, sempre JWT.

{
  "alg": "HS256",
  "typ": "JWT"
}

Você pode encontrar mais cabeçalhos, mas os anteriores estarão sempre presentes.

 

Payload

 

O payload contém as claims do JWT. Os cabeçalhos padrão são os seguintes:

 

• iss: o emissor, a entidade que gera e emite o JWT.

• sub: o subject, a entidade identificada por este token.

• aud: a audience, o público-alvo deste JWT.

• exp: a expiração, o timestamp em formato UNIX após o qual o token não deve ser aceito.

• iat: issued at, especifica a data em que o token foi emitido.

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

 

Assinatura

 

A assinatura é criada utilizando o Header Codificado, o Payload Codificado, um Secret e um Algoritmo Criptográfico.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5M
DIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Algoritmos suportados

Os algoritmos a seguir são suportados tanto pelos componentes JWT de Cliente quanto de Servidor.

 

• HS256
• HS384
• HS512
• RS256
• RS384
• RS512
• ES256
• ES384
• ES512
• ML-DSA-44
• ML-DSA-65
• ML-DSA-87

 

As bibliotecas OpenSSL são necessárias para assinar e verificar o JWT, com uma exceção.

 

ML-DSA, assinaturas pós-quânticas

Os três algoritmos ML-DSA são os algoritmos JOSE pós-quânticos da RFC 9964, e são a exceção citada acima: eles são implementados em Object Pascal puro no pacote sgcCrypto, portanto assinam e validam sem nenhuma biblioteca OpenSSL presente. A assinatura é ML-DSA da FIPS 204 no modo puro com um contexto vazio sobre a entrada de assinatura JWS, transportada no token em base64url. O assinador é determinístico, portanto a mesma chave e a mesma entrada sempre produzem a mesma assinatura.

 

Os valores do enum são jwtMLDSA44, jwtMLDSA65 e jwtMLDSA87, e o header alg que eles escrevem é ML-DSA-44, ML-DSA-65 e ML-DSA-87. O cliente assina com JWTOptions.Algorithms.MLDSA.PrivateKey, uma chave privada PEM PKCS#8, e o servidor valida com JWTOptions.Algorithms.MLDSA.PublicKey, uma chave pública PEM SubjectPublicKeyInfo. O conjunto de parâmetros da chave tem que ser o que o algoritmo nomeia: caso contrário, assinar gera um erro e a validação retorna False.

 

As assinaturas são grandes. Uma assinatura ML-DSA-44 tem 2420 bytes contra 64 do ES256, portanto um token cresce aproximadamente 3,2 KB de base64url, e um de ML-DSA-87 cerca de 6,2 KB. Verifique os limites de tamanho de header de tudo por onde o token passa antes de adotá-lo.

 

As chaves também podem ser transportadas como JSON Web Keys AKP, RFC 9964 seções 3 e 4. sgcMLDSA_ExportPublicJWK e sgcMLDSA_ExportPrivateJWK escrevem uma, sgcMLDSA_ImportJWK lê qualquer uma das duas formas, e sgcMLDSA_ImportJWKAsPEM converte um JWK diretamente nas strings PEM que os dois componentes leem. Um JWK privado armazena a semente de 32 bytes em priv, a única forma privada que a seção 4 define, portanto uma chave privada expandida não pode ser escrita como JWK. As quatro funções estão declaradas em sgcHTTP_JWT_MLDSA.

 

* Os algoritmos ML-DSA precisam do pacote sgcCrypto. Sem ele os valores do enum continuam existindo, portanto um formulário salvo com um deles ainda carrega, mas assinar gera um erro e todo token ML-DSA é rejeitado.

Componentes

 

• TsgcHTTP_JWT_Client: Cliente JWT que permite codificar e assinar JWT e enviá-lo como um Authorization Header nos protocolos HTTP e WebSocket .

• TsgcHTTP_JWT_Server: servidor JWT que permite decodificar e validar JWT recebidos como um Authorization Header nos protocolos HTTP e WebSocket.

 

 

* Os Componentes JWT exigem pelo menos a versão 10.6.0.5169 do Indy ou a Edição Enterprise do sgcWebSockets.