대규모 서비스의 인증 구조

 

 

대규모 서비스의 인증 구조는 한 줄로 요약하면:

"인증(Authentication)은 중앙화하고,
인가(Authorization)는 서비스별로 분산 처리"

 

하는 방향으로 간다.

그리고 핵심 기술 조합은 보통:

SSO
+
OAuth2/OIDC
+
JWT
+
Gateway
+
IAM

 

이다.

---

먼저 왜 복잡해지나?

소규모 서비스는:

로그인
↓
Session 생성
↓
끝

 

이면 된다.

---

그런데 대규모는?

예:

• 웹
• 모바일
• 관리자
• API
• MSA
• 외부 파트너
• 사내 시스템

전부 연결된다.

---

그래서 문제 발생

각 서비스마다 로그인 구현?

 

하면:

• 중복
• 보안 취약
• 관리 지옥

된다.

---

그래서 등장

중앙 인증 서버(IdP)

 

---

기본 구조

Client
↓
Identity Provider(IdP)
↓
Access Token(JWT)
↓
각 서비스(API)

 

---

대표 IdP

제품회사

Okta	Okta
Microsoft Entra ID	Microsoft
Keycloak	오픈소스
Google Identity	Google

---

핵심 흐름

---

STEP 1 — 로그인은 중앙에서

사용자 로그인:

IdP(Login Server)

 

에서 수행.

---

즉 서비스들은:

비밀번호 직접 관리 안 함

 

가능.

---

STEP 2 — Access Token 발급

보통 JWT 발급.

예:

 

{
  "sub":"123",
  "role":"ADMIN",
  "exp":999999
}

 

---

STEP 3 — API 호출

 

Authorization: Bearer TOKEN

 

---

STEP 4 — 각 서비스 검증

서비스는:

JWT 서명 검증

 

후 사용자 확인.

---

왜 JWT 많이 쓰냐?

MSA에서는:

Session 공유 어려움

 

하기 때문.

---

예전 Session 문제

서버 100대면:

세션 공유 저장소

 

필요.

---

JWT는

Stateless

 

라서 확장 쉬움.

---

그래서 구조

로그인 서버만 상태 관리
API 서버는 JWT 검증만

 

---

그런데 현실은 완전 Stateless 아님

실무 핵심.

---

왜냐면 필요한 것

• 로그아웃
• 토큰 폐기
• 권한 변경
• 세션 만료

---

그래서 Redis 많이 사용

예:

Refresh Token 저장
블랙리스트 관리

 

---

대규모 구조 핵심 — Access/Refresh 분리

거의 표준.

---

Access Token

특징설명

짧음	15m~1h
JWT	Stateless
API 인증용	O

---

Refresh Token

특징설명

김	days~weeks
Redis 저장	많음
재발급용	O

---

API Gateway도 중요

대규모는 보통:

Client
↓
API Gateway
↓
Services

 

구조.

---

Gateway 역할

• JWT 검증
• Rate Limit
• WAF
• Logging
• Routing

---

즉 공통 인증 처리 중앙화.

---

서비스 간 인증도 중요

MSA에서는:

서비스 ↔ 서비스

 

인증도 필요.

---

예:

order-service
↓
payment-service

 

---

이때도:

• JWT
• mTLS

등 사용.

---

mTLS 중요

Mutual TLS

---

의미

서버끼리 서로 인증

 

---

Zero Trust 방향

현대 대규모 시스템은:

내부망도 신뢰 안 함

 

---

즉:

• 사용자 인증
• 서비스 인증
• Device 인증

전부 지속 검증.

---

권한 관리도 분리

엄청 중요.

---

인증(Authentication)

누구인가?

 

---

인가(Authorization)

무엇을 할 수 있는가?

 

---

대규모는 보통

• RBAC
• ABAC

혼합.

---

예:

ROLE_ADMIN
+
본인 매장만 접근

 

---

캐시도 중요

JWT 검증 자체는 빠르지만:

권한 정책
사용자 상태

 

등은 Redis 캐시 많이 사용.

---

실무에서 흔한 구조

---

사용자 로그인

OIDC/OAuth2

 

---

인증 토큰

JWT

 

---

토큰 저장

Redis

 

---

서비스 인증

mTLS

 

---

Secret 관리

• HashiCorp Vault
• KMS

---

네트워크 보안

• WAF
• API Gateway
• ZTNA

---

실제 기업 느낌

규모구조

소규모	Session
중규모	JWT + Redis
대규모 MSA	OAuth2/OIDC + Gateway + JWT + IAM

---

실무 핵심 포인트

1. 인증 중앙화

비밀번호는 IdP만 관리.

---

2. 토큰 짧게

Access 최소화.

---

3. 권한은 서비스 단위 검증

Gateway만 믿으면 위험.

---

4. 내부 서비스도 인증

Zero Trust 방향.

---

5. Audit 중요

누가 무엇을 했는지 추적 가능해야 함.

---

핵심 한 줄

대규모 서비스의 인증 구조는:

중앙 인증 서버(IdP)가 OAuth2/OIDC 기반으로 JWT를 발급하고,
API Gateway와 각 마이크로서비스가 이를 검증하며,
Redis·mTLS·Zero Trust·RBAC/ABAC 등을 함께 사용해
확장성과 보안을 동시에 확보하는 구조

 

로 발전하고 있다.