JSON Web Token, o famoso JWT, é de longe a forma mais comum de segurança utilizada em web APIs RESTful depois do uso de SSL/TLS. Quando temos variados clientes consumindo nossas APIs, saber quem está autenticado ou não, ou ainda, que tem autorização ou não para fazer as chamadas, é importantíssimo.
Na primeira parte deste tutorial eu ensinei como implantar um mecanismo de JWT em uma API Node.js, adicionando esta importante camada de segurança. Dentre as dúvidas mais comuns acerca desta técnica está a segurança do token, afinal ele é o ponto mais exposto na técnica e sequestro de tokens é a forma mais comum de tentar burlar este mecanismo.
Claro que usando SSL (sugiro Lets Encrypt que é gratuito) esse risco de captura diminui consideravelmente uma vez que a conexão está criptografada e encorajo fortemente você a não aceitar requisições usando HTTP. No entanto, sabemos que para tudo existem brechas a serem exploradas principalmente por parte de pessoas maliciosas dentro da sua própria empresa muitas vezes…
#1 – O risco do JWT
Mas o token não é criptografado? Eu olhei ele e vi um monte de letras e números aleatórios…
Não, o token apenas é codificado em base64, uma representação textual de um conjunto de bytes, separada em três partes por pontos, veja com atenção o exemplo abaixo.
|
1 2 3 |
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsImlhdCI6MTc1MTY1NDY3MSwiZXhwIjoxNzUxNjU0OTcxfQ.0bbF7setlFnWvSuOKGfir32O9GLS9Fma-z91hq9uSQU |
Se você jogá-lo em qualquer decodificador de base64 online, verá as três partes que o compõem, sendo que a única ilegível é a terceira onde temos a assinatura digital do servidor, atestando que aquele token foi gerado corretamente pelo seu servidor, o que impede que tokens fake se passem por tokens reais. Veja abaixo um exemplo.
|
1 2 3 4 |
{"alg":"HS256","typ":"JWT"}{"userId":1,"iat":1751654671,"exp":1751654971} l^zEkҸ~*F-/EXj |
No entanto, para essa assinatura digital é necessário um segredo/secret. Esse segredo é usado tanto para assinar quanto para verificar a assinatura (e autenticidade) de um token. Se você tem apenas uma webapi que usa o JWT, isso é bem tranquilo. Agora, se você possui diferentes microservices e todos eles precisam de autenticação/autorização via JWT, então você tem um problema pois:
- ou você faz com que o cliente se autentique em cada um dos microservices que vai usar;
- ou você compartilha o secret entre todos eles.;
Uma solução possível para este problema é usar um API Gateway na frente de todos microserviços. Daí todos eles confiariam no gateway, sem ficar pedindo ou verificando tokens. Mas geralmente bons APIs gateways custam caro, embora dê pra fazer um mais caseiro.
Mas voltando ao assunto central: como podemos adicionar mais segurança em nosso JWT em arquitetura de micro serviços? Ou melhor: como podemos garantir que este token possa ser usado em diferentes microservices sem compartilhar o secret com todos eles?
#2 – Assinatura assimétrica do JWT
Como estou falando de um token que navega entre diferentes microservices por meio inseguro (internet) o ideal é uma criptografia assimétrica, onde o emissor/servidor irá gerar o token assinado com a chave privada (de posse somente dele) e os consumidores/clientes podem verificá-lo usando a chave pública (de posse de todos microservices).
Assim, todos microservices confiam na emissão de tokens a partir um servidor central, enquanto podem validar sua assinatura para garantir que não foi forjado, sem saber o secret original.
Primeiro, vamos criar um par de chaves (uma pública e outra privada) usando o algoritmo RSA, um dos mais famosos e seguros do mundo de tipo assimétrico. O jeito mais fácil de gerar um par para fins de estudo é usando um gerador online, como esse aqui. O Format Scheme é PKCS #1 e o tamanho da chave varia de 256 bits a 2048 e embora chaves maiores sejam mais seguras (cada vez que você dobra o tamanho multiplica por 6x a dificuldade de quebra da chave) atente ao fato de que seu JWT deverá ser decifrado pelo servidor a cada requisição e que chaves maiores são mais demoradas para decifrar, mesmo com a chave certa.
Como é apenas para estudo, fiz com o tamanho comercialmente aceito (2048 -bit atualmente) e minha chave pública ficou assim (salve em um arquivo public.key):
|
1 2 3 4 5 6 7 8 9 10 |
-----BEGIN RSA PUBLIC KEY----- MIIBCgKCAQEArCiXLpE3Jtq85xsClQikuRyrAk1MyCHDVUw0K9Tgf2kvLqa76GmW biok/tltodkbErGhl5vaRUktrUH0ujMX2ECZsZBRWt8Nchdg0YU45KuDoq+9QnxN lAGPkUJ4Au+SmcNoZXC85FFaNj+SxyfMKksz6lB4K44vHHtditVuvRDPG4OOxQxs jAB1G8m49iyhdcWp5X2vYoXpxUuaxNKV3uRD1jdhNeG3KxywR/mHpYJ2oIcjjKXM TJxTnr/DogQ67HwXUQSBMOmk430jwGWOSXOC6dalNSf+cva+7C2uT0u9tIA+wfAL Cbn3c/mN0EagfPnW1H/VZD05KdUJFyKvxQIDAQAB -----END RSA PUBLIC KEY----- |
Enquanto que minha privada ficou assim (salve em um arquivo private.key):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
-----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEArCiXLpE3Jtq85xsClQikuRyrAk1MyCHDVUw0K9Tgf2kvLqa7 6GmWbiok/tltodkbErGhl5vaRUktrUH0ujMX2ECZsZBRWt8Nchdg0YU45KuDoq+9 QnxNlAGPkUJ4Au+SmcNoZXC85FFaNj+SxyfMKksz6lB4K44vHHtditVuvRDPG4OO xQxsjAB1G8m49iyhdcWp5X2vYoXpxUuaxNKV3uRD1jdhNeG3KxywR/mHpYJ2oIcj jKXMTJxTnr/DogQ67HwXUQSBMOmk430jwGWOSXOC6dalNSf+cva+7C2uT0u9tIA+ wfALCbn3c/mN0EagfPnW1H/VZD05KdUJFyKvxQIDAQABAoIBAQCGMIFex8vwWjFC BjimB/21WBYnji8aE88YjnRf8ecnCMrBFy+CgcLCjdEWYE3nCL3kfVaSQOYKeXbE BJQICsk8Q2ZJFE+FgDUPyA8sYSYuf030ofzodNFXWzwXonK+/xQLDFg0MYLaiFrD zBvRZkDqeoG10xFICeTI05PfImvVq5wjA6wXEmnCFBsfQwjduvJfrogVIfsDqrU0 na8XNGM6StyzljcAvPJP5BWZISNEQmub6tfN+pDoOY9dksaSbBMI8BQbhbmBxlKD ZnnQJG45M583SFalzSDbixyHrteF/5PdZ0krNvHowU0lqfg2HoVYcHGdKbw+j8Xw PiY5oebhAoGBANU9O+sh2sS7GlPXPpV76nX2WsCkqZgbImVAq4F2BVT5FdvKxD+H gRwAHwcOtsxHXmusHMgVXt4rFL8jDkaRxKBcSp8vr5o8jvdOY3DGuyzAQeQNuNv6 KEKVqZ4Fr0uOkD4YrhYwTA+x0jQVwO4ZTQ2vRnHaiX/gyjNYm9PFLmKtAoGBAM6u dN32SAR5rODMcDJFxkQpM3nD4KyIHO/fLEAm8sRepZ+N6IRRGXaa7f9vQqjmByMs ZB/bCH47N0nghJw5Q5IPCuQQV/qjEb61O98DRrtAtX6r9/MvhhuMvMIcGrZCbaQo RCBEdrAMPcpMj2xAb3NTqG3aied7BRvq7okJm7x5AoGAAcUgWjNNvZRQA6Ilwtfk elYxKqgzQC/5eR2wTsLMCIiIxepI9r4JNFJL76MPoWJ2Ri6HjqGex/lTksKXu746 A5rAg9HBg2Y9SZA9AxKjOxvdcCctAaZx7xuO7ODfM6FbUSijSUvdVcQEGqqTj2Zm XVa3HvrRaV5UT1jM8lUQrYECgYBM1FkpMaXv0/NJ1XVXmsxrBg3Wk9PvDuIC4Skn 59KS4MQcnbnzhdo7VrhmHcvf0TKSBqxpkxiDJCwXUFi7YiYWI3Ve9hxeVUQBaomJ C0S90v4kynRveBkYIKcCWUQswGDVhwpcHFcqdkJ58x/Vk9ZaPpz7ySM+Y2Kw0BI/ 6sxzsQKBgHgmmbL7pPDp63azs1uJv352qAe5wcKviuUnKu0fySFE4d/AyW0+KRx8 MDgRrRGb6hf3KZx3YuO0qdjzQvviOZj+qbG4STt1WFWUQhjgzp7a2alrOvApll4N x2JCIR+NmAWQVzghuhBYE7rWVHQa91j4UngwG0hV8SBm14KqCONz -----END RSA PRIVATE KEY----- |
Agora, em nossa API, vamos mudar levemente o nosso código que gera os tokens para que os mesmos sejam assinados de maneira assimétrica.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
const fs = require("fs"); app.post('/login', (req, res, next) => { //esse teste abaixo deve ser feito no seu banco de dados if (req.body.user === 'luiz' && req.body.password === '123') { //auth ok const userId = 1; //esse id viria do banco de dados const privateKey = fs.readFileSync('./private.key', 'utf8'); const token = jwt.sign({ userId }, privateKey, { expiresIn: parseInt(process.env.JWT_EXPIRES), algorithm: "RS256" }); return res.json({ token: token }); } res.status(401).json({ message: 'Invalid credentials!' }); }) |
As alterações estão apenas a partir da linha que declaro a privateKey, que substitui o nosso secret padrão que estávamos usando. A leitura do arquivo da chave é feita usando módulo fs (adicione um require no topo do arquivo) e nas opções de assinatura (terceiro argumento da função) dizemos o algoritmo de hashing que o RSA vai usar no seu algoritmo interno (RS256 no meu caso represa SHA-256).
Atenção: caso o seu arquivo de chave secreta tenha senha (como são geralmente os .PEM gerados pelo OpenSSL, que é a ferramenta mais recomendada) você deve passar um objeto {key, passphrase} no segundo argumento do sign ao invés de apenas a privatekey.
Agora, ao se autenticar, o servidor lhe retornará um token com assinatura criptografada de forma assimétrica, o que permite que vários serviços possam verificar sua assinatura usando a chave pública, ao invés da chave privada, usada para assinar o token da primeira vez, o equivalente ao secret original.
|
1 2 3 4 5 |
{ "token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsImlhdCI6MTc1MTY1NzA1NCwiZXhwIjoxNzUxNjU3MzU0fQ.bhUgnsMUo5AXxhDl-G2yik2ovNYpd6DB0LxunfE3IfK8Oa6rXgjWzHpq19K_TaaTZq4AeQIp8y0aV7lrVzpU_5ssUNSd4eE1vgtJh83GmI10bR7cb34FvOe67twu3Ia8TvlgOGIyBzrJ9tdlUZjSc582OCDeFhP789CL0vItlc-ZZ3kxNVuXf_BMi1qjbgIU7iHa3-IsD_jLOXS_Q1DpUwIPbvm57QiqQMztBM7d4TAcBjQk1AaWLAk_WXxEXys3I21g0sVYEoVicUoWHei-0Me4ivCmjCuJw1YoAisyWZtHUlIrXY9ZI_sfmcfc2jx6YSWQtoWRBZnmP2l1o4pmBQ" } |
Atenção: se você tiver o erro “digest too big for RSA key” quer dizer que sua chave é pequena demais para o texto a ser cifrado. Neste caso, use chaves maiores (eu não tive problema a partir de 1024-bit).
#3 – Verificando o JWT
Agora é hora de ajustar o código que verifica a assinatura do JWT. Enquanto que para criarmos a assinatura usamos a private key, para verificar a mesma usamos a public key.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
function verifyJWT(req, res, next) { let token = req.headers["authorization"]; if (!token) return res.status(401).json({ message: "No token provided." }); token = req.headers["authorization"].replace("Bearer ", ""); if (blacklist[token]) return res.status(403).json({ message: "Invalid token." }); try { const publicKey = fs.readFileSync("./public.key", "utf8"); const decoded = jwt.verify(token, publicKey, { algorithm: ["RS256"] }); if (!decoded) return res.status(403).json({ message: "Invalid token." }); res.locals.token = decoded; return next(); } catch (err) { return res.status(403).json({ message: err.message }); } } |
Note que a alteração foi bem sutil mesmo: carregamos a public key a partir do respectivo arquivo, passamos ela pra função verify, bem como um objeto informando o algoritmo de hashing que usamos junto do RSA (RS256 refere-se a SHA-256). Sim, é um array de algoritmos e passei apenas um.
Agora, se você obter um token pela rota de login e usá-lo para acessar a rota de clientes, verá que está funcionando como deveria e que no uso comum de apenas um cliente e servidor, não mudou em nada. Mas se tiver que confiar neste token em diferentes microservices, todos eles podem verificar a assinatura usando a chave pública.
Note que esta abordagem consome mais recursos computacionais que os tokens comuns. Esteja preparado para um aumento custo de hardware e/ou do tempo entre cada requisição que necessita deste token.
Espero que tenha gostado do artigo e se gosta do assunto criptografia, o vídeo abaixo é para você!
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.
Excelente artigo! É o básico bem feito para garantir o mínimo de segurança na autenticação de microserviços.
Apenas um adentro, acredito que atualmente faça mais sentido utilizar authorization bearer ao invés de x-access-token para autorização do jwt!
Sim, o cabeçalho mais comum de ser usado atualmente é o Authorization mesmo. Independente disso, o funcionamento é o mesmo. O mesmo vale para a notação ‘Bearer’ que não tem qualquer efeito prático ou diferente no funcionamento, é apenas uma convenção comum para dizer que o conteúdo do cabeçalho é um token do portador (Bearer).