REST, RESTful, JWT e Padrões da Internet

José Campillo
Nov 5 · 5 min read

Preparados para a sopa de letrinhas do HTTP? Eu não :(

Costumo dizer que a web é um mundo à parte. Ela possui suas regras, seu funcionamento, seus meios de se obter conhecimento e o mais importante para o cenário que estamos analisando: seus padrões.

Nós, enquanto desenvolvedores, cotidianamente nos relacionamos com outros sistemas — seja um webservice para validação de CNPJ ou para simplesmente descobrir a cor dos olhos de personagens do Star Wars — , que desempenham papel fundamental para o funcionamento de nossas aplicações (ou não).

Agora, imaginem um cenário em que cada integração implemente suas próprias regras e sua própria forma de funcionamento? Seria o caos instalado. A curva de aprendizagem seria enorme para cada relacionamento, sem citar o aumento de consumo de café per capita.

Um desenvolvedor qualquer após integrar 5 APIs sem padrão

Para resolver esse grande enigma da humanidade, foram criadas as arquiteturas de comunicação.

Afinal, o que é REST?

REST (Representation State Transfer) é um padrão utilizado para integração de Web Services. Foi desenvolvido como uma abstração do protocolo HTTP, trabalhando no formato de requisições e respostas. Para isso, trabalha em dois fronts, sendo: (1) solicitação dos recursos disponíveis e (2) devolução de informações de acordo com a requisição recebida.

Funcionamento da arquitetura REST. ¹

Como notamos acima, uma característica do REST é ser cliente-servidor. É necessário um papel muito claro entre solicitante e solicitado, essa separação de responsabilidades torna-se essencial para seu funcionamento. Imagine se você, leitor deste artigo, ficasse em dúvida sobre quem faz o serviço de transporte, a Uber ou a Polícia Militar?

Programador que não conhece os princípios de REST andando de Uber

Outra característica é ser stateless, ou seja, as requisições são completas em si e não dependem de informações adicionais. Nessa arquitetura, o servidor não guarda estado (session) de seu lado.

REST também oferece uma padronização de verbos HTTP, ou seja, o uso adequado de GET, POST, PUT, DELETE e cia. Portanto, pela simplicidade de seu funcionamento, acabou por conquistar o coração de seus utilizadores e tornou-se uma grande opção ao SOAP.

E RESTful?

Prepare-se, essa explicação realmente demanda um aprofundamento incomensurável e conhecimento técnico intergalático.

Enquanto REST são as padronizações do funcionamento, RESTful é nada mais que a capacidade de implementar esse padrão. É utilizado somente para se referir a aplicações que utilizam REST.

Você após aprender o que é REST e RESTful

E o JWT, onde entra nessa história?

Antes das informações serem exibidas aos solicitantes de uma API sigilosa, torna-se necessária a autenticação da requisição. Para isso, vamos exemplificar com o padrão de transferência de dados JWT (JSON Web Tokens).

Esse padrão oferece um sistema de transferência “seguro”, assinado digitalmente por um algoritmo HMAC. Seu funcionamento é muito simples: você se autentica com um login e senha, recebe um token e o utiliza para requisição dos endpoints desejados.

Funcionamento do JWT. ²

O token possui um padrão, sendo separado em 3 partes: header, payload e signature. O header é constituído de duas informações encodadas em base64: o algoritmo, que pode ser HMAC SHA256 ou RSA, assim como o tipo.

Exemplo:

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

A segunda parte diz respeito ao payload (claims), que seria a área em que utilizamos para transportar as informações desejadas. Existem 3 tipos de payloads: os públicos, privados e reservados.

Os payloads reservados (reserved claim) são aqueles não obrigatórios — apesar de recomendados-, normalmente utilizados por protocolos de segurança em API.

Sendo:

“iss” (issuer): a origem do token.

“iat” (issueAt): o timestamp em que o token foi gerado.

“exp” (expiration): o timestamp de quando o token expira.

“sub” (subject): entidade a quem o token pertence, normalmente o id do usuário.

Os payloads públicos (public claims) são informações ou agrupamentos pertencentes ao domínio da aplicação, mas não obrigatórias. Os payloads privados (private claims) são informações ou agrupamentos que não pertencem ao domínio, mas são obrigatórias.

Por exemplo:

{
"iss": "https://medium.com.br/monotox", // reserved claim
"github": "https://github.com/Monotox" // private claim
}

A signature, terceira e última parte da constituição do nosso token, é a cereja do bolo. É formado do header e payload encriptado com uma chave chamada secret. Sua função é garantir a integridade do token, prevenindo o ataque chamado man-in-the-middle.

Em suma, ficaria dessa forma:

HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)

Um token finalizado consiste em base64Url(header).base64Url(payload).assinatura

Resultado dos processos acima

Utilizando o Token

Uma vez que o token foi criado, basta enviá-lo no header Authorization de cada requisição HTTP com a flag Bearer. Exemplo:

Authorization: Bearer <token>

Com o token em mãos, a API não precisa efetuar consultas ao banco para obter as informações do usuário, pois o próprio token JWT já possui todas os dados que precisamos.

Fluxo de requisições para obtenção de token e consulta aos endpoints

Exemplo em PHP

Notas de Conclusão

Apesar deste artigo tratar o JWT como autenticação, ele pode ser utilizado para transmitir qualquer informação sensível que necessite de confiabilidade.

Nas palavras do produtor:

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

Para maiores informações, visite o JWT website.


Espero que o artigo tenha sido de grande valia! :)

¹ créditos da imagem: MyCourses.

² créditos da imagem: Okta.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade