캡스톤 프로젝트에서 스프링 시큐리티를 사용한 JWT 기반 인증 시스템 구현 과정 중 발생한 문제에 대한 삽질 기록이다.
우선 어떤 문제가 발생하였는지에 앞서 현재 상황은 아래와 같다
[현재 상황]
- 학교 내부망에 연결되어 있는 연구실 서버 pc
- 해당 PC에 CI/CD 파이프라인 구축을 통해 80 포트로 도커에서 배포되고 있는 Spring Boot WAS (학교 내부망 정책으로 인해 8080포트 사용이 불가능하여 임시로 할당)
- JWT 기반 인증 시스템을 Spring Security를 통해 구현함.
- Swagger를 이용한 문서화
캡스톤 프로젝트를 React + Spring Boot 기반으로 구현하기로 해서 프론트엔드와의 협업이 필수적인데, API 문서를 일일히 만드는 것도 일이라 스웨거를 통해 API 테스트 및 문서화를 지원하고 있었다.
JWT 기반 인증 흐름은 간단하게,
[프론트 엔드] 로그인 성공 -> 서버로부터 Access, refresh 토큰 발급 -> 이후 요청들에는 http header에 Authorization: Bearer [Access Token]을 추가하여 요청 전송
[서버] 스프링 시큐리티에 구성된 JwtAuthentication Filter를 통해 사용자의 인증 상태를 관리
여기서 문제가 발생했는데, 기존 문제들과는 결이 많이 달랐다.
[문제 상황]
- 배포된 서버에 외부망에서 Authorization 헤더를 포함하는 요청을 전송할 경우 브라우저에서 응답을 기다리다 ERR_CONNECTION_RESET 혹은 ERR_CONNECTION_TIMED_OUT이 발생
- 클라이언트 개발자가 요청을 보내는건 Pending 상태가 지속되며 클라이언트 단에서 커넥션 에러가 발생하지만, Swagger를 통해 보낸 요청은 심각하게 서버 자체가 해당 요청을 받는동안 일시적으로 먹통이됨 <-매우 심각한 문제
- 원격 서버라도 Authorization 헤더가 포함되지 않은 요청은 정상적으로 처리되어 응답됨.
(로그인 혹은 일반적으로 공개된 Get요청에 Authorization 헤더를 포함하지 않고 보내는 경우) - 로컬 호스트에서 Swagger를 통해 요청을 보내는 경우는 API와 Security Filter 모두 정상 작동 하며 200 응답과 함께 데이터가 정상적으로 받아짐
- 원격 서버에 같은 네트워크(내부망)에서 요청을 보낼 경우 API와 Security Filter가 모두 정상 작동 하며 200 응답과 함께 데이터가 정상적으로 받아짐
- Postman, curl 등의 도구를 사용한 요청은 외부망에서도 API와 Security Filter가 모두 정상 작동하며 200 응답과 함께 데이터가 정상적으로 받아짐
- 프론트엔드 개발자가 보낸 요청에 대해 서버 로그를 확인 해본 결과 컨트롤러 단에서 로직 처리 후 200응답이 나가는 것 까지 확인됨
위와 같다. 딱 봐도 되는 경우와 안되는 경우에 일관성이 너무 없었다. 네트워크나 방화벽 outbound 제한이라고 보기에는 postman이나 curl의 요청은 정상적으로 응답이 가고, 시큐리티 필터문제라기에는 로컬이나 내부망에서 서버로 보내는 요청은 아주 잘 처리가 되었다.
그럼 postman이나 curl로는 잘 되는데 클라이언트 웹브라우저에서만 안되는 경우에 가장 먼저 생각해 볼 수 있는게 Cors 문제인데, 클라이언트 단에서 Cors 에러를 받는게 아닌 요청을 보낸 후 3~5초간 pending 상태가 지속된 이후 응답에서 ERR_CONNECTION_RESET이 발생하는 것이었다. 즉 Cors 문제는 아니었다. 시큐리티상에서 처리를 다 해두었기 때문에 문제가 발생하지는 않을 것이라 생각했다.
실제로 로그가 아래와 같이 찍히는데,
JwtAuthentication Filter에서 나가는 응답에 대한 응답 헤더를 출력 한 것이다.
보이는 바와 같이 Access-Control-Allow-Origin과 같은 Cors 관련 응답 헤더들이 정상적으로 설정되어 응답 까지 보내진다.
서버에서는 응답을 보냈는데 클라이언트에서는 응답을 못받는다고 한다. 심지어 Swagger로 요청을 보내면 서버가 먹통이 되는 심각한 문제까지 있었다.
[ 해결 ]
우선 결론적으로 해당 문제는 Authorization 헤더를 학교 내부망에서 처리를 하는것인지 아웃바운드 필터링으로 설정을 해둔것인지 알 수는 없으나 Authorization 헤더를 포함하여 보내는 요청에 대해 생기는 문제였다. 그래서 요청시에 헤더이름을 Auth-test 등으로 바꿔서 보내니 아주 정상적으로 응답이 수신되었다.
[회고]
팀원들과 프로젝트 회의를 하다가 프론트엔드 개발자에게 문서 url을 넘겨주며 테스트 해보라고 했는데 갑자기 응답이 안온단다.. 무슨 말도안되는 소리인지 방금전까지 테스트 했을때는 됐는데 여기서 왜안되냐 라고 생각했었다. 방금까지는 연구실에서 내부망으로 테스트를 해서 잘되던게 회의하러 밖에나와서 외부망에 연결해서 요청을 보내니까 안되는 것이었다.
디버깅이 안되고 추적도 안되는 문제를 해결하는 것은 항상 절망감이 앞선다. 되는 경우와 안되는 경우가 일관적이라면 문제를 추적하여 해결하기가 편하지만 내가 손댈 수 없는 학교 네트워크에서 발생한 문제라면 더더욱 그런 것 같다.
80포트에 was를 매핑하여 공개 한것이 문제인가? 아니면 설정해둔 도커 네트워크 자체의 문제인가? 도커의 dns문제인가? 시큐리티 필터 내부로직 문제인가? JWT 라이브러리 문제인가? 등등 Nginx로 리버스 프록시도 설정해보고 별 짓을 다해도 안되던게 정말 단순히 Authorization 헤더 이름 때문에 생긴 문제였다는걸 안 순간 상당히 진이 빠졌다.
물론 Authorization 헤더 자체는 문제가 없다. Jwt기반 인증의 표준이라 너무 당연하게도 저런 방식으로 구현을 했고, 그게 의도치 않게 학교 내부망 네트워크 정책과 충돌이 생긴것이었을뿐..
한편으로는 직접 헤더를 파싱하여 인증 상태를 관리하는 로직을 작성했기 때문에 간단하게 해결할 수 있었던 것일지도 모른다. 만일 라이브러리나 프레임워크에서 Authorization: Bearer로 들어오는 요청에 대해 자동으로 인증 상태를 관리 해주고 관련 설정도 바꿀수 없었다면 얄짤없이 서버를 통째로 옮기던가 하는 수 밖에 없었을 것이다.
교수님께 이야기를 들어보니 학교 서버를 통해 개발할 때 항상 내부망 관련 문제가 크던 작던 있었다고 한다.. 비단 학교 뿐만 아니라 기관에서 개발을 하게될 경우 내부망 관련 문제가 종종 생긴다고 하니 비슷한 문제를 겪은 분들이 원인을 찾지 못했다면 내부망 관련 문제가 아닌지 한번 의심해보길 바란다.
