Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

14장. 인증과 인가 — 분산 환경에서 사용자 정보가 흐른다

지금까지 우리는 시스템을 어떻게 나누고, 연결하고, 조회하는지 살펴봤다.

이제 남은 질문은 이것이다.

누가 이 시스템을 사용할 수 있는가
그리고 어디까지 할 수 있는가

인증과 인가

먼저 개념부터 정리하자.

인증(Authentication)은

누구인가를 확인하는 과정이다

인가(Authorization)는

무엇을 할 수 있는가를 결정하는 과정이다

로그인은 인증이고, 권한 체크는 인가다.

모놀리스에서는 단순했다

모놀리스에서는 요청이 하나의 서버에서 처리된다.
로그인하면 세션을 만들고, 요청마다 세션만 확인하면 된다.

인증은 서버 내부에서 끝난다.

마이크로서비스에서는 어떻게 달라지는가

마이크로서비스에서는 하나의 요청이 여러 서비스를 거친다.

예:

Client → Order → Payment → User

이 흐름에서 각 서비스는
요청을 받을 때마다 인증 정보를 알아야 한다.

만약 각 서비스가 인증을 따로 구현한다면

  • Order 서비스도 인증 체크
  • Payment 서비스도 인증 체크
  • User 서비스도 인증 체크

같은 로직이 모든 서비스에 반복된다.

이 구조는 비효율적이고,
관리도 어려워진다.

그래서 인증 정보는 요청과 함께 전달되어야 한다.

분산 시스템에서는 인증도 데이터처럼 흐른다

세션 기반 인증

세션 방식은 여전히 많이 사용된다.

구조는 단순하다.

  • 로그인 시 세션 생성
  • Redis / Memcached 저장
  • 요청 시 세션 조회

장점:

  • 구현이 쉽다
  • 서버에서 상태 제어 가능

하지만 마이크로서비스에서는 문제가 생긴다.

  • 모든 서비스가 세션 저장소에 의존
  • 매 요청마다 Redis 조회 발생
  • 장애 시 전체 서비스 영향

즉, 세션은 중앙 의존성을 만든다.

토큰 기반 인증

이 문제를 해결하기 위해 토큰 방식이 사용된다.

대표적으로 JWT가 있다.

구조는 이렇게 바뀐다.

  • 로그인 시 토큰 발급
  • 클라이언트가 토큰 보관
  • 요청마다 토큰 전달

각 서비스는

  • 토큰을 검증하고
  • 필요한 정보를 추출한다

세션 조회가 필요 없다.

세션 vs 토큰

세션과 토큰의 차이는 명확하다.

세션은 상태 기반이다.
토큰은 상태 없는 방식이다.

세션:

  • 서버에 상태 저장
  • 중앙 의존성 발생

토큰:

  • 클라이언트가 상태 보관
  • 서비스 독립적으로 검증

실무에서는 혼합한다

현실에서는 하나만 쓰지 않는다.

다음과 같은 구조가 많다.

  • 로그인 → 세션 또는 인증 서버
  • API 호출 → 토큰 사용

또는

  • Gateway에서 인증 처리
  • 내부 서비스는 토큰 기반 처리

이렇게 하면

  • 사용자 상태 관리
  • 서비스 독립성

을 동시에 가져갈 수 있다.

인증은 어디서 처리할까

또 하나의 중요한 결정이 있다.

인증을 어디서 처리할 것인가

1️⃣ Gateway에서 처리

모든 요청을 한 곳에서 검증한다.
내부 서비스는 인증 로직을 가지지 않는다.

장점:

  • 중앙 관리
  • 서비스 단순화

단점:

  • Gateway 의존성 증가

2️⃣ 각 서비스에서 처리

각 서비스가 토큰을 직접 검증한다.

장점:

  • 서비스 독립성 유지

단점:

  • 인증 로직 중복

실무에서는 두 방식을 함께 사용한다.

  • Gateway에서 1차 검증
  • 서비스에서 최소 검증

인가 (권한 관리)

인가는 인증보다 더 복잡하다.

가장 단순한 방식은 Role 기반이다.

예:

  • USER
  • ADMIN

하지만 서비스가 커지면 부족하다.

더 현실적인 권한

  • 리소스 기반 권한
  • 사용자 속성 기반 권한
  • 상태 기반 권한

예:

  • 본인 주문만 조회 가능
  • 특정 상태에서만 수정 가능

인가 로직은 비즈니스와 강하게 연결된다.

이벤트 기반 시스템에서의 문제

이벤트 구조에서는 또 다른 문제가 생긴다.

이벤트에는 사용자 정보가 없다.

예:

  • OrderCreated 이벤트
  • 누가 생성했는지 알 수 없음

다른 서비스는 사용자 없이 이벤트를 처리하게 된다.

해결 방법

이 문제를 해결하려면

  • userId를 이벤트에 포함하거나
  • 별도의 audit 정보를 관리해야 한다

즉, 인증 정보도 함께 전달해야 한다.

이 장의 핵심

  • 인증은 “누구인가”
  • 인가는 “무엇을 할 수 있는가”
  • 요청은 여러 서비스를 거친다
  • 인증 정보는 함께 전달되어야 한다
  • 세션은 중앙 의존성을 만든다
  • 토큰은 서비스 독립성을 만든다
  • 실무에서는 두 방식을 함께 사용한다
  • 이벤트에서는 사용자 정보 전달을 고려해야 한다

한 줄 정리

분산 시스템에서는 인증도 흐르고, 권한도 설계해야 한다