Resumo

  • O atacante pode iniciar o fluxo legítimo no próprio equipamento, repassar o código ou endereço verdadeiro à vítima e receber um token válido quando ela autentica e aprova no servidor oficial.
  • A evidência decisiva liga iniciador, cliente, aparelho de consumo, recurso, escopo, ação e consequência antes do consentimento; depois, acompanha token, revogação e encerramento em cada recurso dependente.

Um falso atendente diz que precisa ativar um terminal. Ele fornece um código recém-gerado. A funcionária abre a página oficial no celular, conclui MFA resistente a phishing e aprova. O terminal citado não participa da operação: quem pediu o código foi um cliente aberto pelo atendente em outro lugar.

Não houve cópia de credencial. O servidor executou exatamente o protocolo previsto. A confiança foi atribuída ao fato errado.

RFC 10027, BCP 247 publicado em agosto de 2026, separa autorização entre dispositivos de transferência de sessão e descreve ataques entre protocolos e dentro de um mesmo protocolo. Em comum, eles exploram o canal de contexto não autenticado entre o Dispositivo de Consumo, que inicia, e o Dispositivo de Autorização, onde a pessoa confirma.

Código curto não é contexto autenticado

No RFC 8628, o cliente obtém device code e user code, mostra um endereço de verificação e consulta o servidor enquanto a autorização acontece em outro aparelho. Isso atende televisores, consoles e terminais limitados. Também permite que a referência humana seja transportada por qualquer narrativa.

Expiração curta, unicidade e uso único combatem adivinhação e repetição. O atacante ao vivo pode esperar a vítima aceitar a história, gerar o código naquele instante e aproveitar a primeira aprovação. O estado global de antirreplay ainda pode trocar disponibilidade por consistência.

OAuth 2.0 distingue cliente, proprietário, servidor de autorização e servidor de recursos. PKCE vincula a troca do código ao cliente que possui o verificador; não prova que a pessoa pretendia autorizar esse cliente. Se ele é do atacante, a proteção preserva com rigor o destino errado.

A passkey prova a origem web, não o sentido da decisão

WebAuthn nível 3 pode autenticar a pessoa no domínio legítimo com resistência a phishing. Essa é uma afirmação forte sobre identidade e origem. Não identifica automaticamente o aparelho remoto, o solicitante, o recurso, o escopo nem o efeito irreversível que a pessoa imaginou.

Por isso RFC 10027 recomenda o fluxo de dispositivo somente quando limitações inviabilizam alternativas melhores e orienta evitá-lo para recursos sensíveis, valiosos ou críticos. Pré-registro do aparelho de consumo e autenticar antes de iniciar podem impedir que um cliente arbitrário crie o pedido.

Proximidade aumenta atrito, mas não é identidade. Wi-Fi e rede móvel podem distorcer distância; VPN, retransmissão e falsificação podem aproximar o que está longe; localização detalhada cobra privacidade. Confirmação fora de banda só acrescenta prova quando os fatos exibidos estão ligados ao mesmo request ID e não são apenas outro segredo repassável.

O token pode estar bem protegido e mal concedido

DPoP restringe o token à chave do cliente, reduzindo o valor de uma cópia. Se o invasor controla o aparelho autorizado e a chave, DPoP garante que o poder concedido por engano continue naquele aparelho. As práticas do RFC 9700 fortalecem OAuth sem recriar a intenção humana ausente.

OpenID CIBA elimina a transferência do código visível e reduz essa exposição. Ainda admite que um solicitante com o identificador do usuário provoque uma notificação; pedidos em massa, fadiga e falso suporte continuam relevantes.

Na resposta, introspecção, revogação e eventos CAEP oferecem peças diferentes. Um endpoint de revogação responder “sucesso” ou um evento ser emitido não prova que caches, tokens derivados e sessões dos servidores de recursos terminaram.

Um livro-razão do pedido

Registrar request ID, horário e iniciador; client ID e versão; identidade, registro e confiança do aparelho de consumo; aparelho de autorização e método; hash, canal e validade do código; sinais de proximidade; e a apresentação exata de solicitante, equipamento, recurso, escopo, ação, destino e consequência.

Após a aprovação, ligar família de tokens e chave de confirmação aos usos em cada recurso. Guardar recusas, anomalias, introspecções, revogações, entrega e confirmação CAEP e evidência positiva do fim da sessão. Autenticar a pessoa, confiar no aparelho solicitante e concluir a recuperação são estados separados.

Na primazia do código em execução de Heng Lu, cliente e recurso que exercem o token decidem a realidade operacional. A especificação inicial mínima com decisão futura localizada sustenta um contrato comum de evidência, deixando cada produto escolher confiança, proximidade ou fluxo no mesmo aparelho. A diferença entre controle formal e prático fecha o circuito: o servidor concede o direito formal; chave e sessão dão o controle prático.

O celular confirmou quem apertou o botão. Falta confirmar quem receberia o poder.