# 마이크로서비스 아키텍처에서 인증(Authentication)과 인가(Authorization)

> Clean Markdown view of GeekNews topic #20869. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20869](https://news.hada.io/topic?id=20869)
- GeekNews Markdown: [https://news.hada.io/topic/20869.md](https://news.hada.io/topic/20869.md)
- Type: news
- Author: [baeba](https://news.hada.io/@baeba)
- Published: 2025-05-13T09:57:11+09:00
- Updated: 2025-05-13T09:57:11+09:00
- Original source: [microservices.io](https://microservices.io/post/architecture/2025/04/25/microservices-authn-authz-part-1-introduction.html)
- Points: 15
- Comments: 0

## Summary

**RealGuard.io**는 다양한 **사용자 유형**에 따른 **접근 권한** 관리가 필요한 상업용 보안 시스템 플랫폼입니다. 모놀리식 구조에서는 하나의 **세션 토큰**과 `isAllowed(user, operation, resource)` 방식으로 **인가 로직**을 구현합니다. 인가 모델로는 **RBAC**, **ReBAC**, **ABAC** 및 **혼합 모델**이 있으며, 인가 검증 위치로 **네트워크 인프라**, **REST API 핸들러**, **도메인 로직**, **DB 접근 계층**이 존재합니다. 마이크로서비스 환경에서는 **JWT 등 토큰 기반 사용자 정보 전달**과 **분산 인가의 복잡성** 문제가 추가로 발생합니다.

## Topic Body

이 시리즈는 마이크로서비스 아키텍처에서 인증(Authentication)과 인가(Authorization)를 구현하는 방법을 다룬다.  
이번 글은 전체 개요와 함께 단일 애플리케이션(모놀리식)과의 차이를 설명한다.  
  
---  
  
##### 예시 애플리케이션: RealGuard.io  
  
RealGuard.io는 상업용 보안 시스템 플랫폼으로, 보안 장비의 제어 및 알람을 관리한다.  
사용자는 판매사, 고객사, 모니터링 제공업체 소속이며 각기 다른 접근 권한을 가진다.  
  
---  
  
##### 모놀리식 아키텍처에서의 인증과 인가  
  
모놀리식 구조는 하나의 애플리케이션과 데이터베이스로 구성되며, 인증은 세션 토큰으로 구현된다.  
인가는 다음과 같은 구조로 수행된다:  
  
```javascript  
isAllowed(user, operation, resource)  
```  
  
예시:  
  
```javascript  
isAllowed(user, "disarm", SecuritySystem(ID))  
```  
  
---  
  
##### 인가 모델 4가지  
  
1. **RBAC**: 역할 기반 접근 제어 – 사용자에게 부여된 역할로 권한 결정  
2. **ReBAC**: 관계 기반 접근 제어 – 사용자와 자원의 관계로 접근 결정  
3. **ABAC**: 속성 기반 접근 제어 – 사용자, 자원, 환경의 속성으로 결정  
4. **혼합 모델**: 위 3가지를 조합하여 복합적인 정책 구현 가능  
  
---  
  
##### 인가 예시와 역할별 권한  
  
| Operation        | Required Role                |  
| ---------------- | ---------------------------- |  
| getAlarmSystem() | SecuritySystemViewer         |  
| armSystem()      | SecuritySystemArmer          |  
| disarmSystem()   | SecuritySystemDisarmer       |  
| cancelSystem()   | SecuritySystemAlarmCanceller |  
  
특정 역할 외에도 근무 시간 제약(ABAC)이나 알림 목록 포함 여부 등 추가 조건이 적용될 수 있다.  
  
---  
  
##### 인가 검증 위치  
  
1. **네트워크 인프라**: 서비스 메시, ingress controller 등에서 간단한 권한 체크 가능  
2. **REST API 핸들러**: 요청 수준 coarse-grained 인가 처리  
3. **도메인 로직**: 복잡한 조건 기반의 인가 처리  
4. **DB 접근 계층**: SQL 내부에서 인가 필터링 (대용량 처리에 효과적)  
  
---  
  
##### UI에서의 인가  
  
UI는 인가를 강제할 수는 없지만, 사용자 권한에 따라 버튼/기능을 표시하거나 비활성화하는 방식으로 UX를 최적화할 수 있다.  
  
---  
  
##### 마이크로서비스 아키텍처에서의 인증  
  
BFF(Backend For Frontend)가 로그인 및 세션 관리 담당.  
각 마이크로서비스는 독립 실행되므로 사용자 정보를 세션에서 직접 접근할 수 없고, JWT 등 토큰으로 사용자 정보를 전달해야 한다.  
  
---  
  
##### 마이크로서비스 아키텍처에서의 인가  
  
BFF → SecurityService 순으로 요청이 전달되며, 다음 세 가지 위치에서 인가 검증이 가능하다:  
  
1. **BFF**: 세션 정보 기반으로 경로 및 메서드에 따른 요청 수준 인가 가능  
2. **Inter-service Network**: 서비스 메시가 JWT 기반의 인가 일부 수행  
3. **각 서비스 내부**: 도메인 로직과 DB 접근 계층에서 인가 수행  
  
---  
  
##### 분산 인가의 어려움  
  
각 서비스가 필요한 정보를 자체 DB에 가지지 않기 때문에, 인가를 위해 타 서비스 API 호출이 필요할 수 있다.  
이를 JWT로 해결하려는 방식도 있지만, 토큰 크기와 검증 비용이 문제가 된다.  
  
---  
  
##### 정리  
  
* 인증은 사용자 신원 확인, 인가는 권한 판단  
* `isAllowed(user, operation, resource)` 패턴이 인가 핵심  
* RBAC, ReBAC, ABAC 세 가지 인가 모델을 조합하여 구현  
* 모놀리식에서는 단일 DB 접근으로 인가가 쉬우나  
* 마이크로서비스에서는 인가를 위한 데이터가 흩어져 있어 구현이 더 복잡함

## Comments



_No public comments on this page._