요약

  • 10월 28일 개인 초안은 IPv4·IPv6 접두사를 직접 담는 client_ip_ranges와 HTTPS JSON 문서의 주소를 담는 client_ip_ranges_uri를 제안한다. 둘 중 하나만 쓸 수 있다. 등록이나 파일 다운로드가 성공해도 서버가 그 범위를 승인한 것은 아니다.
  • 다운로드 실패, 잘못된 문서, 신고 철회만으로 전에 막았던 IP를 허용할 수 없다. 서버는 기존 승인 목록을 유지하거나 검증된 새 목록과의 교집합으로 줄이고, 보유 기한을 정할 수 있다. 기한이 끝나면 현재 목록을 승인하거나 명시적으로 제한을 해제할 때까지 클라이언트 요청을 거절한다.

파일은 도착했지만 출입증은 발급되지 않았다

한 회사가 OAuth 클라이언트의 클라우드 출구를 옮긴다. 새 JSON 문서는 정상적으로 받아 왔다. 그런데 새 주소에서 보낸 토큰 요청은 여전히 막힌다. 초안은 이런 차이를 규칙으로 둔다. 파일을 가져온 사실과 그 안의 접두사를 허용하는 결정은 다르다. 문서에 갑자기 넓은 대역이 추가됐다고 HTTP 200이 접근 허가가 되지는 않는다.

신고 방식은 둘 중 하나다. 클라이언트가 IP 접두사를 메타데이터에 직접 적거나, 그 목록이 담긴 HTTPS 문서의 주소를 보낸다. 두 방식을 한꺼번에 제출하면 신고가 유효하지 않다.

아예 신고하지 않는 것과 빈 목록을 내는 것도 다르다. 전자는 두 필드가 모두 없는 상태다. 후자는 “허용할 주소가 없다”는 명시적 신고다. RFC 7592의 갱신 절차에서도 초안은 빈 배열을 필드 삭제 요청으로 취급하지 못하게 한다. 서버가 빈 집합을 승인해 적용하면 어느 출발지 IP도 통과하지 못한다.

새 목록을 승인하면 옛 목록을 통째로 교체한다. 항목을 하나씩 덧붙이는 절차는 없다. 새 목록이 검증됐지만 승인을 기다리는 동안, 서버는 두 목록에 모두 있는 주소만 남길 수 있다. 옛 출구를 먼저 닫고, 새 출구는 심사 뒤에 여는 셈이다.

클라이언트는 새 주소로 트래픽을 보내기 전에 그 주소를 신고해야 한다. 옛 주소에서 요청이 계속 나간다면 목록에서도 아직 지우지 말아야 한다. 문서 재조회 주기와 승인 대기 시간까지 이전 일정에 넣어야 하는 이유다.

문서가 고장 나도 문이 자동으로 열리지는 않는다. 조회나 검증이 실패해도 전에 차단한 주소는 계속 차단해야 한다. 신고 철회 뒤 제한을 풀 때도 현지 정책의 명시적 결정이 필요하다.

서버는 옛 목록을 얼마 동안 유지할지 기한을 정해야 한다. 조회 실패, 철회, 새 목록 승인 대기가 그 시계를 움직인다. 기한이 지나면 현재 목록을 승인하거나 제한을 명시적으로 없앨 때까지 요청을 거절한다. 아직 승인하지 않은 목록을 다시 검사해도 기한은 새로 시작되지 않는다.

옛 목록을 오래 붙잡는 것도 위험하다. 클라이언트가 떠난 주소가 다른 사용자에게 재할당될 수 있기 때문이다. 교집합과 보유 기한은 그 주소가 계속 통과할 수 있는 시간을 줄인다. RFC 9111의 HTTP 캐시와 서버가 승인한 IP 집합은 별개 상태다. 304 Not Modified는 저장된 응답의 재확인이지 새로운 정책 승인이 아니다.

토큰 엔드포인트 앞의 방화벽은 출발지 IP는 보지만 어느 OAuth 클라이언트인지 알지 못한다. 여러 클라이언트 범위를 합친 규칙만 걸 수 있다. 인가 서버는 클라이언트를 식별한 뒤 개별 집합을 적용한다. IP 일치는 인증이 아니다. 서명된 선언에 문서 URL만 들어 있다면 서명이 보증하는 것도 URL일 뿐, 호스팅 업체가 나중에 내놓을 파일 내용은 아니다. 업체가 빈 목록을 내거나 파일을 오래 중단하면 클라이언트는 막힐 수 있다.

IETF 기록에는 개인 제안으로 올라와 있으며 실운영 측정 결과는 없다. 실제 이전 시험에서는 받아 온 파일 버전, 승인 집합, 승인 시각, 옛 범위의 종료 시각, 전후 토큰 요청 결과를 함께 보여줘야 한다.

자료: 초안; IETF 상태; RFC 7592; RFC 9111.