세션 기반 인증 vs 토큰 기반 인증

 

고민지점 

 

서버에서 로그인 기능 구현을 할 때, JWT를 이용한 토큰 기반의 인증/인가 방식을 많이 사용하게 된다. 다만, JWT 옆에 따라 붙는 키워드가 쿠키, 세션, Redis등 같이 몇 가지가 있는데, 가장 많이 언급이 되고 비교가 되는 인증/인가 방식이 쿠키 + 세션 로그인 방식이다. 하지만, 구글링을 해보았을때, JWT 기반 (+Spring Security) 글이 훨씬 많았고, 본인도 충분한 고민 없이 해당 방식으로 구현을 해본 거 같다. 그러므로, 토큰, 세션방식의 장단점을 알고, 왜 해당 방식으로 구현했는지는 알아둘 필요가 있을 필요가 있다고 생각해서 해당 글을 쓰게 되었다. 

 

나한테 하는 얘기인 거 같다

 

 

세션 기반 인증의 단점? 

 

보통 세션 방식의 로그인 방식을 언급할 때 나오는 단점은 몇가지가 있는데, 

크게 WAS 서버의 확장성과 서버의 부담이 많이 나오는 것 같다. 

 

확장성 같은 경우는, 서버를 여러 대 두었을 때, 세션 기반 인증을 처리하는 데 생기는 세션 불일치 문제를 얘기하는 경우인데, 해당 글에선 확장성 보다는 서버의 부담의 측면에서 토큰 기반 인증과 비교를 해보고자한다.  

이 내용은 나중에 알아보자

 

토큰 기반 인증과의 비교 

 

해당 유튜브 영상에서 나와 똑같이 해당 문제에 대해 궁금해 하시는 분들이 계셨고, 감사하게도, 어떤 분이 답글을 달아주셨다. 

 

요약하자면,

 

세션 방식은, 

서버의 부담 측면에서 세션이 가지고 있는 가장 큰 문제점은, 결국 세션을 서버가 메모리에 계속 가지고 있어야한다는 측면이다. 세션 아이디를 가지고, 브라우저에서 매번 http 요청을 할텐데, 매번 해당 요청이 들어올 수록 세션 id를 확인하는 질의를 넣어야하고, 이러한 이유 때문에 서버에 부하가 생긴다는 점이다. 해당 경우는 당연히 트래픽의 규모가 유의미하게 클 때 이러한 문제점이 생기는 것 같다. 

 

반대로 토큰 방식은,

클라이언트가 토큰을 가지고 http 요청을 할 때, 서버에서 (스프링 내에서는 필터나 인터셉터) DB나 메모리를 접근할 필요가 없다는 장점이 있기 때문에, 서버에 부담을 상대적으로 적게 줄 수 있다. 토큰 그 자체가 유효한지, 만료가 되었는지 등을 DB 질의 없이 체크하면 된다. 

 

그럼 JWT 이용할때는 아예 DB 접근을 안하나? 

그건 또 아니다. 보통 Access Token과 Refresh Token을 함께 이용하여, Access Token의 만료 기간을 짧게 두어, 만료되었을때 Refresh Token을 통해 재발급을 받는데, 그 Refresh Token을 DB에 저장하게 된다. 

그럼 결국 세션 기반 인증과 같이 DB에 접근을 해야하는 것이다. 

 

하지만, 

세션 기반 방식은 사용자의 인증이 필요한 모든 http 요청에 대해서 DB 질의를 해야하지만, 토큰 기반 인증은 그렇지 않다. Access Token이 유효하고, 만료가 아직 되지 않았을 때의 같은 경우에는 DB에 있는 Refresh Token에 접근할 이유가 없다. 

만료되었을 때, Acess Tokne이 재발급이 필요할 때에만 접근하게 되면 된다. 

 

결론 및 프로젝트 회고 

어떤 분이 위에 있는 유튜브 댓글에 써주셨듯이, 세션 기반 인증과 토큰 기반 인증 중에 정답은 없다고 생각한다. 

 

토큰 같은 경우에도 장점만 존재하진 않는다. 세션 같은 경우에는 세션 id 탈취와 같이, 세션의 사용을 더 이상 불가능하게 하고 싶을 때, 삭제를 통해서 서버 측에서 관리가 유용하게 가능하지만, 토큰 같은 경우에는 애초에 이러한 작업이 불가능하기에, 토큰들을 관리하기에 훨씬 어려워지며, 이를 막기위해선 해당 토큰을 블랙리스트 처럼 구별을 해둔 후, 만료될 때까지 막는 작업 등을 추가적으로 해줘야한다는 단점도 있다. 

 

나도 프로젝트를 하면서, JWT를 활용한 인증 작업을 직접 구현하고 이해를 하게 되어 유의미한 작업이었지만, 큰 고민 없이 무의식적으로 남들이 많이 쓰니까 쓰게 된 부분이 없지 않은 것 같다.

엄밀히 따지면, 지금 현재 프로젝트의 규모로 보았을때는, 오히려 토큰 인증 방식을 쓰면 위에서 언급한 토큰의 단점을 보완하는데 더 신경을 많이 쓸 수 있어, 세션 기반 인증이 더 나을 수 있겠다는 생각도 하게 되었다. 

 

이 부분은 앞으로 더 리팩토링 및 고민해봐야겠지만, 앞으로 어떤 방식을 선택하느냐에 대한 근거는 마련할 필요성을 더 느끼게 되었던 것 같다. 

 

 

 

https://www.youtube.com/watch?v=T13UYO9so6E 

3분 부터 해당 내용이 나옵니다. 

https://hudi.blog/session-based-auth-vs-token-based-auth/

세션 기반 인증과 토큰 기반 인증 (feat. 인증과 인가)