세션 인증 방식과 토큰 인증 방식

하나의 서버로 이루어진 단일 서버 환경에서는 Session을 이용한 로그인 유지에 대해 불편함을 못 느꼈습니다.

 

하지만, Scale Out을 통해 백엔드 서버를 총 3대를 운영하고 있는 상태에서 새로운 사용자가 Server1에 접속하여 세션이 생성되었습니다. 이때 Server2, Server3는 해당 회원의 세션 정보를 알지 못합니다. 그럼 유저는 요청을 보낼 때마다 매번 인증을 위해 다시 로그인을 해야하는 문제가 발생합니다. 이렇게 서버 간에 세션을 공유하지 않는 상태를 Session 불일치 문제라고 합니다.

 

Session 불일치 문제 해결하기

---

1. Sticky Session 방식

특정 유저의 요청을 최초로 그 요청을 처리해준 서버로만 보내주는 방식

예를 들어, 사용자가 Server1으로 세션을 생성하였다면, 해당 유저의 요청은 요청을 처리해 준 서버로만 보내주는 방식입니다.

적절한 서버에 요청을 붙여주는 역할은 로드 밸런서가 해주어야 하기 때문에 Sticky Session 방식에서 로드 밸런서는 필수입니다.

대표적으로 AWS ELB는 Sticky Session을 활용한 서비스를 제공하고 있습니다.

 

Sticky Session의 문제점

가용성?

이는 Scale Out의 장점을 활용하지 못하는 것인데요. Scale Out은 트래픽 분산과 가용성이라는 장점이 존재하지만 Sticky Session 방식에서는 특정 유저의 요청은 특정 서버로 고정되기 때문에 문제를 해결하는 방식은 Scale Out의 특징과 반대로 작용합니다.

 

트래픽 분산?

또한 Scale Out은 Load Balancer를 통한 트래픽 분산이 장점인데, 사용자의 요청을 처리할 서버가 처음 세션이 생성된 서버로 고정되어 버리기 때문에 특정 서버에 트래픽이 집중되어 있어도 사용자는 해당 서버의 요청 만을 기다리게 된다는 문제점이 있습니다.

 

2. Session Clustering 방식

서버들을 하나의 클러스터로 묶어 관리하고, 클러스터 내의 서버들이 세션을 공유할 수 있도록 하는 방식

클러스터 내의 모든 서버들이 세션 정보를 공유할 수 있다면 사용자는 어떤 서버에 접속하더라도 세션 정보를 찾을 수 있습니다.

 

Session Clustering의 문제점

Scale Out을 통해 서버를 추가할 때 마다 기존에 있는 모든 서버들에 대해서도 추가 세팅 작업을 해주어야 하는 불편함이 존재합니다. 또, 서버가 늘어남에 따라 세션을 저장하고 찾아오는 과정에서 추가적인 부하가 발생하기 때문에 지속적인 확장에는 한계가 있다는 문제점이 있습니다.

 

3. Session Storage 방식

기존의 서버 내 세션 저장소를 이용하지 않고, 별도의 세션 저장소를 두고 서버들이 이를 공유함으로써 세션 불일치를 해결하는 방식

별도의 Session Storage를 활용할 경우 저장소에서 세션을 저장하고 있으므로 새로운 서버를 추가하더라도 추가한 서버에만 세션 저장소 정보를 명시해주기만 하면 되기 때문에 기존 서버의 수정이 발생하지 않는다는 장점이 있습니다.

한 서버에 장애가 발생하더라도, 세션은 독립적으로 존재하기 때문에 서비스에 영향을 미치지 않는다는 장점이 있습니다. 뿐만 아니라, 세션을 저장할 때 세션을 복제해 다른 서버들에게 보낼 필요가 없어 네트워크 성능면에서도 유리한 방식입니다.

 

Session Storage의 문제점

하지만 Session Storage 역시 문제점이 없는 것은 아닙니다. 세션을 저장하고 있는 Session Storage 자체에 문제가 발생할 경우 모든 세션을 잃어버릴 수 있습니다.

세션에 주로 로그인한 사용자의 정보를 저장하는데, 사용자가 로그아웃을 하거나 세션 Timeout에 따라 세션이 제거됨에 따라 이 정보는 영속적인 데이터가 아닙니다. 세션 데이터의 데이터가 유실된다면 사용자는 다시 로그인만 진행하면 됩니다.

 

 

토큰 기반 인증 방식

---

세션 기반 인증이 인증 정보를 서버에 저장하는 방식이라면, 토큰 기반 인증은 인증 정보를 클라이언트가 직접 들고 있는 방식입니다. 대표적인 토큰 기반 인증 방식인 JWT는 디지털 서명이 존재하기 때문에, 토큰의 내용이 위변조 되었는지 서버 단에서 확인할 수 있습니다.

 

토큰 기반 인증 방식 장점

확장성

서버가 직접 인증 정보를 저장하지 않고 클라이언트가 저장하는 방식을 취하기 때문에 세션 불일치 문제로부터 자유롭습니다.

위에서 설명한 세션 불일치 문제를 해결하기 위한 Sitcky Session, Session Cluster, Session Storage 같은 별도의 과정이 필요 없이 Scale Out이 가능합니다.

 

서버의 부담 감소

세션 기반 인증 방식은 서버가 세션을 직접 저장하고, 관리합니다. 따라서 세션의 양이 많아질수록 서버의 부담이 증가하게 됩니다.

하지만 토큰 기반 인증 방식은 클라이언트가 인증 데이터를 직접 가지고 있습니다. 따라서 유저 수가 증가에 상관없이 서버의 부담은 증가하지 않습니다.

 

토큰 기반 인증 방식 단점

보안

토큰은 서버가 추적하지 않고, 클라이언트가 모든 인증 정보를 가지고 있기 때문에 토큰이 탈취된다면 해당 토큰이 만료될 때 까지 피해를 입을 수밖에 없다.

 

요약

---

세션 기반 인증 방식과 토큰 기반 인증 방식을 에 대해 이해해보았습니다.

세션 기반 인증 방식에서 Scale Out을 고려할 때, 세션 불일치 문제가 발생한다는 문제점이 있었고 Sitcky Session, Session Cluster, Session Storage와 같은 방법들이 무엇인지, 특징과 장단점에 대해 알아보았습니다.

토큰 기반 인증 방식에서는 클라이언트가 인증 정보를 저장한다는 특징을 통해 Scale Out을 고려할 때 세션 불일치 문제로부터 자유롭고, 서버의 부담이 적다는 장점을 통해 세션 기반 인증 방식보다 조금 더 유리합니다.