JWT (JSON Web Token)

  • Rafael Miceli
  • 18 Abr 2016

Usando OAuth o fluxo para ganhar autorização ao recurso que queremos de nossa aplicação muda bastante.

O Que antes parecia algo bastante simples, que era apenas uma comunicação com um servidor, agora passa a ser mais modular.

Mas como dito no post sobre OAuth básico ganhamos muitas vantagens ao usar o OAuth.

Ok, usando OAuth, como então sabemos que estamos autorizados para acessar cada resource?

Tokens

Não vou explicar a definição do que é um Token, mas o mesmo é o que usamos para garantir que somos nós que estamos acessando.

O Fluxo funciona da seguinte forma:

Nós (Resource Owner) acessamos a url de um site (Client), que geralmente vai nos redirecionar para uma tela de login (Authorization Server) quando precisamos acessar uma área restrita, e após o login realizado com sucesso nós recebemos com isso um Token, que comprova que nós somos nós.

Antes do OAuth usavamos o SAML, mas com o OAuth foi preciso mudar isso. Começou usando SWT (Simple Web Token).

Mas o SWT, como o próprio nome, era muito simples e possuía apenas assinatura simétrica, com isso foi necessário evoluir o Token para OAuth.

JWT

Hoje usamos o JWT (Json Web Token) como o Token para validar nossa autorização com o protocolo OAuth.

Usando JWT nós codificamos nosso Token usando JSON. Com isso a ganhamos um excelente benefício, pois qualquer plataforma possuí um parser de JSON!

Além do mais, JSON é atualmente nosso formato favorito na web, uma vez que muitos sites podem ler facilmente o mesmo!

No lado criptográfico, JWT também possuí assinatura simétrica e assimétrica.

JWT Estrutura

Para entendermos um pouco um JWT eis abaixo um sample de um:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjEzODY4OTkxMzEsImlzcyI6ImppcmE6MTU0ODk1OTUiLCJxc2giOiI4MDYzZmY0Y2ExZTQxZGY3YmM5MGM4YWI2ZDBmNjIwN2Q0OTFjZjZkYWQ3YzY2ZWE3OTdiNDYxNGI3MTkyMmU5IiwiaWF0IjoxMzg2ODk4OTUxfQ.uKqU9dTB6gKwG6jQCuXYAiMNdfNRw98Hw_IWuA5MaMo

Vamos separar ele para entendermos um pouco:

Header:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

Payload:

eyJleHAiOjEzODY4OTkxMzEsImlzcyI6ImppcmE6MTU0ODk1OTUiLCJxc2giOiI4MDYzZmY0Y2ExZTQxZGY3YmM5MGM4YWI2ZDBmNjIwN2Q0OTFjZjZkYWQ3YzY2ZWE3OTdiNDYxNGI3MTkyMmU5IiwiaWF0IjoxMzg2ODk4OTUxfQ.

Signature:

uKqU9dTB6gKwG6jQCuXYAiMNdfNRw98Hw_IWuA5MaMo

O JWT é separado por “.”, cada parte sua consistindo de:

<base64url-encoded header>.<base64url-encoded claims>.<base64url-encoded signature>

A primeira parte da estrutura é seu header que contém informações sobre qual criptografia está sendo usada.

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

Payload ou Claims:

A segunda é seu conteúdo. O Conteúdo de um JWT são Claims. Claims são informações que seu JWT passa como pares de chave valor para seu servidor validar.

Existem 2 tipos de Claims que são Reserved Claims , que são Claims já pré-definidos (compare com keywords de uma linguagem) e Application Defined Claims , que são Claims “customizados”, que você vai criar para sua aplicação usar.

Alguns exemplos de Reserved Claims são

  • “iss” (Issuer): Informa da onde o token está vindo.
  • “iat” (IssuedAt): Quando o token foi gerado.
  • “exp” (Expiration): Quando o token expira.
  • “sub” (Subject): A entidade a quem este token pertence (geralmente o Id do usuário)
{
    "iss": "localhost:4039132",
    "iat": 1300819370,
    "exp": 1300819380,
    "sub": "21EC2020-3AEA-4069-A2DD-08002B30309D",
    "context": {
        "user": {
            "userKey": "21EC2020-3AEA-4069-A2DD-08002B30309D",
            "username": "bwayne",
            "displayName": "Bruce Wayne"
        }
    }
}

Siganture:

A terceira é a assinatura do token, ou seja, se queremos garantir que o token não foi corrompido podemos usar a Signature(Assinatura) com o Header para isso.

Após conhecer o JWT, em um próximo post vamos criar um simples Authorization Server.

comentarios com Disqus Disqus