[Web] Session vs JWT

Session과 JWT

Session방식의 Authentication / Authorization 방식은 구현하기 쉽지만, 분산 처리를 해야 하는 경우 문제가 생깁니다.

먼저 Session을 사용하는 2가지 방식에 대해서 알아보고, 어떤 문제가 생기는지 알아보겠습니다.

 

---

Sticky Session

Sticky Session 동작 방식

Load Balancer가 특정 Client의 Session 정보를 가지고 있는 Server Instance로 연결해줍니다.

이는 두 가지 문제점을 안고 있습니다.

1. 특정 서버가 장애가 생긴다면?

Server Instance2가 장애가 생겼을 때, Client2의 요청은 어디로 가야할까요? Session정보는 Server Instance2만이 가지고 있으므로 기존 Session 정보는 사용할 수 없게 됩니다.

2. 진짜 로드 밸런싱이 되는가?

홀수번호 Client의 요청은 Server Instance1, 짝수번호 Client의 요청은 Server Instance2가 처리한다고 가정해봅시다.

홀수번호 Client의 요청이 짝수번호 Client의 요청보다 훨씬 많으면 Server Insatnce1이 훨씬 더 많은 트래픽을 받고 있다는 것을 깨달을 수 있습니다.

---

Session Clustering

위의 Sticky Session의 경우 특정 서버 인스턴스에 정보를 저장하여 문제가 있었습니다. 그렇다면 서버 인스턴스가 아니라 Session 전용 서버에 Session정보를 저장하면 어떨까요?

Session Clustering 동작 방식

Session Clustering은 Sticky Session의 문제점들은 잘 해결했지만, Session Storage로 몰리는 트래픽의 처리를 어떻게 할 것인지에 대한 새로운 문제가 생깁니다.

 

이렇게 대용량 처리가 필요할 시 Session방식으로 인증 정보를 저장할 경우 신경써야 할 점이 많다는 것을 알 수 있습니다.

---

JWT를 쓰는 이유?

Session방식은 Server나 따로 Storage를 만들어 관리한다는 점에서 발생하는 문제점들이 있었습니다.

 

Token인증 방식은 Client가 Server로부터 발급 받은 Access Token을 Header에 담아 Request를 보내면 Server에서 그 토큰을 검증하여 처리하는 방식으로 이루어집니다.

 

인증 정보를 Server측에 담아두지 않고 Client측에서 담아두기 때문에 많은 문제점들이 해소됩니다.

 

장점

• 인증에 필요한 정보가 Client가 가지고 있는 Token에 포함되기 때문에 Server측에서 따로 인증정보를 저장하는 저장소가 필요 없다.
• 토큰값만 있다면 어떤 서버로 요청이 가든 상관이 없기 때문에 확장성이 좋다.
• 헤더를 이용하기 때문에 cookie와 관련된 문제 (CSRF 등) 가 없다.

단점

• 이런 Token은 거의 모든 Request에 대해서 전송되고 검증하기 때문에 주고받는 데이터가 커질 수 있다.
• Claim에 넣을 데이터가 많아질수록 Token또한 길어지며 역시 주고받는 데이터가 커진다.
• Payload에 대한 정보는 간단하게 Base64로 Decoding이 가능하다.( https://www.jwt.io에서 확인할 수 있다. ) Payload에 중요한 정보를 넣지 않도록 주의해야 한다.
• 한 번 발급된 Token은 서버에서 조작이 불가능하기 때문에 추가로 Token을 관리하기 위한 Expire Time이나 Refresh Token이 필요하다.

---

그래서 Session을 쓸까? Token을 쓸까?

정해진 답은 없으며, 만약 확장성을 지속적으로 생각해야 한다면 Server에 부담을 줄여주는 Token 인증방식이 좋을 것입니다. 그러나 구현하는 비용을 생각하여 더 구현하기 쉬운 Session을 선택할 수도 있습니다.

 

 

 

---

References

JWT (JSON Web Token) 이해하기와 활용 방안 - Opennaru, Inc.

MSA 기반 환경에서의 인증과 인가 - 1. 개요