여러 서비스에서 로그인 상태를 확인하고 강제 로그아웃도 지원하려 합니다. JWT와 서버 세션은 어떤 기준으로 선택하나요?

JWT와 서버 세션의 선택은 ‘무상태인가’보다 권한 회수 속도, 검증 지연, 서비스 간 신뢰, 장애 시 동작을 기준으로 해야 합니다. 서버 세션은 클라이언트에 임의 식별자만 주고 서버가 현재 상태를 조회하는 방식이라 강제 로그아웃과 권한 변경을 즉시 반영하기 쉽습니다. JWT는 신원·대상·만료 같은 주장을 토큰에 담고 각 서비스가 서명을 검증하므로 조회를 줄일 수 있지만, 발급 후 내용이 만료 전까지 남습니다.

토큰과 세션의 실제 계약을 비교합니다

서버 세션의 쿠키 값은 보통 의미 없는 ID이고, 세션 저장소에 사용자·기기·만료·회수 상태가 있습니다. 로그아웃은 서버 상태를 폐기하면 되므로 명확하지만, 모든 요청이 저장소나 캐시에 의존하고 저장소 장애가 로그인 기능에 영향을 줍니다. 세션 캐시를 오래 두면 즉시 회수 보장이 약해지고, 여러 지역에서 공유 상태의 지연·가용성을 설계해야 합니다.

서명된 JWT는 payload가 암호화된 것이 아니므로 민감한 원문을 넣지 않습니다. 서비스는 허용 알고리즘, issuer, audience, subject, 만료·발급 시각·not-before와 서명을 검증해야 합니다. 서명이 유효하다고 해서 토큰에 적힌 역할이 지금도 최신이거나 특정 API 작업이 허용된다는 뜻은 아닙니다. JWT 형식 자체가 저장 위치나 회수 방법을 결정하지 않으므로, 짧은 access token과 별도 refresh token, 토큰 버전·차단 목록을 함께 사용할 수도 있습니다.

요구에 맞춰 혼합합니다

여러 내부 서비스가 짧은 시간 동안 같은 신원과 대상만 검증하면 JWT가 저장소 조회를 줄이는 이점이 있습니다. 반대로 관리자 삭제, 결제 수단 변경처럼 즉시 회수가 중요한 작업은 세션 상태나 권한 버전을 재조회하거나, 짧은 토큰 수명과 별도 차단 검사를 사용하겠습니다. 이때 ‘완전한 무상태’를 유지하려고 회수 요구를 무시하지 않습니다. 필요한 상태를 인정하고 어느 요청에서 읽는지 명시하는 편이 정직합니다.

브라우저에서는 토큰 저장 위치도 선택의 일부입니다. HttpOnly 쿠키를 쓰면 XSS가 값을 직접 읽는 위험을 줄일 수 있지만 CSRF 방어가 필요하고, 브라우저 저장소에 bearer token을 두면 CSRF 표면과 함께 XSS 탈취 위험을 평가해야 합니다. 두 방식 모두 전송 암호화와 로그·분석 도구의 원문 마스킹이 필요합니다. 키 교체 때는 새 공개키를 먼저 배포하고 기존 토큰의 남은 수명 동안 이전 키를 제한적으로 검증하는 운영 계약도 필요합니다.

검증은 정상 로그인보다 로그아웃 직후, 권한 회수, 키 ID 변경, 검증 저장소 장애, 다른 audience의 토큰, 만료·시계 오차, 여러 서비스의 정책 차이를 포함해야 합니다. 선택 기준은 토큰이 멋진가가 아니라 ‘어떤 자격을 언제까지 신뢰하고, 취소를 어느 지연으로 보장하며, 그 판단을 어디서 할 것인가’입니다.

세션과 JWT를 섞어 쓰는 경우에도 어느 자격이 권위 있는지 정해야 합니다. 예를 들어 JWT는 서비스 간 5분짜리 접근 증명으로만 쓰고, 브라우저의 장기 로그인과 강제 로그아웃은 중앙 session/refresh 상태가 책임지게 할 수 있습니다. 이때 한 서비스가 JWT의 subject만 받아 객체 권한을 자체적으로 넓히지 않도록 audience와 scope를 좁게 발급합니다. 세션 저장소를 장애 시 fail-open하면 강제 차단이 무력화되므로 민감 작업은 fail-closed에 가깝게, 저위험 공개 조회는 별도 계약으로 처리하겠습니다. 토큰 크기와 검증 CPU, 네트워크 왕복뿐 아니라 회수 목록의 증가와 운영자가 원인을 추적할 수 있는지도 비용에 넣습니다.