HTTP 401과 403 차이: 인증 실패와 권한 부족 구분하기
401 Unauthorized와 403 Forbidden은 자주 같이 보이지만 의미는 다릅니다. 이 둘을 섞어 쓰면 클라이언트 UX도 나빠지고, 운영 중 문제를 좁히는 속도도 느려집니다. 실무에서는 "누구인지 확인이 안 됐는가"와 "누구인지는 알지만 권한이 없는가"를 분리해서 봐야 합니다.
1) 401의 의미
401은 보통 인증 정보가 없거나, 있어도 유효하지 않다는 뜻입니다. 대표적으로 아래 상황이 있습니다.
Authorization헤더 누락- 액세스 토큰 만료
- 잘못된 API 키
- 세션이 사라졌거나 로그인 상태가 끊김
즉 401은 “먼저 다시 인증하라”에 가깝습니다.
2) 403의 의미
403은 사용자가 누구인지는 확인되지만, 현재 리소스나 동작에 접근할 권한이 없다는 뜻입니다. 대표적으로 아래 상황이 있습니다.
- 일반 사용자가 관리자 API 호출
- 필요한 scope나 role이 없음
- 조직/테넌트 접근 제한
- IP 또는 정책 기반 접근 차단
즉 403은 “인증은 되었지만 허용되지 않는다”에 가깝습니다.
3) 왜 이 구분이 중요한가
401을 403으로 보내면 클라이언트는 토큰 재발급이나 재로그인을 시도하지 않을 수 있습니다. 반대로 403을 401로 보내면 사용자는 계속 로그인만 다시 하게 되고, 실제 권한 문제는 해결되지 않습니다. API 소비자 입장에서도 어떤 조치를 취해야 하는지 판단이 어려워집니다.
4) 디버깅 순서
- 요청에 인증 헤더나 세션 쿠키가 실제로 붙었는지 확인
- 토큰 만료와 서명 검증 결과 확인
- 사용자 식별이 된 뒤 role/scope 정책을 확인
- 프록시나 API 게이트웨이가 상태 코드를 바꿨는지 확인
이 순서대로 보면 401과 403을 빠르게 분리할 수 있습니다.
5) 운영에서 자주 보는 패턴
프런트엔드에서 토큰 갱신 로직이 실패하면 첫 API가 401을 내고, 이후 사용자는 로그인 화면으로 튕깁니다. 반면 관리 페이지에서 특정 버튼만 403이 난다면 인증보다 권한 매핑이나 백엔드 정책 분기가 원인일 가능성이 큽니다. 상태 코드 하나가 같아 보여도 문제 영역이 완전히 다릅니다.
6) 보안상 일부러 404를 쓰는 경우
일부 시스템은 리소스 존재 여부를 숨기기 위해 403 대신 404를 반환하기도 합니다. 예를 들어 다른 사용자의 문서 ID를 추측했을 때 “권한 없음” 대신 “없음”으로 응답하는 방식입니다. 이런 정책이 있다면 API 문서와 실제 응답 설계를 함께 확인해야 합니다.
7) 응답 본문도 같이 설계하기
상태 코드만 정확해도 도움이 되지만, 운영 환경에서는 응답 본문에 왜 실패했는지 최소한의 이유 코드를 넣는 편이 좋습니다. 예를 들어 TOKEN_EXPIRED, ROLE_REQUIRED, SCOPE_MISSING 같은 내부 코드를 함께 주면 로그와 클라이언트 처리가 쉬워집니다.
8) 체크리스트
- 인증 정보가 실제 요청에 포함되었는가
- 토큰 만료/서명 검증에 실패했는가
- 사용자 식별 이후 권한 정책에서 막혔는가
- API 게이트웨이, 프록시, WAF가 상태 코드를 바꾸지 않았는가
- 클라이언트가 401과 403을 다르게 처리하는가
9) 빠른 판단 기준
- 다시 로그인하면 해결될 것 같으면 401 쪽을 먼저 의심
- 로그인은 정상인데 특정 기능만 안 되면 403 쪽을 먼저 의심
- 여러 사용자에게 동시에 발생하면 배포나 인증 인프라 문제 가능성도 고려
10) 관련 도구와 문서
상태 코드 의미 자체를 빠르게 확인하려면 HTTP Status Lookup이 유용하고, 토큰 만료나 claim 확인이 필요하면 JWT Decoder와 JWT 관련 가이드를 함께 보는 것이 좋습니다.