diff --git a/docs/architecture/00_아키텍쳐.md b/docs/architecture/00_아키텍쳐.md index 16f54a4..8b7802d 100755 --- a/docs/architecture/00_아키텍쳐.md +++ b/docs/architecture/00_아키텍쳐.md @@ -76,6 +76,12 @@ modified: 2025-07-07 API 키 관리의 복잡성과 보안 리스크를 해결하기 위해, OAuth와 프록시 호출을 활용한 'Keyless' API 중개 플랫폼을 도입합니다. 사용자는 플랫폼에 한 번만 인증하면, 플랫폼이 백그라운드에서 필요한 API 키를 안전하게 관리하고 대신 호출해주는 구조입니다. 이를 통해 개발자 경험(DX)을 극대화하고 보안을 강화합니다. +#### auth-server: 멀티테넌트 인증 허브 +**로빙 생태계의 중앙 인증 시스템**으로 B2B 고객사별 Slack 봇 인증 및 OAuth 토큰 관리를 담당합니다. +- 회사별 독립 서브도메인 제공 (예: `company.auth.ro-being.com`) +- Google/Slack OAuth 통합 인증, JWT 기반 사용자 세션 관리 +- 상세 스키마: [auth-server 데이터베이스 스키마](./auth-server-database-schema.md) + #### 기술 구조 - **통합 인증**: 사용자는 플랫폼에만 로그인합니다. 플랫폼은 각 API 제공사에 필요한 인증 토큰(OAuth)을 내부적으로 관리하거나, 자체 Vault에 안전하게 저장된 API 키를 사용하여 **프록시 호출**(Proxy Call)을 수행합니다. - **정책 토큰**: 사용자의 요청은 단순한 API 호출이 아닌, 권한과 허용 범위가 명시된 서명된 토큰(예: JWT)과 함께 전달됩니다. API 게이트웨이는 이 토큰을 검증하여 안전한 호출을 보장합니다. diff --git a/docs/architecture/로빙_아키텍쳐_설계_경량.md b/docs/architecture/로빙_아키텍쳐_설계_경량.md index f1ccc19..db538ea 100644 --- a/docs/architecture/로빙_아키텍쳐_설계_경량.md +++ b/docs/architecture/로빙_아키텍쳐_설계_경량.md @@ -29,8 +29,8 @@ ├───────────────────────┼───────────────────────┤ │ │ │ ┌────▼─────┐ ┌─────▼──────┐ ┌──────▼─────┐ - │ 상태 │ │ 공용 스킬 │ │ 인증 │ - │ 서비스 │ │ 서버 │ │ 서비스 │ + │ 상태 │ │ 공용 스킬 │ │auth-server │ + │ 서비스 │ │ 서버 │ │(인증허브) │ └────┬─────┘ └────────────┘ └────────────┘ │ ┌────▼─────┐ ┌────────────┐ @@ -578,7 +578,7 @@ services: ### Q3: Slack 인증 정보는 어디서 관리하고 어떻게 불러오는가? -**A**: Slack 인증 정보는 State Service가 중앙에서 관리합니다. 각 회사의 Slack 토큰들은 암호화되어 PostgreSQL에 저장되고, 로빙 컨테이너는 시작할 때 State Service의 `GET /company/{company_id}/state` API를 호출하여 복호화된 토큰을 받아옵니다. 이 방식으로 토큰 갱신이 필요할 때 State Service에서만 업데이트하면 모든 컨테이너가 재시작 시 자동으로 새 토큰을 받게 됩니다. +**A**: **auth-server**가 멀티테넌트 인증 허브 역할을 담당합니다. 회사별 Slack 봇 토큰과 OAuth 정보를 중앙 관리하며, 각 로빙 컨테이너는 필요시 auth-server를 통해 인증 정보를 조회합니다. 상세 구조는 [auth-server 데이터베이스 스키마](./auth-server-database-schema.md) 참조. ## 13. 성능 최적화