Resumo

  • O draft de Transactional Access Tokens cria um JWT curto para uma única audiência e obriga o authorization server a avaliar política a cada solicitação.
  • O perfil aceita replay de bearer durante a validade e não transforma txn em chave de idempotência, recibo de execução ou limite para refresh tokens e client credentials duráveis.

Publicado em 29 de setembro de 2026, draft-tulshi-oauth-transactional-access-tokens-00 é um Internet-Draft individual que pretende Standards Track. Ainda não é documento do OAuth WG, consenso do IETF ou RFC. As fontes não demonstram implementação, interoperabilidade ou resultado de segurança. A análise deve preservar essa incerteza.

O Txn-AT deriva do perfil JWT de RFC 9068. Ele usa txnat+jwt, exige um único resource server em aud, inclui txn e pode carregar tctx e rctx afirmados pelo authorization server. A duração recomendada entre iat e exp não passa de 300 segundos.

Cada emissão exige política. Mesmo um refresh token, client credential, source token ou handle válido pode ser recusado. Ao abrir uma transação, o servidor entrega um handle opaco com pelo menos 128 bits de entropia, vinculado ao cliente, ao sujeito e, quando aplicável, à mesma chave de sender constraint.

Esse handle solicita novos Txn-ATs para outras audiências na mesma transação. A trilha precisa separar raiz durável, decisão atual, handle, token por recurso, Transaction Token interno e efeito observado. Dizer apenas “autorizado” elimina a pergunta sobre qual camada realmente falhou.

O draft mantém consentimento e autoridade do cliente como duráveis. Um authorization code pode produzir um refresh token uma vez; solicitações posteriores dispensam nova interação. O token curto reduz o material exposto ao resource server, mas não reduz automaticamente a vida da capacidade de pedir outro token.

Por isso a avaliação precisa deixar recibo. Versão da política, sujeito, autenticação, attestation, recurso, authorization details, ambiente e frescor devem ser registrados. O servidor não pode ecoar contexto do cliente dentro de tctx ou rctx sem julgá-lo. Assinar dados velhos continua produzindo uma assinatura válida.

O txn muda por audiência. Dois resource servers não deveriam correlacionar usando apenas esse valor. Entretanto, client_id, horário, subject e contexto continuam disponíveis, e o próprio authorization server conhece o identificador interno. A privacidade é uma redução lateral, não anonimato diante do centro.

Uma derivação HMAC pode dispensar tabela, mas transforma K_txn em segredo de correlação. Rotação e retenção de chaves aposentadas definem por quanto tempo a auditoria e o vínculo continuam possíveis. Se chave e estado interno vazarem juntos, a separação entre recursos pode ser reconstruída.

O replay revela o limite mais prático. O documento aceita que um bearer Txn-AT seja repetido durante a validade para manter o resource server stateless. Recomenda DPoP ou mutual TLS e permite rastrear jti para uso único. “Permite” não é “exige”. Uma operação irreversível precisa escolher conscientemente.

Mesmo com DPoP, a mesma parte legítima pode reenviar uma requisição. txn identifica o contexto de autorização, não a semântica do efeito. A aplicação necessita de idempotency key, regra de duplicidade, receipt de commit e compensação. Em vários recursos, sucesso parcial continua sendo problema distribuído.

A separação de tipos evita downgrade somente se cada caminho a aplicar. Um endpoint Txn-AT-only deve rejeitar at+jwt; workload interno deve rejeitar Txn-AT externo no lugar de txntoken+jwt; múltiplas audiências, handle vencido, cliente ou sujeito errado devem falhar. Metadata não comprova enforcement.

O authorization server também entra no caminho crítico de toda transação. Latência de emissão soma à latência do trabalho; indisponibilidade bloqueia recursos; volume cresce com transações, não sessões. Distribuição regional abre questões de versão de política, binding de handle, chaves e sinais de replay.

A leitura coerente com uma camada fina é clara: formato e proveniência viajam; decisão permanece local e revisável; execução permanece fora do token. Txn-AT pode reduzir um grant amplo, mas só running code e receipts separados provam que a redução sobreviveu ao uso.

Fontes