JWT desmistificado

Recentemente no trampo ando estudando bastante sobre OAuth2 e todo o ecossistema que envolve esse assunto, mais especificamente, venho implementando tanto authorization servers quanto resource servers (explicação desses carinhas num post mais focado no OAuth em breve).

Dito isto, a forma mais comum e padrão utilizada para servir como access token do OAuth é o JWT, conhecido de muita gente, porém realmente domado por poucos.

Primeiro de tudo, quando comecei a me aprofundar mais sobre o assunto JWT, me espantei com uma coisa, sabiam que a pronúncia correta em inglês é jót? Sim, nunca tinha imaginado isso hahaha, sempre falei cada letra separada, J - W - T, em português né, alem disso, época que trabalhei pra gringa não tive muito contato com jóts, então fica ai a curiosidade.

O que raios é um JWT?

Um JWT nada mais é do que um JSON object que é serializado de tal maneira que possa ser trafegado mais eficientemente através da rede.

Um exemplo de JWT com assinatura

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

OBS: O JWT está formatado de maneira que suas partes sejam mais facilmente identificadas (com quebras de linhas entre os . que separam cada membro), entretanto, ele é normalmente trafegado sem nenhum tipo de quebra de linha (tudo junto).

Estrutura de um JWT

Perceba que no JWT não conseguimos a priori identificar sua estrutura, isso porque seus “membros” estão “encodados” em Base64UrlSafe, ou seja, precisamos decoda-los primeiro antes de conseguirmos interpreta-lo.

Levando em consideração o JWT apresentado na ultima sessão, ao aplicarmos o decoding com Base64UrlSafe da primeira parte, obtemos os seguinte JSON

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

Esse primeiro JSON é chamado de JOSE Header, nele são contidas informações (claims) a respeito de como o JWT deve ser processado e interpretado criptograficamente, alem de conter possivelmente outras propriedades sobre o JWT.

As claims (ou informações) que esse JSON guarda vai depender to tipo de JWT, se estamos assinando (JWS) ou criptografando (JWE). Por exemplo, a claim “alg” especifica qual algoritmo foi utilizado para assegurar esse JWT.

A segunda parte do JWT, contém seu conteúdo em si, ou seja, claims a respeito da Informações que ele carrega.

{"iss":"joe",
 "exp":1300819380,
 "http://example.com/is_root":true}

Neste exemplo temos 2 claims padrões do JWT, “iss” e “exp” e uma claim custom “http://example.com/is_root”.

“iss” guarda informações sobre o issuer do token, ou seja, quem emitiu esse JWT, nesse caso “joe”, mas poderia ser uma URL, nome de alguma organização, etc.

“exp” guarda informações sobre a data de expiração do token, no formato POSIX, ou seja, segundos desde 1970-01-01T00:00:00Z UTC.

Segue a RFC de JWT para uma lista de claims registradas e seu uso.

A terceira parte do JWT é sua assinatura (no caso de um JWS), ou seja, um token que deve ser utilizado para validar sua autenticidade.

A estrutura básica do JWT é esta, dependendo da segurança adicional que desejamos utilizar, aplicamos as suas operações em cima dos JSONs listados acima.

Entrar em detalhes de como criptografar e assinar os JWTs esta fora do escopo desse post, para o seu dia a dia normalmente você irá trabalhar com bibliotecas de criptografia, então é importante saber como utilizar, porém a implementação costuma ser complexa por envolver muitas operação matemáticas que devem ser aplicadas de maneira eficiente.

Aplicações do JWT

Agora que sabemos que raios é um JWT, onde utilizamos?

Bom, da definição sabemos que ele é feito para ser trafegado em requisições web, normalmente no header de Authorization, em URLs (Base64UrlSafe), etc.

Uma ótima aplicação do JWT é como token do OAuth, ou seja, ao autorizarmos um cliente através de qualquer fluxo do OAuth, podemos oferecer um JWT como access token, onde aplicações provedoras de recursos (resource servers) podem utilizar o JWT e permitir que determinados recursos sejam utilizados pelos portadores do token.

Conseguimos confiar que um JWT é legítimo devido a toda sua proteção através do framework JOSE (JSON Object Signing and Encryption), então uma vez que o token seja validado, suas informações com certeza foram emitidas pela parte que autoriza o acesso.

Em resumo, JWT normalmente é utilizado como token de autenticação / autorização para aplicações protegidas.

E é isso, próximos capítulos quero falar de OAuth2 para aproveitar o que venho estudando nos últimos tempos.