• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

jwt 토큰방식에서의 세션 미사용 질문

22.06.07 18:41 작성 조회수 901

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클래스에 설정을 한다면 서버는 사용자의 상태정보를 저장하지 않는 '무상태성'을 유지할 수 있고 

그에 따라, 매 요청마다 인증객체를 생성하는 과정이 진행되는 것으로 이해해도 되는 것인지 궁금합니다.