Resumo

  • draft-ietf-oauth-deferred-token-response-00 usa um deferral_code vinculado ao remetente para representar uma solicitação pendente; o código não é token de acesso nem concede acesso.
  • O endpoint RFC 7009 retorna HTTP 200 quando cancela e quando nada altera. A descoberta de suporte e o poll posterior com access_denied são evidências diferentes.
  • Um token já entregue é outra credencial, com vida própria. Cancelar o código diferido não o revoga e não prova o encerramento da operação no recurso.

Uma resposta correta pode sustentar uma conclusão errada

O endpoint de revogação OAuth evita revelar se o valor apresentado era válido. Essa propriedade reduz a utilidade do endpoint para quem tenta enumerar credenciais. Ela também impede que um operador use o código HTTP como espelho do estado interno.

A revisão 00 de Deferred Token Response trata decisões de token que levam mais tempo que a requisição original: análise humana, fraude ou verificação externa. Quando o cliente aceita o modo diferido e o servidor o escolhe, o endpoint de token devolve HTTP 400 com authorization_pending, um código opaco, sua validade e o intervalo mínimo de consulta.

O código representa uma única solicitação pendente. Não é access token, refresh token ou authorization code. Se a origem usou DPoP ou certificado mTLS, a mesma chave ou certificado restringe o código. Copiar a sequência não transfere a identidade do remetente.

O texto é um Internet-Draft ativo do grupo OAuth, não um RFC nem evidência de implantação. Seu valor aqui é mostrar onde cada autoridade começa e termina.

O campo se repete, a vida não

O primeiro expires_in mede a vida do código diferido. Depois do prazo, o servidor responde expired_token. Uma resposta final bem-sucedida pode trazer outro expires_in, agora para o access token. Misturar os dois faz o monitor agendar a renovação da credencial errada.

O interval é entregue uma vez e precisa permanecer no estado do cliente. Os polls pendentes não repetem o valor; slow_down acrescenta pelo menos cinco segundos. Um log que conserva apenas a resposta mais recente não consegue provar que o ritmo foi respeitado.

Tempo só vira evidência quando continua ligado ao objeto e ao observador: código, token, cliente, chave e transição.

Callback não é entrega de token

O cliente pode registrar um endpoint HTTPS para notificação. O servidor envia callback quando a solicitação termina por sucesso, erro ou cancelamento. O corpo não leva token nem resultado; apenas informa que um poll agora encontrará a resposta final.

Um token de notificação exclusivo autentica o remetente. Sem ele, são necessárias outras proteções e o callback deve ser tratado como indicativo até a confirmação. Mesmo autenticado, ele não distingue aprovação de recusa.

A recomendação é continuar consultando no intervalo definido. O callback reduz latência, enquanto o poll resiste a perda, atraso ou supressão da mensagem. Se o consumidor transformar o despertar em decisão, elimina justamente a independência dos dois caminhos.

O mesmo 200 cobre cancelamento e ausência de efeito

Para cancelar, o cliente envia o código exato ao endpoint de revogação e deve indicar o tipo deferral-code. Quando o valor é reconhecido e pertence ao cliente, o servidor muda atomicamente a solicitação para cancelled, suprime o callback cuja entrega ainda não começou e faz o próximo poll retornar access_denied.

Um valor desconhecido, de outro cliente, já resgatado, cancelado ou expirado também recebe HTTP 200, sem mudança. O comportamento vem do RFC 7009 e preserva a indistinguibilidade.

A revisão 00 cria revocation_endpoint_token_type_values_supported. O servidor que suporta cancelamento do código deve listar esse tipo. Quem não lista ainda responderá 200 para qualquer revogação. O próprio texto alerta que pular essa descoberta pode deixar o cancelamento falhar em silêncio.

O encadeamento correto começa com o snapshot dos metadados, passa pela requisição e sua resposta de transporte e termina no poll com access_denied. O 200 é um recibo intermediário.

A fronteira de entrega decide o que sobrevive

Se a análise já terminou com sucesso, mas o token ainda não foi entregue, o cancelamento marca o código como resgatado e depois cancelado. Nenhum token sai, e a consulta recebe access_denied.

Se o token já chegou ao cliente, cancelar o código não deve revogá-lo. São credenciais independentes. Quem precisa interromper acesso tem de revogar o token separadamente e, conforme o risco, observar a rejeição no resource server.

Há ainda o callback em trânsito. A obrigação de suprimir vale só antes do início da entrega. Uma notificação tardia pode coexistir com cancelamento correto e não pode reabrir o fluxo.

Por isso, “cancelado” precisa dizer em qual lado da entrega ocorreu: ainda pendente, resolvido sem entrega ou token entregue. A decisão de resposta depende dessa posição.

O consentimento pode mudar durante a espera

O código diferido pode durar horas ou dias. Nesse tempo, o titular pode retirar consentimento, a sessão pode terminar e o cliente pode ser desativado. Antes da emissão, o servidor deve reavaliar essas condições e negar se deixaram de valer. A aprovação externa não substitui autorização atual.

Depois da emissão, o resource server ainda aplica escopo e política local. Um token válido não prova que uma operação específica foi aceita; aceitação tampouco prova conclusão do processo de negócio.

Um recibo pequeno preserva a corrida

O registro local deve guardar emissor e digest dos metadados de suporte, cliente e referência à chave de vinculação, correlação unidirecional do código, horários, validade, intervalo, tentativas de cancelamento, poll final, situação do callback e se a resposta de token ultrapassou a entrega.

Não se deve colocar o código secreto em logs comuns. O draft pede proteção equivalente à de refresh tokens. Se houve entrega, acrescente a revogação separada; se há risco operacional, acrescente admissão no recurso e resultado controlado.

Essa forma é uma especificação inicial mínima, não um cadastro central de cancelamentos. Ela permite comparar evidências mantendo armazenamento, acesso e remediação locais.

Pelas camadas de realidade de Lu Heng, o 200 é mensagem, cancelamento é transição, access_denied é observação do protocolo, revogar o token é outro evento e a operação no recurso é o resultado executável. A prova fica mais forte quando desce para código em funcionamento, não quando o primeiro sinal é copiado por mais painéis.

Fontes

  1. Deferred Token Response rev00
  2. Histórico da DTR
  3. DTR rev00 HTML
  4. DTR rev00 texto
  5. RFC 6749 — OAuth 2.0
  6. RFC 7009 — Revogação OAuth
  7. RFC 8628 — Device Authorization Grant
  8. RFC 8693 — Token Exchange
  9. RFC 8705 — OAuth mTLS
  10. RFC 9449 — OAuth DPoP
  11. RFC 9700 — Práticas de segurança OAuth
  12. Parâmetros OAuth da IANA
  13. Lu Heng — Minimum Initial Specification
  14. Lu Heng — On Reality Layers
  15. Lu Heng — Running Code Primary