마이크로서비스 아키텍처(MSA)에서 인증(Authentication)과 인가(Authorization)는 단일 애플리케이션보다 훨씬 복잡하다.
서비스가 분리되어 있으므로 사용자의 로그인 정보를 각 서비스에 개별적으로 전달하고 관리하는 방식은 현실적으로 불가능하다.
이를 해결하기 위해 등장한 대표적인 인증 방식이 OAuth2.0, OpenID Connect, 그리고 JWT(Json Web Token) 기반 인증이다.
이번 글에서는 Spring Security 환경에서 JWT와 OAuth2를 활용해 확장성과 보안성을 동시에 갖춘 인증 체계를 설계하는 방법을 설명한다.

✅ 마이크로서비스에서 인증이 어려운 이유
- 모든 서비스가 독립되어 있어 각자 인증/인가를 구현하면 중복 로직과 보안 취약점이 생긴다.
- 인증 로직이 변경되면 여러 서비스에 동시 배포가 필요하다.
- 프론트엔드 → Gateway → 내부 서비스로 이어지는 흐름에서 인증 토큰을 공유하는 체계가 필요하다.
- OAuth2처럼 외부 인증 제공자(Google, Kakao 등)와 연동하려면 중앙 인증 서버가 필요하다.
🔑 JWT(Json Web Token)란?
JWT는 인증 정보를 JSON 포맷으로 담아 디지털 서명된 토큰으로 만들어 전달하는 방식이다.
토큰은 일반적으로 헤더(Header), 내용(Payload), 서명(Signature)으로 구성된다.
🧩 JWT 구조

- Header: 알고리즘 정보 (예: HS256)
- Payload: 사용자 정보, 권한, 만료 시간 등의 Claims
- Signature: 비밀 키로 암호화된 서명
JWT는 토큰 자체에 정보를 담기 때문에 서버 상태를 유지하지 않아도 된다.
즉, Stateless 인증에 적합하며, 모든 마이크로서비스에서 동일한 방식으로 검증 가능하다.
✅ JWT 장점
- 중앙 인증 서버를 거쳐 받은 토큰만 있으면 각 서비스가 독립적으로 검증 가능
- 별도의 세션 저장소 불필요
- RESTful API에 이상적으로 적용 가능
❌ JWT 단점
- 토큰 탈취 시 무력화가 어렵다 (재발급 또는 만료 시간 조정 필요)
- 토큰 길이가 길어 네트워크 비용 증가 가능
- 서버에서 임의로 토큰을 만료시키기 어려움 (단점 보완 위해 블랙리스트 사용 가능)
🌐 OAuth2란?
OAuth2.0은 사용자 인증을 제3자 인증 서버에 위임하고, 엑세스 토큰(access token)을 발급받아 보호된 자원에 접근하는 표준 프로토콜이다.
Google, Facebook, Kakao 등 외부 로그인 연동이 대표적인 예이다.
🔧 OAuth2 흐름 요약
- 사용자가 로그인 시도
- 인증 서버가 인증 후 Access Token 발급
- 클라이언트는 이 토큰을 가지고 Resource Server에 요청
- 리소스 서버는 토큰의 유효성을 검증하여 응답
Spring Security에서는 spring-security-oauth2를 통해 OAuth2 인증/인가를 쉽게 구현할 수 있다.
✅ OAuth2 장점
- 외부 로그인 연동이 용이하다
- 인증 서버와 리소스 서버 분리 가능 (보안/운영 분리)
- 다양한 인증 방식을 유연하게 지원한다
🔄 JWT + OAuth2 + OpenID Connect 조합
실무에서는 OAuth2 인증을 통해 Access Token을 JWT 형식으로 발급받는 방식이 일반적이다.
여기에 OpenID Connect를 함께 사용하면 사용자 정보 조회 및 로그인 세션 유지가 가능하다.
| 구성 요소 | 역할 |
| OAuth2 | 인증 흐름 표준화 |
| OpenID Connect | 사용자 식별 정보 제공 |
| JWT | 인증 토큰 포맷 |
🛠️ Spring Security에서의 구현 방식
1. 의존성 추가
implementation 'org.springframework.boot:spring-boot-starter-oauth2-resource-server'
implementation 'org.springframework.boot:spring-boot-starter-security'
2. application.yml 설정
spring:
security:
oauth2:
resourceserver:
jwt:
jwk-set-uri: http://auth-server/.well-known/jwks.json
3. 인증 처리 예제
@GetMapping("/me")
public ResponseEntity<String> getProfile(@AuthenticationPrincipal Jwt jwt) {
return ResponseEntity.ok(jwt.getSubject());
}
모든 마이크로서비스는 JWT의 유효성만 검증하면 인증된 사용자임을 신뢰할 수 있다.
🧠 API Gateway + JWT 전략
- 사용자가 로그인하면 인증 서버에서 JWT 발급
- 프론트엔드는 JWT를 Authorization 헤더에 실어서 요청
- API Gateway는 JWT를 검증하고, 내부 마이크로서비스로 전달
- 마이크로서비스는 토큰만으로 사용자 정보를 확인 가능

✅ 결론
MSA에서 인증 시스템을 설계할 때는 분산 구조에 맞는 확장성과 보안성이 중요하다.
JWT는 Stateless 인증 방식으로 마이크로서비스에 적합하며, OAuth2는 권한 위임과 외부 인증 연동에 강점을 가진다.
두 기술을 결합하여 인증 서버와 리소스 서버를 분리하고, 토큰 기반 인증 구조를 정립하면
운영 효율성과 보안성을 모두 확보할 수 있다.
📌 참고한 공식 문서
'MSA' 카테고리의 다른 글
| [MSA] 계약 테스트와 통합 테스트 전략 비교 (3) | 2025.07.24 |
|---|---|
| [MSA] Sleuth, Zipkin으로 분산 추적 구현하기 (4) | 2025.07.24 |
| [MSA] Prometheus, Grafana로 모니터링 체계 구축하기 (0) | 2025.07.24 |
| [MSA] MSA에서 CI/CD와 무중단 배포 전략 (3) | 2025.07.24 |
| [MSA] Kafka vs RabbitMQ: 메시지 기반 아키텍처 완전정복 (2) | 2025.07.23 |
| [MSA] Spring Cloud Config와 Vault로 설정 통합 관리 (0) | 2025.07.23 |
| [MSA] Circuit Breaker로 장애 격리 설계 (Hystrix, Resilience4j) (2) | 2025.07.23 |
| [MSA] Eureka와 Consul로 서비스 디스커버리 구현하기 (1) | 2025.07.23 |