Representational State Transfer, popularmente conhecido apenas por REST, iniciou como uma abordagem simplificada para os Web Services que tinham enormes especificações, como WSDL para descrever o serviço e SOAP para permitir a comunicação.
REST trabalha diretamente com o protocolo HTTP puro, os verbos HTTP são utilizados para definir a operação a ser executada para o recurso. Atualmente não existe a imposição de um padrão, o formato pode ser JSON, XML ou apenas PLAIN TEXT, porém existem convenções e boas práticas a serem abordadas, vide o artigo RESTful API – Melhores práticas.
REST é mais performático que SOAP
A abordagem simplificada também foi aplicada à segurança dos serviços REST; novamente nenhum padrão definido impõe uma maneira particular para autenticar os usuários, e devemos lembrar que o REST não mantém nenhum estado de cliente, com sessões, assim o servidor responde a cada requisição como se fosse única.
Ao optar por RESTful é preciso definir como será realizada a autenticação do usuário e normalmente pensa-se logo no OAuth, mas é muito provável que a sua aplicação não precise de um servidor de OAuth. Se a sua aplicação não tiver login distribuído como Facebook, Github e Twitter, logo não precisa do OAuth e pode utilizar uma solução como o JWT.
JWT – Fluxo de Requisição
JWT (JSON Web Token) é um padrão aberto (RFC 7519) cada vez mais usado, a implementação é totalmente stateless, sendo a abordagem recomendada para aplicações distribuídas.
O JWT fornece uma maneira de criar e validar tokens de acesso sem a necessidade de consultar a base de dados, uma vez que a informação para autenticação é armazenada. Inclusive é compatível com OAuth 2.0, que resulta diretamente em reduzir a latência do serviço ao validar tokens de acesso.
Quando falamos de JWT, precisamos falar e pensar nas especificações do JSON Object Signing and Encryption, também conhecido simplesmente como JOSE, um conjunto de definições divididas em 5 padrões: JWT, JWA, JWS, JWK e JWE. Aprofunde o conhecimento lendo o RFC 7165
Estrutura do JWT
<base64-encoded <strong>header</strong>>.<base64-encoded <strong>claims</strong>>.<base64-encoded <strong>signature</strong>>
Header
O tipo de chave usada pode ser gerado a partir do algoritmo de hash HS256 ou RS256.
Diferenças entre os algoritmos:
HS256 (HMAC com SHA-256), é um algoritmo simétrico, com apenas uma chave (secreta) que é compartilhada entre as duas partes, servidor da aplicação e cliente. Uma vez que a mesma chave é utilizada tanto para gerar a assinatura como para validá-la, deve-se ter cuidado para garantir que a chave não seja comprometida.
RS256 (RSA Signature with SHA-256) é um algoritmo assimétrico e utiliza um par de chaves público / privado: o servidor da aplicação tem uma chave privada (secreta) usada para gerar a assinatura e o cliente da aplicação recebe uma chave pública para validar a assinatura.
Claims
O payload contém os “claims”, as reivindicações declaradas sobre uma entidade e os metadados adicionais. Existem três tipos de “claims”: reservados, públicos e privados
Claims: Reservadas
“iss” (Issuer) Origem do token
“iat” (issueAt) Timestamp de quando o token foi gerado
“exp” (Expiration) Timestamp de quando o token expira
“sub” (Subject) Entidade a quem o token pertence, normalmente o ID do usuário
Exemplo:
{ “iss”: “10.10.10.1”, “iat”: 1300819378, “exp”: 1300819478, “sub”: “43231”, “context”: { “user”: { “uid”: “2123CD-3243EDR-32ERWRE2-4E4R”, “username”: “renato.marinho”, “fullname“: “Renato Marinho” } } }
Signature
Verifica que o remetente do JWT é quem diz ser para garantir que a mensagem não foi alterada ou corrompida durante o tráfego.
Implementação
Site oficial do JWT, onde também é possível verificar as bibliotecas disponíveis para as mais diversas linguagens, tais como: PHP, .NET, Python, Node.js, Java, Ruby, Go, JavaScript entre outras.