MSA 보안: OAuth2·OIDC·JWT
OAuth2와 OIDC 역할 분리, JWT 운영 리스크와 키 로테이션, 제로 트러스트 관점의 서비스 검증 원칙 정리
요약 (5–7줄)
MSA 보안의 핵심은 설정이 아니라 신뢰 경계와 토큰 흐름 설계다.
인증은 “누가 누구인지”, 인가는 “무엇을 할 수 있는지”를 다룬다.
OAuth2는 인가 프레임, OIDC는 인증 레이어로 역할이 다르다.
JWT는 무상태라는 장점과 함께 폐기·회전·노출 리스크를 동반한다.
Gateway 인증은 충분조건이 아니며, 제로 트러스트에선 서비스도 검증해야 한다.
보안 실패의 대부분은 암호가 아니라 경계·클레임·검증 규칙의 불일치에서 발생한다.
1. 정의
- 인증(Authentication): “누가 누구인지”를 증명
- 인가(Authorization): “무엇을 할 수 있는지”를 제한
MSA에서는 이 둘을 토큰과 클레임으로 분리해 설계한다.
보안은 기능이 아니라 흐름이다.
2. 직관
모놀리식 보안은 “문 앞에서 한 번 확인”이다.
MSA 보안은 “방마다 확인”이다.
네트워크 내부는 안전하다는 가정은 더 이상 성립하지 않는다.
그래서 토큰이 신분증이 된다.
3. 작동원리: OAuth2 + OIDC 조합
3.1 왜 OAuth2와 OIDC를 함께 쓰는가
- OAuth2: 인가 프레임 (권한 위임)
- OIDC: 인증 표준 (사용자 식별)
OAuth2만으로는 “누구인지”가 불명확하다.
OIDC는 id_token으로 사용자 정체성을 보강한다.
3.2 기본 흐름
1) 사용자가 인증 서버에서 로그인
2) OIDC로 신원 확인
3) OAuth2로 접근 토큰 발급
4) Resource Server가 토큰 검증 후 접근 허용
4. JWT의 장점과 단점
4.1 장점
- 무상태(stateless): 중앙 세션 저장소 불필요
- 서비스 확장에 유리
- 캐시/로드밸런싱 친화적
4.2 단점
- 즉시 폐기 불가
- 토큰 노출 시 피해 확대
- 키 회전 실패 시 전면 장애
4.3 대응 전략
- 짧은 만료(access token)
- 리프레시 토큰 분리
- 서명 키 로테이션(JWKS)
- 최소 클레임 원칙
JWT는 “편의성”을 얻는 대신 운영 규율을 요구한다.
5. Resource Server의 핵심 설정 포인트
5.1 서명 검증
- 공개키 기반 검증 필수
- 알고리즘 고정(alg none 방지)
5.2 Issuer / Audience
- issuer: 신뢰하는 발급자만 허용
- audience: 이 서비스용 토큰만 수용
5.3 Scope / Role 매핑
- scope: 행위 권한
- role: 도메인 역할
- 컨트롤러 단에서 명시적 매핑
보안 사고의 다수는 audience 누락에서 시작한다.
6. “Gateway에서 인증하면 서비스는 안전한가?”
아니다.
제로 트러스트 관점
- 네트워크 내부도 불신
- 각 서비스는 자기 보호 책임
Gateway는 편의 장치일 뿐
보안의 단일 관문(single point of trust)이 아니다.
7. 트레이드오프
- 장점: 확장성, 일관된 정책, 중앙 통제
- 비용: 토큰 관리 복잡성, 운영 규율 필요
MSA 보안은 한 번의 설정이 아니라
지속적인 합의와 검증이다.
8. 최소 예시
8.1 Toy 예시: 사용자 로그인 → API 호출
1) 사용자 로그인
2) 인증 서버가 id_token + access_token 발급
3) 클라이언트가 API 호출 시 Authorization: Bearer
4) Resource Server가 서명/issuer/audience 검증
5) scope 확인 후 처리
핵심: 인증은 서버, 검증은 서비스
8.2 실무 예시: 서비스 간 호출 (M2M)
- 사용자 토큰 사용 금지
- Client Credentials Flow
- 서비스별 audience 분리
- 최소 scope만 부여
결과:
- 서비스 침해 시 권한 확산 제한
- 책임 경계 명확화
9. 실무 함정 → 해결 패턴
| 함정 | 결과 | 해결 패턴 |
|---|---|---|
| 장기 만료 JWT | 탈취 시 대형 사고 | 짧은 만료 |
| audience 미검증 | 토큰 오남용 | 서비스별 audience |
| Gateway 의존 | 내부 침투 | 서비스 자체 검증 |
10. 오해/실수 3개 + 교정
1) “JWT면 안전하다” → 검증 규칙이 핵심
2) “Gateway에서 끝” → 제로 트러스트 위배
3) “권한은 role 하나면 된다” → scope/role 분리
11. 판단 기준
사용해야 할 때
- 다수 서비스/클라이언트
- 외부 연동/B2B
- 수평 확장 필요
쓰지 말아야 할 때
- 단일 내부 앱
- 짧은 수명 서비스
- 운영 역량 부족
12. 재학습 체크리스트 (10–14)
- 인증과 인가를 분리했는가?
- OAuth2와 OIDC 역할을 구분하는가?
- access/refresh 토큰 수명을 분리했는가?
- issuer/audience를 검증하는가?
- 서명 알고리즘을 고정했는가?
- 키 로테이션 절차가 있는가?
- Gateway 장애 시에도 서비스가 안전한가?
- M2M 호출에 사용자 토큰을 쓰지 않는가?
- 최소 scope 원칙을 지키는가?
- 토큰 노출 대응 절차가 있는가?
- 로그에 토큰을 남기지 않는가?
- 보안 변경이 배포 없이 반영 가능한가?