API Gateway와 OAuth2 / JWT

💡  오늘 학습 키워드

• API Gateway
• OAuth2 / JWT

 

🎯  학습 내용 정리

마이크로서비스 아키텍처에서는 하나의 서비스가 아닌 여러 개의 서비스가 함께 하나의 시스템을 구성한다. 사용자의 요청도 하나의 서버가 아닌 여러 서비스로 전달된다.

 

예를 들어 쇼핑몰 서비스를 생각해보면 다음과 같다.

• 회원 서비스
• 상품 서비스
• 주문 서비스
• 결제 서비스
• 배송 서비스

사용자가 상품을 조회하고 주문을 생성하는 과정에서도 여러 서비스가 함께 동작한다.

만약 클라이언트가 각각의 서비스를 직접 호출한다면 어떻게 될까?

• 모든 서비스의 주소를 알아야 한다.
• 인증을 모든 서비스에서 처리해야 한다.
• 로깅과 모니터링도 서비스마다 구현해야 한다.
• 서비스가 추가될 때마다 클라이언트도 수정해야 한다.

이러한 문제를 해결하기 위해 사용하는 것이 API Gateway이다.

 

 

1. Circuit Breaker

API Gateway는 클라이언트와 마이크로서비스 사이에서 동작하는 단일 진입점(Single Entry Point) 이다.

클라이언트는 Gateway만 호출하고 Gateway가 적절한 서비스로 요청을 전달한다.

Client
 │
API Gateway
 ├── User Service
 ├── Order Service
 ├── Product Service
 └── Payment Service

모든 요청은 반드시 Gateway를 거치게 된다. 덕분에 클라이언트는 내부 서비스 구조를 알 필요가 없다.

Gateway는 다음과 같은 역할을 수행한다.

• 요청 라우팅
• 인증(Authentication)
• 권한 검사(Authorization)
• 로깅
• 모니터링
• Rate Limit
• 요청 및 응답 필터링
• Load Balancing

즉, 공통 기능을 Gateway에서 처리하여 각 서비스는 자신의 비즈니스 로직에만 집중할 수 있다.

 

 

예를 들어 사용자가 주문을 생성한다고 가정해보자. Gateway가 없다면

Client
 ├── User Service
 ├── Product Service
 ├── Order Service
 └── Payment Service

모든 서비스를 직접 호출해야 한다.

서비스가 추가되거나 주소가 변경되면 클라이언트도 함께 수정해야 한다.

 

반면 Gateway를 사용하면

Client
  ↓
API Gateway
  ↓
Order Service

Gateway가 내부적으로 필요한 서비스로 요청을 전달한다. 클라이언트는 Gateway의 주소 하나만 알고 있으면 된다.

 

 

Spring Cloud Gateway는 Spring Cloud에서 제공하는 API Gateway이다.

기존에는 Netflix Zuul이 많이 사용되었지만 현재는 Spring Cloud Gateway가 공식 Gateway로 사용된다. Spring Cloud Gateway는 Netty 기반의 Reactive 서버 위에서 동작하며 높은 성능과 확장성을 제공한다.

 

대표 기능은 다음과 같다.

• 동적 라우팅
• 서비스 디스커버리(Eureka)
• Load Balancing
• JWT 인증
• OAuth2 연동
• Filter 제공
• Rate Limiting
• Circuit Breaker 연동

MSA 프로젝트에서는 대부분 Gateway를 시스템의 진입점으로 사용한다.

 

 

Spring Cloud Gateway는 요청 경로에 따라 서비스를 선택한다.

