HTTP 401 Unauthorized: 의미와 해결 방법

이 오류의 의미와 확인 방법

• 브라우저, API 클라이언트, 모니터링 도구 또는 웹사이트 검사기가 401 Unauthorized를 보고합니다.
• 보호된 페이지 또는 API 라우트에서 로그인을 요청하거나 세션을 거부하거나 인증 오류 본문을 반환합니다.
• 동일한 호스트에서 일부 공개 URL은 정상적으로 제공되지만 특정 라우트 또는 요청 메서드에서는 401을 반환할 수 있습니다.
• DNS 확인과 TLS 협상이 정상적으로 작동하더라도 요청에서 HTTP 401을 받을 수 있습니다.
• 응답 헤더에 인증 요구 사항, 리디렉션, 캐시 동작, 프록시 또는 CDN이 표시될 수 있으며, 요청 ID 또는 상관관계 ID가 포함되는 경우도 있습니다.
• 브라우저 세션으로 보낸 요청은 API 클라이언트 또는 모니터링 서비스에서 보낸 요청과 다르게 동작할 수 있습니다.

가능성이 높은 순서의 주요 원인

1. 인증 누락 또는 유효하지 않은 인증 — 요청에 자격 증명이 없거나, 세션이 만료되었거나, 토큰 또는 비밀번호가 잘못되었거나, 인증 헤더 형식이 올바르지 않습니다.
2. 잘못된 요청 컨텍스트 — 클라이언트가 잘못된 URL, HTTP 메서드, 호스트, audience, scope, 쿠키, API 키 또는 환경을 사용하므로 다른 곳에서는 유효한 자격 증명이 여기서는 허용되지 않습니다.
3. 애플리케이션 인증 규칙 — 미들웨어, 라우트 가드 또는 세션 검증이 애플리케이션 핸들러가 실행되기 전에 요청을 거부합니다.
4. 웹 서버, reverse proxy, CDN 또는 WAF 규칙 — 인프라 계층에서 인증을 요구하거나, 불완전하거나 변경되었거나 누락된 자격 증명을 전달합니다.
5. 캐싱 또는 라우팅 동작 — 캐시된 응답, 예상하지 못한 리디렉션, 오래된 라우트 또는 호스트/프로토콜 불일치로 인해 클라이언트가 인증 요구 사항이 다른 엔드포인트로 이동합니다.
6. 업스트림 구성 또는 서비스 변경 — 배포, identity provider 변경, 시크릿 교체, 프록시 변경 또는 환경 불일치로 인해 이전에는 유효했던 요청이 실패합니다.

해결 방법

방문자용

1. 정확한 주소를 확인하고 반복해서 새로 고침하지 말고 한 번만 다시 시도하세요.
2. 리소스에 계정이 필요한 경우 사이트의 일반적인 인터페이스를 통해 로그인한 후 다시 시도하세요. 세션이 만료되지 않았는지 확인하세요.
3. 링크 하나만 실패한다면 사이트 전체를 사용할 수 없다고 가정하지 말고 해당 URL을 구체적으로 신고하세요.
4. 대략적인 시간, 페이지 또는 API 엔드포인트와 표시된 401 메시지를 기록하세요. 비밀번호, 쿠키, 액세스 토큰 또는 기타 시크릿은 보내지 마세요.
5. 평소 공개된 페이지에서 401이 반환되거나 로그인에 성공했는데도 보호된 리소스에 접근할 수 없다면 사이트 소유자에게 문의하세요.

API 클라이언트 및 개발자용

1. 실패한 클라이언트가 사용한 것과 동일한 HTTP 메서드, URL, 호스트, 쿼리 파라미터, 헤더 및 본문으로 실패를 재현하세요. 가능한 경우 비프로덕션 계정 또는 테스트 자격 증명을 사용하세요.
2. 자격 증명이 포함되어 있고 만료되지 않았으며 형식이 올바르고 해당 호스트, 라우트 및 환경에 사용하도록 발급되었는지 확인하세요. 인증 시스템에서 token scope 또는 audience를 사용하는 경우 이를 확인하세요.
3. 시크릿을 노출하지 않은 상태로 상태, 응답 헤더 및 응답 본문을 캡처하세요. 인증 challenge 정보, 리디렉션, 캐시 헤더 및 요청 ID를 특히 주의해서 확인하세요.
4. 정상적으로 작동하는 요청과 실패한 요청을 한 번에 한 가지 차이만 두고 비교하세요. 쿠키, 인증 헤더, 프록시 전달, 리디렉션 및 요청 메서드를 확인하세요.
5. 애플리케이션, 웹 서버, reverse proxy, CDN 또는 WAF 중 어떤 컴포넌트가 응답을 생성했는지 확인하세요. 응답 본문, 특징적인 헤더 및 계층별 로그가 이를 구분하는 데 도움이 될 수 있습니다.
6. 타임스탬프, 라우트, 클라이언트 및 요청 ID를 사용해 일치하는 로그를 확인하세요. 최근 배포, identity provider 변경, 시크릿 교체, 라우팅 업데이트 및 프록시 구성을 점검하세요.
7. 예를 들어 라우트별 자격 증명 또는 전달 규칙을 수정하는 등 권한이 부여된 가장 좁은 범위의 수정만 적용하고 동일한 요청을 다시 테스트하세요. 첫 대응으로 인증을 비활성화하거나, 비공개 응답을 공개적으로 캐시하거나, 광범위한 권한을 부여하지 마세요.
8. 관련 공개 및 보호된 라우트, 해당 HTTP 메서드와 의도한 비인증 동작을 테스트하여 수정으로 인해 접근 제어 문제가 발생하지 않았는지 확인하세요.

401과 유사한 오류 구분

• 401 Unauthorized: 인증이 없거나 유효하지 않거나 엔드포인트에서 허용되지 않습니다.
• 403 Forbidden: 서버가 요청을 이해했지만 접근을 허용하지 않습니다. 유효한 인증이 이미 존재할 수도 있습니다.
• 404 Not Found: 해당 위치에서 라우트 또는 리소스를 사용할 수 없습니다. 다만 일부 시스템은 보호된 리소스를 의도적으로 이런 방식으로 숨깁니다.
• 5xx 응답: 단순히 인증을 거부한 것이 아니라 서버 측 처리에 실패했습니다.

예방 및 해결 확인 방법

• 라우트, 메서드, 클라이언트 유형 및 배포별로 인증 실패를 모니터링하여 특정 라우트 문제와 광범위한 인시던트를 구분하세요.
• 인증, 라우팅, 프록시 및 캐싱 구성을 버전 관리하고 릴리스 전에 변경 사항을 검토하세요.
• 중요한 웹 라우트와 API 메서드에 대해 예상되는 비인증, 인증 및 권한 부족 응답을 테스트하세요.
• 개발, 테스트 및 프로덕션에 별도의 자격 증명과 구성을 사용하고 통제된 프로세스를 통해 시크릿을 교체하세요.
• 액세스 토큰, 쿠키 및 비밀번호가 애플리케이션, 프록시, 모니터링 또는 지원 로그에 나타나지 않도록 하세요.
• 인증 실패를 조사할 수 있도록 정제된 요청 ID, 타임스탬프 및 계층별 로그를 충분한 기간 동안 보존하세요.
• 어떤 라우트가 의도적으로 공개, 보호 또는 메서드와 클라이언트 유형에 따라 제한되는지 문서화하세요.

자주 묻는 질문