Resumo

  • “Ativo” na RFC 9767 reúne emissão, revogação, tempo, método de prova, destinatário e acesso solicitado no contexto assinado pelo servidor de recursos.
  • O servidor de autorização avalia o token; o servidor de recursos valida a apresentação corrente, aplica política própria e escolhe a resposta concreta.
  • A trilha confiável tem quatro comprovantes: introspecção, prova da mensagem, decisão local e efeito observado, além da idade do cache e da custódia de tokens derivados.

Uma resposta com endereço

O cliente entrega um token ao servidor de recursos, o RS. Para saber como tratá-lo, o RS consulta o servidor de autorização, o AS. Quem assina essa consulta é o próprio RS, com sua chave, e não o cliente ou a chave vinculada ao token.

O pedido leva o valor recebido, a identidade do RS e, de modo recomendado, o método usado pelo cliente para provar a apresentação. Pode também declarar o acesso mínimo exigido pela operação. O AS deve considerar todos os parâmetros; se não conseguir interpretar uma parte, não pode marcar o token como ativo.

Essa moldura impede que o booleano viaje sozinho. Um token pode servir para RS1 e não para RS2, permitir leitura sem permitir escrita, estar dentro do prazo mas chegar com uma prova incompatível. A pergunta e a resposta formam um par.

A RFC 9767 complementa o núcleo GNAP. A RFC 9635 organiza a negociação do grant entre cliente e AS; a extensão conecta AS e RS em implantações desacopladas. A interface comum transporta fatos sem transformar o AS no operador de todos os recursos.

Até o cadastramento da chave do RS fica fora do escopo. Pré-registro e confiança no primeiro uso são opções de implantação. A assinatura comprova posse dentro do modelo adotado; não certifica que o cadastro atribuiu corretamente cada recurso nem que o RS decidirá corretamente depois.

O que cabe em active

O positivo exige uma conjunção: emissão pelo AS que responde, ausência de revogação, prazo válido, vínculo pelo método de prova indicado, adequação ao RS identificado e cobertura do access informado.

O negativo não é um diagnóstico único. Token ausente, estado indeterminado, expiração, revogação, audiência errada ou acesso insuficiente podem resultar em false. Os outros campos são omitidos. Registrar todo false como “revogado” acrescenta uma certeza inexistente.

O true também não aprova corpo, intenção humana, saldo, objeto, risco de fraude ou resultado. Ele afirma que o token passou pelas condições representadas naquela consulta. Nada diz, sozinho, sobre a ação posterior.

Uma resposta ativa pode trazer direitos, chave, flags e tempos. Os direitos podem ser filtrados para o RS e até formar uma lista vazia. O valor do token não deve aparecer na resposta. Essa projeção limitada reduz exposição, mas também significa que a visão de um RS não é o grant completo.

Quem opera decide

Depois da introspecção, a RFC 9767 entrega ao RS a escolha do curso apropriado. Direitos insuficientes podem produzir erro ou um recurso público. A resposta final permanece sob a discrição do RS.

É a alocação correta de autoridade. O AS conhece emissão, grant e revogação. O RS conhece método, endpoint, estado do objeto, controles locais e alternativas que consegue executar. A decisão deve ficar no ponto de efeito.

Discrição não dispensa recibo. O registro local deve nomear recurso, operação, direitos considerados, política e versão, outros controles, software e resposta escolhida. Entregar conteúdo público após falta de direito privado não é uma autorização privada bem-sucedida.

O efeito vem depois. Uma escrita pode ser confirmada e a resposta se perder; pode ser aceita e falhar no banco; um HTTP 200 pode carregar erro de aplicação. O resultado de introspecção não observou nenhum desses estados.

Duas verificações

Token ligado a chave não reduz tudo a uma assinatura. O RS verifica o token e também a prova da mensagem atual. Uma chave comprometida pode assinar corretamente uma operação fora dos direitos. E um token ativo não prova que esta requisição contém o nonce, alvo e componentes assinados exigidos.