예를 들어 다음과 같이 설정할 수 있다.

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true

      routes:
        - id: users-service
          uri: lb://users-service
          predicates:
            - Path=/users/**
            
        - id: orders-service
          uri: lb://orders-service
          predicates:
            - Path=/orders/**

 

여기서 중요한 부분은

lb://orders-service

이다.

lb는 Load Balancer를 의미한다.

Gateway는 Eureka에서 서비스 목록을 조회한 뒤 적절한 인스턴스로 요청을 전달한다.

 

 

Gateway는 요청을 전달하기 전에 다양한 작업을 수행할 수 있다. 이를 Filter라고 한다.

Spring Cloud Gateway에서는 크게 두 가지 Filter를 제공한다.

• Global Filter
• Gateway Filter

 

Global Filter

Global Filter는 모든 요청에 적용된다.

 

예를 들어

• JWT 인증
• 요청 로그
• 응답 로그
• Trace ID 생성

등은 모든 API에서 수행해야 한다.

이럴 때 Global Filter를 사용한다.

@Component
public class LoggingFilter implements GlobalFilter, Ordered {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange,
                             GatewayFilterChain chain) {

        System.out.println(exchange.getRequest().getURI());

        return chain.filter(exchange);
    }

    @Override
    public int getOrder() {
        return -1;
    }
}

위 Filter는 모든 요청의 URL을 출력한다.

 

 

Gateway Filter

Gateway Filter는 특정 라우트에만 적용된다.

예를 들어

/admin/**

경로에 대해서만 관리자 인증을 수행하고 싶다면 Gateway Filter를 사용할 수 있다.

routes:

- id: admin
  uri: lb://admin-service

  predicates:
    - Path=/admin/**

  filters:
    - AddRequestHeader=X-Request, Gateway

Global Filter는 전체 서비스, Gateway Filter는 특정 서비스에 적용된다.

 

2. OAuth2

OAuth2는 인증(Authentication)과 권한 위임(Authorization)을 위한 표준 프로토콜이다. 사용자의 비밀번호를 외부 서비스에 직접 전달하지 않고 안전하게 권한을 위임할 수 있도록 설계되었다.

 

대표적인 예가

• Google 로그인
• Kakao 로그인
• Naver 로그인
• GitHub 로그인

이다.

 

로그인 과정은 다음과 같다.

사용자
  ↓
Google 로그인
  ↓
동의 화면
  ↓
Authorization Code
  ↓
Access Token
  ↓
내 서비스 로그인

즉, OAuth2는 로그인 기능 자체가 아니라 권한을 위임하는 방식이라고 이해하는 것이 정확하다.

 

 

JWT(JSON Web Token)는 인증 정보를 담는 토큰 형식이다.

로그인이 성공하면 서버는 JWT를 발급한다. 이후 사용자는 JWT를 이용해 인증을 수행한다.

JWT는 다음과 같이 구성된다.

Header.Payload.Signature

각 부분의 역할은 다음과 같다.

 

Header

토큰 타입과 암호화 알고리즘을 저장한다.

HS256 JWT

 

Payload

사용자 정보를 저장한다. 예를 들어

userId, role, email, expiration

등이 포함된다. 이를 Claim이라고 한다.

 

Signature

토큰이 위조되지 않았는지 검증하는 부분이다. 서버만 알고 있는 Secret Key를 이용하여 생성한다.

따라서 Payload를 임의로 수정하면 Signature 검증이 실패한다.

 

 

JWT 인증은 세션 인증과 다르게 서버가 로그인 상태를 저장하지 않는다.

로그인 과정은 다음과 같다.

1. 로그인 요청

Client
  ↓
Login API

 

 

2. 로그인 성공

JWT 발급

 

 

3. JWT 저장

브라우저는

• LocalStorage
• SessionStorage
• HttpOnly Cookie

등에 JWT를 저장한다.

 

4. API 요청

이후 모든 요청은 JWT를 함께 전송한다.

Authorization: Bearer JWT

 

 

5. Gateway 인증

Gateway는 JWT를 검증한다.

JWT 검증
  ↓
유효
  ↓
Service 전달

유효하지 않으면

401 Unauthorized

를 반환한다.

 

 

MSA에서는 대부분 Gateway에서 JWT를 검증한다.

전체 흐름은 다음과 같다.

Client Login
  ↓
Auth Service
  ↓
JWT 발급
  ↓
Client 저장
  ↓
API 요청
Authorization: Bearer JWT
  ↓
API Gateway
  ↓
JWT 검증
  ↓
User Service
Order Service
Product Service
  ↓
Response

이 방식의 장점은 인증 로직을 모든 서비스에서 구현하지 않아도 된다는 것이다.

 

Gateway가 인증을 완료한 후 내부 서비스로 요청을 전달하기 때문에 각 서비스는 사용자 정보만 받아 비즈니스 로직을 수행하면 된다.

또한 Gateway는 사용자 정보를 Header에 담아 내부 서비스에 전달하는 방식도 많이 사용된다.

예를 들어

X-User-Id

X-Role

같은 Header를 추가하면 내부 서비스는 JWT를 다시 파싱하지 않아도 된다.

 

 

많은 개발자가 OAuth2와 JWT를 같은 기술이라고 생각하지만 서로 역할이 다르다.

OAuth2는 로그인을 위한 권한 위임 프로토콜이고, JWT는 인증 정보를 저장하는 토큰 형식이다.

실제 서비스에서는 다음과 같은 흐름이 가장 많이 사용된다.

Google Login
  ↓
OAuth2 인증
  ↓
사용자 정보 조회
  ↓
우리 서비스 JWT 생성
  ↓
JWT 발급
  ↓
이후 모든 API는 JWT 사용

즉, OAuth2는 최초 로그인 과정에서만 사용되고, 이후 인증은 JWT를 사용하는 구조가 일반적이다.

 

 

API Gateway는 MSA에서 모든 요청의 단일 진입점 역할을 수행하며, 인증, 권한 검사, 로깅, 라우팅과 같은 공통 기능을 중앙에서 처리한다. Spring Cloud Gateway를 사용하면 이러한 기능을 손쉽게 구현할 수 있으며, Global Filter와 Gateway Filter를 통해 공통 로직과 서비스별 로직을 유연하게 분리할 수 있다.

또한 OAuth2와 JWT를 함께 사용하면 안전한 로그인과 Stateless 인증을 구현할 수 있다. 일반적으로 OAuth2를 통해 사용자를 인증하고, 이후 JWT를 발급하여 Gateway에서 검증하는 방식이 가장 많이 사용된다. 이러한 구조는 서비스 간 결합도를 낮추고 인증 로직을 일관성 있게 관리할 수 있어 MSA 환경에서 표준적인 인증 방식으로 자리 잡고 있다.

 

 

📚  한줄 정리

1. API Gateway는 모든 클라이언트 요청을 단일 진입점에서 처리하여 라우팅, 인증, 로드 밸런싱 등 공통 기능을 제공하는 핵심 컴포넌트이다.

2. OAuth2는 안전한 사용자 인증과 권한 위임을 위한 표준 인증 프레임워크이며, JWT를 사용하는 구조가 일반적이다.