인프런 커뮤니티 질문&답변
작성한 질문수
jwt 토큰방식에서의 세션 미사용 질문
작성
·
1.1K
0
강의에서 jwt방식을 예로 드셨던 세션정책Stateless에서 세션을 사용하지 않는다고 말씀하셨습니다.
궁금한 점은
jwt토큰방식을 사용하더라도 세션은 사용하는 것이 아닐까라는 의문입니다.
이유는 jwt방식으로 인증에 성공하면 Authentication객체를 securityContext에 저장하고 세션에 캐싱을 하며 controller에서 principle이나 @preauthorize 등과같은 기능을 사용할 수 있기 때문입니다.
답변 1
2
네
jwt 기술을 사용한다는 의미는 여러가지가 있겠지만 그 중 하나는 세션을 사용하지 않기 위함입니다.
예를 들어 서버를 여러대를 운영할 경우에 세션같은 경우 사용자의 동일한 세션이 서버간에 공유 즉 클러스터가 되어야 하는 문제가 생기는데 jwt 는 토큰 자체에 인증기능을 구현할 수 있기 때문에 어떤 서버로 접속하더라도 동일한 토큰값이라면 서버개수와 상관없이 인증시스템을 구현할 수 있습니다.
그 외에도 여러 장점이 있습니다.
다만 강의에서 세션을 사용할 필요가 없다고 한 것은 강제나 의무가 아니며 jwt 를 사용함에 있어서 근본 취지가 중요하다는 의미로 해석하시면 되겠습니다.
그리고 스프링 시큐리티에서 SecurityContext 에 인증객체를 저장하는 것은 세션과는 아무런 상관이 없습니다.
정확하게는 ThreadLocal 과 관련이 있습니다.
SecurityContext 는ThreadLocal 에 저장하는데 ThreadLocal 은 세션의 범위가 아닌 Request 범위에 속하기 때문에 범위가 세션보다 범위가 작습니다.
강의에서도 설명하지만 SecurityContext 를 SecurityContextHolder 에 담을 때 세션에 SecurityContext 가 존재할 경우에 세션에서 꺼내어 오지만 세션에 존재하지 않을 경우 새롭게 SecurityContext 를 만들어서 SecurityContextHolder 에 저장합니다.
그리고 SecurityContextHolder 는 ThreadLocal 를 가지고 있습니다.
즉 jwt 를 사용하던 안하든, 세션을 사용하던 안하든 SecurityContext 객체에 Authentication 객체가 저장되어 있지 않고 null 이라면 마지막 권한을 체크하는 FilterSecurityInterceptor 에서 결국 막히게 됩니다.
SecurityContextHolder > ThreadLocal > SecurityContext > Authentication > UserDetails
의 관계를 잘 파악하시면 됩니다.
선생님, 답변 감사합니다.
필터를 거치고 Controller단에서 principal이나 @preauthorize기능이 가능한 이유는 세션이 아닌 ThreadLocal 덕분이라는 것을 이해할 수 있었습니다.
답변 내용중에 궁금한 점이 생겨 다시 한번 질문드립니다.
세션을 사용하는 시스템에서는 한 번 로그인 후 생성해둔 인증객체를 SecurityContext (SC)에 저장해 두고 Request범위에 있던 SecurityContextHolder을
Session범위로 더 넓혀 SecurityContextHolder(SCH)을 저장하면
다른 요청에서도 세션을 통해 SCH를 찾을 수 있고 이후 SC를 찾을 수 있어서
추가적인 인증객체를 생성하지 않고 이전에 서버측에 저장된 인증객체를 재이용할 수 있다는 것으로 이해했습니다.
이때, 세션을 사용하지 않게끔 SecurityConfig클래스에 설정을 한다면 서버는 사용자의 상태정보를 저장하지 않는 '무상태성'을 유지할 수 있고
그에 따라, 매 요청마다 인증객체를 생성하는 과정이 진행되는 것으로 이해해도 되는 것인지 궁금합니다.