A RFC manda validar o proof de forma independente em cada chamada e não reutilizar de cache o resultado de outra mensagem. HTTP Message Signatures, DPoP e tokens ligados a certificado são mecanismos distintos; nenhum aplica a regra de negócio do RS.

O comprovante de prova precisa indicar a mensagem, os componentes cobertos, chave, algoritmo, dados de frescor e resultado. Ele não deve ser fundido com o ID da introspecção num campo genérico authorized.

Cache é política temporal

Introspecção remota custa latência e disponibilidade. O RS pode guardar o resultado, obtendo desempenho em troca de informação menos viva e precisa. Enquanto usa um positivo antigo, pode aceitar um token já revogado.

O TTL é uma decisão do operador do recurso. Ele define por quanto tempo um fato passado do AS substitui a situação presente. Leitura pública e pagamento irreversível não deveriam herdar por acaso a mesma janela de uma biblioteca.

A chave de cache tem de incluir o contexto: token, RS, método de prova e acesso solicitado quando relevante. Indexar só pelo token amplia uma resposta estreita. Cache negativo também pode ocultar recuperação, pois false inclui incerteza.

A RFC 7009 descreve revogação no AS, não a invalidação comprovada em cada RS. A RFC 9767 cita sinal proativo como possibilidade fora de escopo. Fechar o ciclo exige evento de invalidação, entradas afetadas e uma decisão posterior que mudou.

Menos exposição não é invisibilidade

O AS pode filtrar claims para que cada RS veja apenas o necessário. Isso evita, por exemplo, mostrar um identificador médico a um serviço não médico. Em compensação, cada introspecção informa ao AS que aquele token foi usado naquele RS e naquele horário.

Tokens estruturados permitem validação local e reduzem a trilha ao vivo no AS, mas podem distribuir mais atributos e atrasar revogação. Tokens opacos concentram conhecimento e chamadas no AS. O projeto deve declarar simultaneamente seu orçamento de frescor e de divulgação.

Chaves assimétricas e simétricas também não oferecem o mesmo risco. Uma chave pública de verificação não cria assinatura privada. Um segredo simétrico entregue ao RS pode permitir nova apresentação. “Vinculado à chave” não basta para explicar reuso.

A referência de recursos deve continuar opaca. Se cliente ou RS inferirem estrutura, nasce dependência acidental e vazamento. Valor aleatório ou cifrado mantém o identificador como referência ao conjunto guardado no AS, não como direito autônomo.

O salto seguinte abre outro livro

Se RS1 precisa chamar RS2, repassar o bearer token mistura atores e amplia exfiltração. RFC 9767 permite pedir token derivado: RS1 apresenta existing_access_token, identifica-se como cliente com chave própria e assina novo pedido.

O AS confirma que o token de entrada era apropriado para RS1 e pode emitir outro, mais restrito, com audiência RS2 e vínculo a RS1. A operação pode se repetir adiante.

Derivação não preserva efeito. O token de RS2 não comprova que RS1 entendeu o pedido, que RS2 executou ou que a resposta voltou. Assim como no OAuth Token Exchange, cada novo artefato requer contabilidade de ator, sujeito, audiência e escopo.

Quatro comprovantes

O primeiro guarda pergunta de introspecção, identidade assinada, resposta, tempo e cache. O segundo guarda a prova desta mensagem. O terceiro registra política e decisão do RS. O quarto registra commit, confirmação a jusante, entrega ou compensação.

Testes devem romper cada junção: token certo no RS errado; acesso além do permitido; parâmetro desconhecido; proof repetido; positivo em cache depois da revogação; direitos filtrados vazios; commit com resposta perdida; token de entrada usado diretamente no RS2. O sistema passa quando cada camada falha dentro de seu limite sem inventar a camada seguinte.

Fontes