Resumo

  • O RFC 9701 permite que um servidor de recursos autenticado receba introspecção OAuth como JWT assinado e, opcionalmente, cifrado, com emissor, audiência, data de criação e estado do token em objeto aninhado.
  • A proteção criptográfica precisa ser ligada à autorização do solicitante, tipo, frescor, audiência e escopo internos, base de divulgação, controle de repetição, regra local e operação realmente concluída.

Uma resposta pode ser assinada pelo emissor esperado, cifrada com a chave pública do servidor correto e ainda conter dados que não deveriam ter sido liberados. A criptografia funcionou. A política de divulgação falhou. RFC 9701 separa esses resultados ao exigir que o servidor de autorização conheça o solicitante e limite o conteúdo para ele.

O mecanismo amplia a introspecção de token do RFC 7662. A resposta JSON passa a poder ser um JWT criptograficamente protegido, útil quando o servidor de recursos precisa atribuir a declaração ao servidor de autorização. É um recibo mais forte sobre o estado do token, não uma permissão automática.

O direito de perguntar vem antes da resposta

O servidor de autorização deve identificar, autenticar e autorizar o servidor de recursos. Uma conexão TLS ou o conhecimento do endpoint não basta. O chamador precisa ser uma identidade administrada, com credenciais limitadas e relação demonstrada com a audiência do token.

O registro dinâmico do RFC 7591 é uma forma de manter identidade, método de autenticação e chaves, tratando o servidor de recursos como cliente. O padrão não obriga essa arquitetura, mas obriga o resultado: um servidor não autorizado não recebe dados de token.

Token inválido, expirado, revogado ou destinado a outro recurso produz active:false sem outros membros. Para um token ativo, o scope deve ser reduzido ao necessário para aquele servidor. Claims pessoais seguem política e base legal específicas. A mesma credencial pode produzir respostas legítimas diferentes conforme o destinatário.

A audiência do envelope não é a audiência do token

O servidor pede application/token-introspection+jwt; a resposta declara o mesmo tipo e o header usa typ: token-introspection+jwt. No topo ficam iss, aud, iat e token_introspection.

O aud externo determina quem pode consumir a resposta. Um aud interno descreve onde o token de acesso foi destinado a funcionar. O iat externo data a resposta; tempos internos pertencem ao token. Perder essa estrutura é aplicar uma verificação correta ao objeto errado.

O RFC desaconselha sub e exp no topo e afirma que o JWT retornado não é uma representação alternativa do token introspectado. Os registros de OAuth, JWT e mídia normalizam nomes; não impedem que uma biblioteca achate os contextos.

Assinar e cifrar são controles diferentes

O objeto é assinado ou assinado e depois cifrado como Nested JWT. JWS registra a assinatura, JWE restringe a leitura e JWT define o contêiner. O sistema local ainda escolhe emissores, chaves, algoritmos, rotação e idade aceitável.

Metadados do RFC 9701 configuram algoritmo de assinatura, algoritmo de cifragem da chave e cifragem do conteúdo. O servidor de autorização pode publicar suporte segundo RFC 8414. Capacidade publicada não comprova o algoritmo usado. Um kid encontrado não comprova que a chave estava autorizada nessa versão de política.

O recibo deve guardar hash da resposta, typ, emissor, key set e versão, algoritmos, resultado da assinatura, chave destinatária e resultado de decifragem. Só então é possível distinguir erro de formato, confiança, configuração e audiência.

Um JWT autêntico pode ocupar o canal errado

Resposta de introspecção e access token JWT podem ter formato, emissor e claims parecidos. Se o gateway aceitar qualquer JWT assinado, a resposta pode ser apresentada como token. O typ dedicado e o objeto aninhado reduzem essa cross-JWT confusion; RFC 8725 exige perfis de validação separados.

Cada entrada precisa de tipo, claims mínimos, emissor, audiência e algoritmos próprios. Decifrar o objeto não muda sua finalidade. A resposta também não limita o token ao apresentador. As medidas contra replay do RFC 9700, incluindo restrição por remetente quando adotada, continuam independentes.

active:true envelhece

O iat externo torna a idade observável, mas não define cache universal. Revogação, expiração, mudança de escopo ou política podem ocorrer logo depois. A assinatura velha continua sendo prova histórica válida e, ao mesmo tempo, evidência operacional insuficiente.

O servidor de recursos define idade máxima por operação. Depois avalia regras próprias: bloqueio do objeto, suspensão, limite financeiro, aprovação reforçada, restrição regional e prova de posse. scope=write é entrada, não decisão. Um allow sem efeito durável também não prova execução.

A privacidade não termina na chave de cifragem

O RFC 9701 exige base legal para dados pessoais e aplicação contínua dessa base. Cifrar para um servidor não prova minimização, finalidade nem retenção apropriada. RFC 9325 protege o TLS; não governa o dado após a entrega.

A consulta revela ao servidor de autorização quando o cliente ou usuário usa o servidor de recursos. Se essa observação for inaceitável, deve-se usar outro modo de transportar os dados do token. A introspecção cria um ponto de controle e também um ponto de telemetria.

A cadeia completa liga fingerprint do token, operação, identidade/autenticação do solicitante, endpoint e TLS, bytes, type, key, assinatura, decifragem, envelope, estado interno, escopo, base de divulgação, antirreplay, política local e efeito. Não há um único “sucesso” capaz de representar tudo.

A especificação inicial mínima de Lu Heng deixa na camada comum o formato e os claims necessários à interoperabilidade, preservando confiança, frescor, privacidade e autorização como decisões locais. As camadas de realidade separam registro, JWT, assinatura, estado, decisão e efeito. A primazia do código em execução exige a trilha do verificador e do enforcement, não um selo de compatibilidade.

Fontes