지난 [일단 박죠] O2O Object Detection 서버 Spring Cloud 적용을 위한 분석 게시글에서 그렸던 구조에서 언급하지 않았던 부분이다. 토큰 기반의 인증 방식을 나타낸 그림인데, 이번 게시글에서는 왜 토큰 기반 인증 방식을 선택했는지에 대해서 정리해보고자 한다.

1. 세션 기반 인증 방식의 문제점

세션 기반 인증 방식을 통해 인증 과정을 수행 할 경우 아래와 같은 문제점들이 발생한다.

1-1. 스케일 아웃의 어려움 및 결합도 증가

• 세션 정보를 서버 각각에서 관리하게 된다면, 세션 정보를 모든 서버 간에 공유해야 하기 때문에, 세션 관리의 복잡성이 크게 증가한다. 특히, 서비스가 확장될 때마다 세션 정보의 동기화가 필수적이며, 이를 위한 추가적인 시스템(예: Redis)이 필요하다.
• 세션 정보를 중앙에서 관리하게 되면, 해당 세션 관리 시스템이 전체 시스템의 단일 장애 지점(Single Point Of Failure, SPOF)으로 작용할 수 있다. 즉, 세션 저장소에 문제가 발생하면, 전체 인증 과정이 마비될 위험이 있다.

1-2. 리소스 오버헤드

• 세션 기반 인증에서는 각 사용자의 세션 정보를 서버 측에서 관리한다. 사용자 수가 증가함에 따라, 서버는 이를 저장하고 관리하기 위한 상당한 리소스를 소모하게 되며, 이는 서버의 성능 저하로 이어질 수 있다.

2. 토큰 기반 인증 방식의 선택 이유

토큰 기반 인증 방식은 아래와 같은 이유로 앞에서 다루었던 세션 기반 인증 방식의 문제점을 해결한다.

2-1. 결합도 감소

• Gateway에서 토큰을 검증하게 되면, 상점 관리 서버와 객체 인식 서버는 인증 로직에 대한 결합도 없이 각자의 핵심 비즈니스 로직에 집중할 수 있다. 이는 시스템 전체의 결합도를 낮추며, 서비스 간의 독립성을 보장한다. 또한, 모든 인증 요청이 Gateway를 통과함으로써, 보안 정책의 일관된 적용과 관리가 가능하다.

2-2. Stateless Authentication 및 확장성 향상

• 토큰 기반 인증 방식에서는 사용자 인증 정보를 서버가 아닌 클라이언트 측에 저장한다. 이로 인해 서버는 사용자의 인증 상태를 유지할 필요가 없으며, 각 요청은 독립적으로 처리된다. 이는 서비스의 확장(스케일 아웃)이 용이하다.

결론적으로, 상점 관리 서버와 객체 인식 서버와 같이 분리된 서비스 구조를 가진 시스템에서 토큰 기반 인증 방식으로 세션 기반 인증 방식이 가지는 여러 제약사항을 극복할 수 있다.

3. 토큰 기반 인증 방식의 문제점

하지만 토큰 기반 인증 방식은 아래와 같은 고질적인 문제점이 있다.

3-1. 토큰 탈취의 경우

• 토큰이 탈취될 경우, 공격자는 탈취한 토큰을 사용하여 사용자의 인증 정보로 서비스에 접근할 수 있다.

3-2. 무효화의 어려움

• 토큰은 만료 시간이 지나기 전까지 유효하기 때문에, 일단 탈취되면 특별한 조치가 취해지기 전까지는 무효화하기 어렵다. 즉, 토큰이 탈취된 사실을 인지한 후에도 공격자가 토큰을 사용하여 시스템에 접근할 수 있다.
  

4. 결론

분리된 서비스 구조를 가진 시스템에서 세션 기반 인증방식의 문제점을 해결하기 위해서 토큰 기반 인증 방식을 선정하였다. 하지만 토큰 기반 인증 방식은 토큰이 탈취 당했을 경우, 무효화가 어렵다. 다음 게시글에서는 이러한 토큰 탈취 문제에 대해 고려한 내용들과 현재 프로젝트에 적용한 토큰 구조에 대해서 설명할 것이다.