Resumo

  • A RFC 7662 permite que um recurso protegido pergunte ao servidor de autorização sobre o estado atual de um token e receba atributos pertinentes àquele recurso.
  • active: true é uma conclusão relevante sobre a credencial, não a aprovação de uma operação específica, um registro de execução ou um recibo durável.
  • Armazenar respostas em cache troca carga e latência por atualidade; estado do token, decisão de acesso e efeito da aplicação precisam de evidências próprias.

O que exatamente recebeu sinal verde

Um servidor de recursos nem sempre consegue avaliar sozinho o token que chega. O formato pode ser opaco, a lista de revogações pode estar em outro domínio ou a decisão depender de estado mantido pelo servidor de autorização. Na introspecção, o recurso apresenta o token a esse servidor e recebe um objeto com a propriedade obrigatória active. Se ela vier verdadeira, a resposta pode trazer escopo, cliente, usuário, tipo de token, datas, público e emissor.

Não se trata de um ping sofisticado. A RFC 7662 diz que um token ativo, em geral, foi emitido pelo servidor consultado, não foi revogado e permanece dentro do intervalo de validade. O servidor de autorização deve fazer as verificações aplicáveis, como expiração, instante de início, revogação, assinatura e possibilidade de uso no recurso protegido que fez a consulta. Esse resultado tem valor operacional concreto.

Seu limite está no objeto analisado. O servidor de autorização conhece a credencial e a concessão. Normalmente não conhece o saldo atualizado, o proprietário de cada registro, o limite diário, o bloqueio regulatório ou a versão do objeto que a solicitação pretende mudar. Essas condições pertencem ao recurso protegido.

Assim, um token com escopo de escrita pode estar ativo e ainda não autorizar aquela escrita. A conta pode pertencer a outro locatário, o usuário pode precisar de autenticação adicional ou a ação pode estar suspensa naquele horário. O resultado de introspecção chega antes da política local, não depois dela.

A interface de Richer mantém duas responsabilidades

Justin Richer é o autor identificado na RFC 7662, documento Standards Track da IETF sobre introspecção de tokens OAuth 2.0. A atribuição não deve virar mito de autoria individual: o documento é resultado do processo de padronização da IETF e não dá a Richer controle sobre implementações ou decisões de operadores.

O protocolo põe em contato dois tipos de autoridade. O servidor de autorização pode afirmar quando e para quem emitiu um token, se ele expirou, se foi revogado e que atributos carrega. O servidor de recursos conhece a solicitação concreta, o objeto atingido e as regras locais. Ao consultar o primeiro, o segundo não terceiriza seu dever de decidir.

A divisão já aparece no modelo de papéis do OAuth. O cliente apresenta o token de acesso ao servidor de recursos; esse servidor valida a credencial e atende a solicitação quando suas condições forem satisfeitas. A RFC 6750 descreve esse uso para tokens ao portador. A introspecção padroniza uma fonte de fatos de validação, mas não escreve a regra que transforma escopo, sujeito e público em permissão sobre cada objeto.

Uma trilha de auditoria precisa registrar as duas etapas. Quem declarou o token ativo, em que momento e para qual recurso? Qual versão da política local permitiu ou negou qual ação? Resumir ambas como “autorizado” produz um painel simples e uma investigação impossível.

A resposta carrega o contexto de quem perguntou

A introspecção não precisa revelar um dossiê idêntico a todos os consumidores. A RFC 7662 permite que o servidor de autorização ajuste a resposta ao recurso protegido solicitante. Ele pode, inclusive, devolver apenas os escopos pertinentes àquele recurso. Isso reduz exposição e reconhece que a utilidade da credencial depende do destino.

Uma resposta observada pelo serviço A, portanto, não prova o que o serviço B poderia ver ou fazer. A identidade de quem consultou, o público, o horário e os campos efetivamente devolvidos fazem parte da evidência. Respostas diferentes podem ser deliberadas e corretas.

A RFC 8707 ajuda a separar outro par de conceitos. O indicador de recurso informa onde se pretende usar o token; o escopo expressa que tipo de acesso é solicitado. Destino e permissão se complementam, mas nenhum deles é um resultado de aplicação.

Os atributos opcionais também não mudam de função só porque são úteis em logs. exp e nbf marcam limites temporais. aud e iss identificam público e emissor. sub, username e client_id podem apontar para atores diferentes. jti identifica o token. Como uma única credencial costuma acompanhar muitas chamadas, o jti não é chave de pedido, de pagamento ou de execução.

O presente armazenado em cache envelhece

Consultar o servidor de autorização em cada requisição aumenta a carga e coloca uma viagem de rede no caminho crítico. A RFC 7662 permite cachear respostas e, ao mesmo tempo, explicita a troca: o ganho de desempenho reduz a atualidade da informação.

Considere uma resposta ativa obtida às 10h e mantida por cinco minutos. Às 10h01, o titular revoga o token pelo mecanismo da RFC 7009, ou um administrador encerra a concessão. Até o cache expirar, o recurso pode agir com base na fotografia antiga. O servidor de autorização conhece o novo estado; o recurso segue o estado que sua própria política permitiu conservar.

O TTL passa a ser uma escolha de segurança. Ele deve considerar duração do token, promessa de revogação, sensibilidade da ação, disponibilidade do servidor e custo de uma admissão desatualizada. A leitura de um catálogo público e a troca de credenciais de recuperação não deveriam receber a mesma janela apenas porque usam o mesmo cliente de introspecção.

Revogação também não desfaz o que já ocorreu. A RFC 7009 invalida tokens e pode afetar concessões ou tokens relacionados conforme a implementação. Ela não reverte um valor liquidado fora do sistema, não recolhe um segredo já exposto e não apaga uma mensagem entregue. Impedir o próximo uso e reparar o efeito anterior são trabalhos distintos.

Depois da autorização ainda existe o resultado

Mesmo quando o recurso autoriza a solicitação, a execução pode terminar de modo ambíguo. O serviço falha antes do commit ou grava a mudança e perde a resposta. Uma fila aceita o comando, mas o consumidor o rejeita mais tarde. O cliente repete a chamada com o mesmo token ainda ativo, e duas solicitações válidas podem representar uma intenção só.

Nenhum campo de introspecção resolve essa incerteza. Escopo descreve uma classe de acesso. jti agrupa usos de um token. O sucesso da própria introspecção demonstra apenas que atributos foram entregues. Não é recibo da operação de negócio.

APIs de consequência precisam de identidade durável no nível da aplicação: chave de idempotência, ID de comando, versão condicional ou outro mecanismo do domínio. Também precisam permitir a consulta do desfecho depois de um timeout. Validação da credencial, decisão local, identidade da operação, resultado do commit e entrega da resposta podem ser correlacionados, mas não substituídos uns pelos outros.

Ler a RFC 7662 com rigor não diminui a introspecção. Preserva a força de uma resposta padronizada a uma pergunta difícil e delimitada. Quando o sistema para de pedir que o token explique decisões que nunca observou, fica claro onde cada decisão realmente precisa existir.

Fontes