Resumo

  • O rascunho individual de 28 de outubro permite ao cliente declarar endereços de duas maneiras: listar os prefixos IPv4/IPv6 em client_ip_ranges ou indicar um arquivo JSON em HTTPS por client_ip_ranges_uri. O servidor ainda precisa aceitar a lista antes de usá-la como regra de acesso.
  • Se o arquivo falhar, vier inválido ou for retirado, endereços antes barrados continuam barrados. O servidor pode manter a lista antiga, limitar seu uso aos endereços presentes também na nova e definir quando ela vence. Vencido o prazo, bloqueia o cliente até aprovar uma lista atual ou retirar expressamente o filtro.

O arquivo chegou; a autorização, ainda não

Uma empresa transfere o tráfego do cliente OAuth para outra saída de nuvem. O novo arquivo JSON responde com HTTP 200, mas o ponto de emissão de tokens ainda reconhece apenas a faixa anterior. O texto proposto trata busca e aceitação como atos distintos. O servidor valida o conjunto inteiro e decide, segundo sua política, se uma expansão pode entrar. Um prefixo amplo inserido no documento não vira passe livre por ter sido baixado.

O cliente escolhe: escreve os prefixos nos metadados ou informa a URL de um arquivo. Os dois formatos juntos invalidam a declaração. Sem nenhum dos campos, o cliente não declarou endereços. Com uma lista vazia, declarou que não há endereço algum. A RFC 7592 já trata da atualização do cliente; aqui o rascunho impede que essa lista vazia seja confundida com uma ordem de apagar o campo. Se o servidor a aceitar e aplicar, bloqueia todas as origens.

A nova lista aprovada substitui a antiga por inteiro. O rascunho não prevê adicionar endereços um por um. Enquanto a lista nova aguarda aprovação, o servidor pode manter apenas os endereços que aparecem nas duas. Assim fecha uma saída abandonada sem abrir a nova por antecipação.

O cliente deveria anunciar o novo endereço antes de enviar tráfego por ele. Também deveria conservar o antigo na declaração enquanto ainda o utiliza. O tempo entre publicar o arquivo, o servidor buscá-lo e alguém aprová-lo precisa caber no plano da mudança.

Se o arquivo falha, a catraca não se solta. Erro na busca, dados inválidos e retirada da declaração não podem liberar uma origem antes barrada. Para relaxar o controle após uma retirada, o servidor precisa de uma decisão local explícita.

O servidor deveria estabelecer por quanto tempo ainda usa a lista antiga durante uma falha, retirada ou troca pendente. Quando esse prazo termina, quem aplicava o filtro rejeita o cliente até aceitar a lista atual ou decidir encerrar a exigência. Buscar de novo uma proposta ainda não aprovada não zera o relógio.

A faixa velha também pode se tornar um problema. Um endereço que o cliente abandonou pode ser atribuído a outra parte. Reduzir a lista aos endereços em comum e limitar sua duração encurta esse risco. A RFC 9111 trata do cache HTTP. O rascunho mantém a lista aceita fora desse cache: 304 Not Modified confirma o arquivo guardado, não uma aprovação, e a expiração do cache não apaga o acesso.

Um firewall diante do endpoint vê o IP, mas não sabe qual cliente OAuth fez o pedido. Só consegue aplicar a soma das faixas de vários clientes. O servidor, depois de identificar cada cliente, pode aplicar sua lista individual. Uma origem permitida não autentica ninguém.

Se uma declaração assinada contiver apenas a URL do arquivo, a assinatura avaliza essa URL. O conteúdo que o anfitrião servirá amanhã continua sob controle dele. Uma lista vazia ou um arquivo indisponível além do prazo pode derrubar o acesso do cliente.

O registro do IETF classifica a proposta como individual, sem resultados de implantação. Num teste real, importam o arquivo baixado, o conjunto aceito, a hora da aprovação, o fim da faixa antiga e as respostas do endpoint antes e depois da mudança.

Fontes: rascunho; estado no IETF; RFC 7592; RFC 9111.