HTTP 407과 401: 어느 쪽 로그인이 실패한 걸까

407은 프록시에 인증하라는 응답입니다. 401은 대상 리소스에 인증하라는 뜻입니다. 한 요청에서 둘 다 만날 수 있으므로 비밀번호를 제공하기 전에 누가 요구하는지부터 확인하세요.

상태 코드와 인증 요구 헤더 비교하기

상태 코드는 중요한 첫 단서지만 전체 교환을 살펴봐야 합니다. 페이지 본문에 407이 표시된 것은 실제 HTTP 407 응답과 같지 않습니다. 마찬가지로 사용자 정의 웹 로그인 페이지는 200을 반환하면서도 애플리케이션 계층에서 사용자 인증을 요구할 수 있습니다.

HTTPS 요청이 웹사이트에 도달하기 전에 407로 실패하는 이유

일반 HTTP 프록시로 HTTPS 요청을 보낼 때 클라이언트는 보통 먼저 CONNECT 터널을 만들어 달라고 요청합니다. 프록시는 그 CONNECT 요청에 인증을 요구할 수 있습니다. 인증이 완료되지 않으면 터널을 통한 목적지 TLS 세션도 아직 수립되지 않았으므로, 웹사이트 API 토큰을 바꿔서 이 단계를 고칠 가능성은 낮습니다.

자세한 출력을 켜서 인증 요구가 어디서 나타나는지 확인하세요.

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

로컬 리스너를 자신의 프록시로 바꾸고 로그의 첫 인증 요구를 읽으세요. CONNECT 중의 407은 목적지 TLS보다 먼저 발생합니다. 터널이 성공적으로 만들어진 뒤에는 401이 나타날 수도 있습니다.

프록시 인터페이스로 프록시 자격 증명 제공하기

신뢰하는 관리자가 제공한 엔드포인트와 계정이라면, curl이 프록시 인증 방식을 협상하고 빠진 비밀번호를 입력하라는 프롬프트를 표시할 수 있습니다.

curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/

예제 엔드포인트와 사용자 이름을 사용 허가를 받은 서비스 정보로 바꾸세요. 사용자 이름만 지정하면 위 명령에 비밀번호를 직접 넣지 않아도 됩니다. 특정 curl 빌드와 프록시가 지원하는 인증 방식은 다를 수 있으므로 협상에 실패하면 실제 인증 요구와 빌드의 지원 기능을 확인하세요.

프록시 인증 옵션은 curl의 원본 서버 사용자 인증 옵션과 별개입니다. 프록시의 인증 요구를 대신하려고 원본 서버용 Authorization 헤더를 추가하지 마세요. 프록시 자격 증명 헤더를 무관한 요청에 수동으로 전달하거나 애플리케이션 전체에서 재사용하는 헤더에 저장하는 것도 피하세요.

프록시가 계속 407을 반환한다면

• 의도한 프록시 호스트와 포트를 쓰는지 확인하세요.
• Basic 인증이라고 가정하지 말고 프록시가 알리는 인증 방식을 확인하세요.
• 계정 상태와 서비스가 특정 사용자 이름 형식을 요구하는지 확인하세요.
• 자격 증명이 URL에 들어 있다면 특수 문자가 어떻게 전달되는지 확인하세요.
• 브라우저에 통합된 기업 인증 설정에 런타임이나 플랫폼 지원이 필요한지 확인하세요.
• 클라이언트 측 증거가 부족하면 관리자에게 민감한 정보를 제거한 요청 식별자나 서버 로그 항목을 요청하세요.

로그인이 성공했어도 403이나 CONNECT 거부는 접근 정책에 따른 결정일 수 있습니다. 비밀번호를 더 시도해도 금지된 목적지에 접근 권한이 생기지는 않습니다.

목적지의 HTTPS가 모든 프록시 자격 증명 교환을 보호하지는 않는다

프록시 인증은 목적지 TLS가 수립되기 전에 일어날 수 있습니다. 프록시 자체와의 연결이 평문이고 인증 방식이 그 구간에서 재사용 가능한 자격 증명을 노출한다면, 목적지가 HTTPS라도 앞서 이루어진 교환을 소급해 보호하지 못합니다. 서비스에 적합한 전송 방식과 인증 구성을 선택하고, 알 수 없는 공개 프록시에 개인 계정을 보내지 마세요.

자세한 로그는 공유하기 전에 검토하세요. 도구가 일반적인 자격 증명 필드를 가려도 사용자 이름, 내부 엔드포인트 이름, 쿠키 등 식별 가능한 정보가 남을 수 있습니다.