SSO 슬라이딩 세션 구현

고객사에서 슬라이딩 세션을 적용해달라는 요청이 들어왔다. 현재는 JWT 토큰이 24시간 고정 만료라, 활동 중이어도 24시간이 지나면 로그아웃된다. 사용자 활동 기반으로 세션을 연장해달라는 거였다.

단순한 기능 요청이라고 생각했다. 인터셉터에서 만료 임박 시 토큰을 갱신해주면 되니까. 하지만 코드를 열어보면서 판단이 바뀌었다.

첫 번째 판단: 구현 전에 현황부터

코드를 열었을 때 토큰 갱신과 관련된 흔적이 여러 군데 있었다. UI에 5분 전 갱신 리스너, 응답 인터셉터에 Authorization 헤더 읽기 코드, git log에 “토큰 리프레시 적용” 커밋. 얼핏 보면 이미 구현되어 있는 것 같았다.

하지만 하나씩 뜯어보니 전부 미완성이거나 데드코드였다. 갱신 리스너는 로그인 페이지에만 등록되어 있어서 로그인 후엔 소멸했고, 백엔드는 응답 헤더에 토큰을 보내는 코드 자체가 없었다.

팀에 현황을 먼저 보고했다. “현재 갱신 메커니즘이 전혀 없고, 기존 코드는 미완성 상태입니다.”

보고 후 팀장님이 물었다. “그럼 외부 SSO랑 내부 토큰 동기화는 어떻게 되어 있어?”

솔직히 거기까진 조사하지 않았다. 하지만 이 질문이 핵심이었다는 걸 바로 알았다. 외부 SSO에서 로그아웃해도 내부 JWT가 살아있으면, 비활성화된 사용자가 최대 24시간 동안 시스템에 접근할 수 있다.

이걸 계기로 SSO 동기화 상태를 감사했다. 코드베이스에서 SSO 관련 유틸, 서비스, 프로퍼티를 전부 뒤져서 SSO 방식을 매핑하고, 각각의 재검증 가능 여부를 정리했다.

결과: SSO-JWT 동기화가 어디에도 없었다. 한 번 JWT가 발급되면 외부 SSO 상태와 완전히 독립적으로 24시간 유효했다.

이 조사를 했기 때문에 이후 구현 방향이 달라졌다. “슬라이딩 세션”이 아니라 “슬라이딩 세션 + SSO 재검증”으로 스코프가 확장됐다.

토큰 저장 아키텍처를 조사하면서 결정적인 깨달음을 얻었다.

슬라이딩 세션을 SSO 재검증 없이 단독으로 적용하면:

보안이 오히려 나빠진다. 이 분석을 팀에 공유하고, “슬라이딩 세션은 반드시 외부 SSO 재검증과 함께 가야 한다”는 방향을 잡았다.

외부 SSO 재검증이 기술적으로 가능한지 확인해야 했다. 토큰을 재검증하면 소비(무효화)되는 건지, 단순 조회인지. 문서가 없었다.

벤더 SDK JAR 파일을 디컴파일해서 검증 API의 내부 동작을 확인했다. 토큰을 소비(무효화)하지 않고 상태만 조회하는 방식이었다. 재검증 가능 확인.

문서 없이 추측으로 가지 않고, 코드 레벨에서 확인한 게 중요했다. “아마 되겠지”로 구현했다가 운영에서 터지면 고객사 환경에서 디버깅해야 하니까.

첫 번째 구현 방식은 백엔드 인터셉터에서 응답 헤더로 새 토큰을 전달하는 것이었다. 2022년에 미완성으로 남아있던 흐름을 완성하는 자연스러운 방식이었다.

빌드하고 K8s에 배포했는데, 응답에서 Authorization 헤더가 사라져 있었다. Istio 사이드카가 커스텀 응답 헤더를 스트립하고 있었다.

여기서 두 가지 선택지가 있었다:

Istio 변경은 인프라단 작업이다. 나는 코드 변경만으로 고객사에 이미지를 전달하는 범위를 생각하고 있었다. Istio를 건드리면 인프라 팀과 조율이 필요하고, 고객사 환경마다 Istio 설정이 다를 수 있다.

UI에서 직접 SSO의 /refreshToken 엔드포인트를 호출하는 방식으로 피봇했다. 백엔드 변경은 전부 롤백. 3개 레포에서 2개 레포로 범위가 줄었고, 인프라 의존성도 없어졌다.

정리하면 이 이슈의 범위는 이렇게 변했다:

범위가 확장되는 건 문제가 아니다. 확장되는 이유를 이해하고 통제하는 게 중요하다. 그리고 통제할 수 없는 부분(인프라 변경)이 나왔을 때, 통제 가능한 범위 안에서 해결하는 방향으로 전환한 것이 이 작업에서 가장 실용적인 판단이었다고 생각한다.