1. 쓰는 이유

• 주변에서 토큰 기반 인증을 많이 사용해서 평소 사용자 인증 기능을 구현할 때 JWT 인증을 주로 사용했다.

• 그러나 백엔드 기초 강의를 보면 세션 (session) 기반 인증을 사용하는 경우도 종종 있다.

• 그래서 궁금했다. 1) 두 가지 인증 방식은 어떤 차이가 있고, 2) 각각 어떤 경우에 사용하는 게 적절한 것인지.

2. 본문

개념 이해

Session

• 세션에 사용자 정보를 담아서 데이터베이스에 저장하고, 쿠키를 통해 세션 아이디를 클라이언트에 보냄. (세션 정보는 서버에 저장)

JWT

• 사용자 정보가 유효하면 토큰을 발급하여 클라이언트로 보내주고, 토큰에는 1) 헤더, 2) 내용, 3) 서명 데이터가 담겨 있다.

보편성 (Winner: JWT)

• 최근에는 확실히 토큰 기반 인증 방식이 유행이라고 한다.

• 그 이유는 최근에 마이크로 서비스 아키텍처가 유행이라서 그렇다. (자세한 내용은 아래 '확장성'에서 확인)

• 물론 호불호가 갈리지만, 트렌드는 무시할 수 없을 것 같다.

확장성 (Winner: JWT)

• 최근 마이크로 서비스 아키텍처 (MSA)가 도입되면서, 서버가 여러 개일 경우 서버 간 세션 정보를 공유할 수 있는 방법이 필요하다.

• 세션을 사용할 경우, sticky session, session clustering, session storage (데이터베이스에 저장하는 방식)을 이용하면 해결이 되긴 하지만, 전부 서버 측 부담을 주는 방법이다. 그러나 사용자 인증정보를 클라이언트 측에 저장하는 JWT 방식은 서버에 부담을 안 주고 사용자 인증이 가능하다.

• JWT는 서버에 인증 방식을 저장하지 않으므로, HTTP의 비상태성 (stateless) 특징을 유지시킬 수 있다.

보안성 (Winner: Session)

• 세션의 경우, 인증 정보를 서버에서 관리하기 때문에 인증 정보를 클라이언트에서 관리하는 JWT 방식보다 안전하다고 한다.

예) 해커가 인증정보를 탈취했을 때, 세션의 경우에는 데이터베이스에 있는 정보를 삭제하거나 무효화하면 되지만, 토큰 방식은 토큰의 유효기간이 지날 때까지 별도의 삭제 방법이 없다는 것이 큰 단점이다.

• 또한, JWT는 payload에 사용자 정보를 암호화하지 않기 때문에 토큰이 탈취되면 사용자 정보도 함께 탈취되는 것이며, 이는 쿠키에 세션 아이디만 저장하는 방식보다 위험하다.

사이즈 (Winner: Session)

• Why JWTs Suck as Session Tokens 에 따르면, 토큰 방식은 세션 방식에 비해 네트워크 트래픽을 훨씬 많이 사용한다고 한다.

• 같은 사용자 정보를 저장하는데 sesison 방식은 쿠키 사이즈가 6 bytes인 반면, JWT는 토큰 사이즈가 304 bytes이라고 한다. (약 50배)

• 따라서 트래픽 크기 관리가 중요한 서비스는 session이 유리할 수도 있다.

3. 결론

• 어떤 인증 방식이 훨씬 유리하다고 할 수는 없지만, 요즘처럼 MSA 아키텍처가 유행하는 시대에서 JWT의 인기가 많은 것이 사실이다.

• 서비스 종류와 목적에 맡게 인증 방식을 선택하면 될 것 같고, 딱히 차이가 없다고 생각하면 트렌디한 JWT를 선택하면 될 것 같다.

4. 참고 자료

• Session(세션)과 Token(토큰)의 차이는?

• Why JWTs Suck as Session Tokens