Segurança Digital
JSON Web Token (JWT)
A RFC 7519 define JWT como um formato compacto para transportar claims entre partes, normalmente em três segmentos Base64url quando protegido por JWS. Um token pode ser assinado, autenticado por MAC ou cifrado por JWE; a simples presença de pontos não garante segurança. Em APIs de casa inteligente, JWT costuma carregar `iss`, `sub`, `aud`, `exp` e escopos. O critério de escolha é interoperabilidade entre serviços; sessões opacas são preferíveis quando revogação imediata e minimização de dados têm prioridade.
🛡 Níveis de Segurança
Recomendado
JWT assinado com algoritmo assimétrico
A RFC 7519 define JWT como um conjunto de claims JSON protegido por JSON Web Signature ou JSON Web Encryption. Em um caso comum, o token aparece como `header.payload.signature`, com cada parte em Base64url. O cabeçalho pode indicar `alg`, `kid` e `typ`; o payload contém claims; a assinatura cobre exatamente os dois segmentos codificados. Para arquiteturas com um emissor e várias APIs verificadoras, algoritmos assimétricos como RS256, ES256 ou EdDSA permitem que as APIs tenham apenas chaves públicas. Assim, uma API comprometida não ganha capacidade de emitir tokens. O emissor protege a chave privada em HSM, KMS ou serviço de identidade. Os verificadores obtêm chaves por JWKS autenticado, fazem cache e selecionam por `kid`. O algoritmo permitido precisa ser configurado localmente. Não confiar apenas no `alg` vindo do token. A biblioteca deve rejeitar `none`, confusão entre HMAC e RSA e chaves incompatíveis. A validação obrigatória inclui assinatura, `iss`, `aud`, `exp`, `nbf` quando presente e, conforme uso, `iat`, `jti`, `azp`, escopo e tipo. Um token válido para a API de energia não pode abrir uma fechadura. `aud` precisa conter o recurso correto. `iss` deve ser uma string exata e HTTPS quando aplicável. O clock precisa estar sincronizado; uma tolerância de dezenas de segundos pode ser usada, não minutos ilimitados. Tokens curtos, como 5–15 minutos, reduzem impacto de roubo. Refresh tokens são tratados separadamente e armazenados com maior proteção. O JWT não deve incluir senhas, chaves Wi‑Fi, vídeos ou dados pessoais desnecessários porque JWS assina, mas não esconde. Quem possui o token lê o payload.
Interoperável
JWT de acesso conforme perfil OAuth
Quando um access token JWT precisa ser consumido por recursos de diferentes fornecedores, a RFC 9068 fornece um perfil para OAuth 2.0. Ela define claims e práticas que aumentam previsibilidade. O authorization server emite, a resource server verifica. O token deve ter emissor, audiência, expiração, assunto ou client identity e informações de autorização. O recurso não deve aceitar ID Token de OpenID Connect como access token. Essa confusão é recorrente. ID Token prova autenticação ao cliente; access token autoriza acesso ao recurso. Um serviço residencial pode emitir um access token para `aud=https://api.casa.example` com `scope=lights.read lights.write`. A API valida. Para uma fechadura, usar audiência separada e escopo específico. O token precisa ser enviado por HTTPS em `Authorization: Bearer`. Não colocar em query string, logs ou URLs. Bearer significa que quem possui pode usar; portanto, proteção de transporte e armazenamento é essencial. DPoP ou mTLS podem vincular o token a uma chave e reduzir replay, conforme arquitetura. O recurso deve validar tipo explícito, como `at+jwt`, quando o perfil define, evitando token substitution. Claims customizadas precisam de namespace ou coordenação para não colidir. O serviço deve documentar. A evolução de escopos precisa ser compatível. Não emitir um token com lista ilimitada de dispositivos se o usuário controla apenas uma residência. Aplicar menor privilégio e, quando viável, identificadores de casa e função. O token não deve carregar estado volátil que muda a cada segundo; um claim de permissão fica obsoleto até expirar. Para revogação urgente, combinar expiração curta, introspecção, denylist ou sessão central.
Restrito
JWT autenticado por HMAC
HS256, HS384 e HS512 usam HMAC com segredo compartilhado. Essa opção é eficiente e adequada quando o mesmo componente emite e verifica, ou quando todos os verificadores são igualmente confiáveis. A chave precisa ter entropia suficiente; para HS256, usar pelo menos 256 bits aleatórios, não `secret`, nome da casa ou senha humana. O segredo não deve ser reutilizado em webhooks, cookies ou outros protocolos. Em uma arquitetura de microsserviços, distribuir a chave a dez APIs significa que qualquer uma pode emitir tokens válidos. Isso amplia o perímetro. Por isso, assinatura assimétrica costuma ser preferida. Se HMAC é usado, cada ambiente tem chave separada, armazenada em secret manager, com `kid` e rotação. O verificador fixa o algoritmo. Um ataque clássico ocorre quando uma biblioteca aceita token originalmente RS256 como HS256 e usa a chave pública como segredo HMAC. Bibliotecas atuais mitigam, mas a configuração precisa impedir. O token deve seguir as mesmas validações de claims. Assinatura correta não substitui audiência. Um token de teste não pode funcionar em produção. `iss` e chaves separados. A rotação pode manter chave anterior durante a vida máxima dos tokens. Após o prazo, remover. O emissor nunca envia a chave ao cliente. Um hub local que emite tokens para sua própria API pode usar HMAC, mas um aplicativo móvel distribuído não deve conter a chave de assinatura. Se contém, qualquer usuário extrai e emite.
Crítico
JWT sem validação contextual ou com vida longa
O risco mais comum não é quebrar a criptografia, mas aceitar o token errado. Verificar apenas a assinatura é insuficiente. O token pode ter sido emitido para outra audiência, outro cliente, outro ambiente ou outro tipo. O sistema precisa de regras explícitas. `exp` obrigatório e curto. `nbf` e `iat` com limites. `jti` quando existe necessidade de replay ou revogação. O cabeçalho `kid` não pode ser usado para construir caminho de arquivo ou URL arbitrária. JWKS deve vir de emissor configurado, não de `jku` fornecido pelo atacante sem allowlist. Certificados em `x5u` e chaves embutidas precisam de política. O BCP RFC 8725 orienta validação de algoritmos, tipos, audiências e regras mutuamente exclusivas. Não aceitar tokens JWT de dois perfis no mesmo endpoint sem `typ` e validação distinta. Um token com 30 dias de vida para abrir portas é perigoso. Se roubado de um celular, permanece. Use access tokens curtos e refresh token protegido. Logout não invalida JWT já emitido automaticamente. A aplicação precisa revogar sessão, manter denylist ou reduzir vida. Dados de autorização mudam: usuário removido da casa pode conservar acesso até expirar. Para ações críticas, consultar estado central ou usar token muito curto. Um token não deve crescer com centenas de dispositivos; aumenta cabeçalhos, logs e exposição. Referências opacas podem ser melhores.
🖥 Aplicações em Hardware
🔒
Hub local
Tokens de sessão para API do controlador
O hub autentica usuário por senha/Argon2id ou passkey e emite access token de 10 minutos. A API valida assinatura Ed25519 ou HMAC se monolítica, `iss=hub-id`, `aud=local-api`, expiração e escopo. O navegador usa cookie HttpOnly/Secure/SameSite por meio de backend, evitando token em localStorage. Aplicativos guardam no Keychain/Keystore. Refresh tokens são aleatórios, rotativos e armazenados hashed no servidor. Ações de fechadura exigem reautenticação ou escopo curto. O hub mantém lista de sessões. Se o usuário é removido, revoga refresh e coloca access token crítico em denylist até expirar. O relógio usa NTP, mas tolera falha sem aceitar tokens indefinidos.
🔒
Cloud IoT
Access tokens assimétricos para microsserviços
Um provedor de identidade assina com chave privada em HSM. APIs obtêm JWKS por endpoint HTTPS configurado e fazem cache. Cada API possui audiência distinta. O gateway valida na borda, mas o serviço também valida para evitar bypass. Escopos e tenant são aplicados. O `kid` seleciona chave, e a rotação publica nova antes de usar. Tokens duram poucos minutos. Refresh token fica no serviço de identidade. Logs não guardam. Um token não é usado em MQTT diretamente sem perfil; o broker pode validar via plugin, mas a audiência precisa. Para dispositivos, certificados ou tokens específicos podem ser melhores. Não emitir a mesma forma para usuário e dispositivo sem `typ` e regras separadas.
🔒
Gateway de API
Validação central e propagação controlada
O API gateway valida JWT e pode encaminhar identidade em cabeçalhos assinados ou token interno. Serviços não devem confiar em cabeçalho vindo da Internet; a rede e mTLS protegem. O gateway limita tamanho e algoritmos. Ele não substitui autorização de objeto no backend. Para integração de parceiros, usa OAuth/OIDC e tokens com audiência. Rate limiting por `sub`/client. Se o JWT é inválido, resposta genérica 401. Sem revelar chave. Métricas contam motivo. O gateway atualiza JWKS e mantém última chave durante falha temporária. Não buscar URL de chave indicada livremente no token. Issuers permitidos são configuração. Ambientes dev/prod separados.
🔒
Dispositivo IoT
Token temporário para commissioning ou API local
Um dispositivo com recursos suficientes pode aceitar token curto emitido pelo hub, assinado assimetricamente. Ele armazena chave pública e valida. Isso evita segredo de emissão dentro do dispositivo. O token inclui device ID, ação e expiração de 60 s. Para comando crítico, inclui nonce e é usado uma vez. Porém, relógio pode estar errado antes de NTP. O protocolo pode usar monotonic counter ou challenge. Não adotar JWT em microcontrolador apenas por moda: parsing JSON, Base64url e assinatura consomem memória. COSE/CBOR pode ser mais adequado em Matter e ambientes restritos. O critério é ecossistema. JWT é bom quando integra HTTP/OAuth. O firmware usa biblioteca, limita tamanho e profundidade e rejeita claims duplicadas.