DOCS/journey/ideas/250810_auth_system_analysis.md

로빙 프로젝트 인증 시스템 전체 분석 및 통합 방안

현재 구조 분석

1. 데이터베이스 (PostgreSQL - main_db)

Users 테이블 구조

- id: UUID (Primary Key)
- username: VARCHAR(50) UNIQUE  # happybell80 등
- email: VARCHAR(255) UNIQUE NOT NULL
- name: VARCHAR(255)
- picture: VARCHAR(500)  # OAuth profile picture URL
- oauth_provider: VARCHAR(50)  # google, github 등
- oauth_id: VARCHAR(255)  # Provider의 user ID
- is_active: BOOLEAN
- created_at, updated_at, last_login_at: TIMESTAMP

WorkspaceMembers 테이블

- user_id: UUID (FK to users.id)
- workspace_id: UUID
- robeing_id: VARCHAR(100)  # rb8001, rb10508 등
- role: ENUM (owner, member, guest)

2. Auth Server (51123 서버, 포트 9000)

JWT 토큰 구조

# 토큰 생성 시 페이로드 (gmail.py:183-188)
{
    "sub": username,        # "happybell80" - 주요 식별자
    "email": user_email,    # "goeun2dc@gmail.com"
    "name": user_name,      # "김고은"
    "username": username,   # "happybell80" (중복)
    "exp": expires_at
}

환경 변수

• JWT_SECRET_KEY: ro-being-auth-jwt-secret-key-2024
• JWT_ALGORITHM: HS256
• JWT_EXPIRATION_DAYS: 30 (일) # 코드에서 사용
• JWT_ACCESS_TOKEN_EXPIRE_MINUTES: 30 (분) # .env에만 존재, 미사용

이메일-유저명 매핑 (하드코딩)

# gmail.py:150-154
email_to_username = {
    'goeun2dc@gmail.com': 'happybell80',
    'eagle0914@gmail.com': 'eagle0914',
}

3. Frontend (frontend-customer)

토큰 저장/조회

• 저장 키: auth_token (auth-context.tsx:61)
• 조회: localStorage.getItem('auth_token') (auth-context.tsx:29)
• 서버 URL: https://auth.ro-being.com (하드코딩)

현재 문제점

// robeing-api.ts - 토큰 전송 안함!
export async function sendMessage(text: string, userId: string = 'test_user') {
    // Authorization 헤더 없음
    // 모든 사용자가 'test_user'로 처리됨
}

4. Robeing Gateway (포트 8100)

현재 처리 방식

# main.py:92-95
x_user_id: Optional[str] = Header(None)  # X-User-Id 헤더만 확인
# JWT 토큰 검증 없음!

5. Robeing Services (51124 서버)

ChromaDB 컬렉션명 생성

# rb10508_micro/app/core/memory/storage.py
collection_name = f"{settings.ROBEING_ID}_{username if username else 'default'}_{memory_type}"
# 현재: rb10508_micro_default_episodic (모든 사용자 공유!)

# 문제: endpoints.py에서 username 전달하지 않음
# endpoints.py:22 - 기본값: "default_user"

서비스 포트

• rb8001: 포트 8001
• rb10508_micro: 포트 10508
• rb10408_test: 포트 10408

환경변수 현황

• AUTH_SERVER_URL: http://192.168.0.100:9000 (설정됨)
• JWT_SECRET_KEY: your-jwt-secret-key (기본값, 변경 필요)

주요 문제점

1. 인증 토큰 미전송 ✅ 해결됨

• Frontend가 API 호출 시 JWT 토큰을 전송하지 않음
• robeing-api.ts에 Authorization 헤더 없음
• 수정 완료: robeing-api.ts:40, chat-interface.tsx:275-279에서 토큰 전송 구현

2. 백엔드 토큰 미검증 ⚠️

• Robeing Gateway가 JWT 토큰을 검증하지 않음
• X-User-Id 헤더만 확인 (누구나 위조 가능)

3. 사용자 식별 실패 및 채널별 메모리 분리 ⚠️

• endpoints.py에서 username 파라미터를 storage.py로 전달하지 않음
• user_id는 받지만 username으로 변환하지 않음
• 채널별 다른 컬렉션 사용 문제:
  • Slack: rb10508_micro_happybell80_episodic (Auth 서버 매핑 제공)
  • Frontend: rb10508_micro_default_episodic (모든 사용자 공유)
  • 동일 사용자(happybell80)가 두 채널에서 다른 메모리 공간 사용
  • 대화 내용 분리로 연속성 상실

4. 이메일-유저명 매핑 하드코딩 📝

• 새 사용자 추가 시 코드 수정 필요
• 확장성 없음

5. OAuth 권한 과다 요청 🔐

• 회원가입/로그인 시 Gmail 읽기/쓰기 권한(gmail.modify)까지 요청
• 복잡한 동의 과정으로 사용자 이탈 가능성 높음
• 이메일 기능 미사용자에게도 과도한 권한 요청

6. 변수명 불일치 혼란 🔄

• user_id vs username vs email 혼용
• JWT의 'sub'에 username 저장 중 (gmail.py:184)
• endpoints.py는 user_id 사용, storage.py는 username 필요

7. Slack 통합과 인증 체계 불일치 🔗

• Slack OAuth와 Google OAuth 별개 운영

  • Slack 워크스페이스 인증 (봇 토큰)
  • Google 개인 인증 (사용자 토큰)
  • 두 시스템 간 연결 고리 불명확

• Slack 사용자 매핑 문제

  • slack_user_id (U0925SXQFDK) ↔ user_id (UUID) 매핑 필요
  • 현재 하드코딩된 매핑 3개만 존재
  • 신규 Slack 사용자 자동 연결 방법 없음

• 복잡한 관계 구조

  Slack Workspace ← SlackWorkspaces 테이블
        ↓
  Slack User ID ← slack_user_mapping 테이블
        ↓
  User (UUID) ← users 테이블
        ↓
  Google Account (OAuth)
  

• 권한 충돌 가능성

  • Slack 봇 권한: chat:write, channels:read 등
  • Google 권한: gmail.modify, calendar.events 등
  • 같은 사용자가 두 가지 인증 경로 보유

8. JWT Secret 불일치 🔑

• Auth Server: ro-being-auth-jwt-secret-key-2024
• Robeing Services: your-jwt-secret-key (기본값)
• 토큰 검증 시 실패할 수 있음

결정 필요 사항

1. 주요 식별자 선택

• username (추천): 'happybell80' - 인간 친화적, URL 안전
• user_id (UUID): 'a1b2c3d4-...' - DB 표준, 중복 없음
• email: 'goeun2dc@gmail.com' - OAuth 표준, 변경 가능성

2. JWT 페이로드 표준화

옵션 A (username 중심):
{
    "sub": "happybell80",      // 주 식별자
    "user_id": "uuid-here",     // DB ID
    "email": "goeun2dc@gmail.com",
    "name": "김고은"
}

옵션 B (UUID 중심):
{
    "sub": "uuid-here",         // 주 식별자
    "username": "happybell80",
    "email": "goeun2dc@gmail.com",
    "name": "김고은"
}

3. API 헤더 표준화

옵션 A (Bearer 토큰만):
Authorization: Bearer <jwt_token>

옵션 B (Bearer + X-User-Id):
Authorization: Bearer <jwt_token>
X-User-Id: happybell80  // 빠른 조회용

옵션 C (Bearer + X-Username):
Authorization: Bearer <jwt_token>
X-Username: happybell80  // 명확한 이름

4. ChromaDB 컬렉션 네이밍

옵션 A: {robeing_id}_{username}_episodic
예: rb10508_happybell80_episodic

옵션 B: {robeing_id}_{user_uuid}_episodic
예: rb10508_a1b2c3d4_episodic

옵션 C: {workspace_id}_{robeing_id}_{username}_episodic
예: workspace1_rb10508_happybell80_episodic

5. 토큰 저장 키 통일

현재: 'auth_token'
대안: 'jwt_token', 'access_token', 'robeing_token'

6. OAuth 권한 분리 전략

# 옵션 A: 단계별 권한 요청 (추천) ✅
기본 로그인: openid, userinfo.email, userinfo.profile
이메일 스킬: gmail.modify (별도 연결)
캘린더 스킬: calendar.events (별도 연결)

# 옵션 B: 일괄 권한 요청 (현재)
모든 권한을 한 번에 요청 (사용자 이탈 높음)

구현 방안:

• /auth/gmail/login - 기본 프로필 권한만 (간단한 로그인)
• /auth/gmail/connect-email - Gmail 권한 추가 (이메일 아이템 사용 시)
• DB에 권한 레벨 저장: oauth_scopes 필드 추가
• Frontend에서 권한 상태 표시 및 추가 연결 버튼 제공

7. Slack과 Google 인증 통합 전략

옵션 A: 통합 인증 (하나의 주 계정)
- Google 로그인을 주 인증으로 사용
- Slack은 추가 연결 (선택적)
- 장점: 단순한 인증 흐름
- 단점: Slack 전용 사용자 지원 어려움

옵션 B: 독립 인증 (현재)
- Google과 Slack 각각 독립 인증
- 수동 매핑 필요
- 장점: 유연성
- 단점: 복잡한 관리

옵션 C: 자동 연결 (추천) ✅
- 이메일 기반 자동 매칭
- Slack 이메일 == Google 이메일 시 자동 연결
- 불일치 시 수동 연결 옵션 제공

구현 방안:

• Slack 사용자가 처음 메시지 전송 시:
  1. Slack API로 이메일 조회
  2. users 테이블에서 같은 이메일 검색
  3. 매칭되면 자동으로 slack_user_mapping 생성
  4. 없으면 임시 계정 생성 후 연결 대기

즉시 수정 필요 (Critical)

통합 해결 방안 (우선순위별)

1. Auth 서버 JWT 활용 (권장) 🌟

Frontend 로그인 → JWT(username 포함) → Gateway 검증 → Robeing username 추출
→ Slack과 동일한 컬렉션 사용 (rb10508_micro_happybell80_episodic)

2. Frontend user_id 전달 개선

로그인 후 username을 user_id로 전송
현재: user_id = "default_user"
개선: user_id = "happybell80"

3. 통합 매핑 테이블 구축

Auth 서버에 통합 매핑:
email ↔ slack_id ↔ username
- Frontend: email → username
- Slack: slack_id → username  
- 결과: 동일 username으로 통합 메모리

관련 문서: Auth DB 테이블 구조 단순화 방안

현재 테이블 구조 (5개)

• users: 사용자 기본 정보 (email, username)
• workspaces: 워크스페이스 정보 (로빙 할당)
• workspace_member: 사용자-워크스페이스 연결
• slack_workspaces: Slack 워크스페이스 정보
• slack_user_mapping: Slack ID ↔ User ID 매핑 (3개만 존재)

제안된 통합 구조 (4개 테이블로 단순화)

-- 1. users: 기존 유지
-- 2. slack_workspaces: 단순화
-- 3. user_robeings: 사용자-로빙 직접 연결
CREATE TABLE user_robeings (
    user_id UUID REFERENCES user(id),
    robeing_id VARCHAR(100),  -- rb10508_micro 등
    is_primary BOOLEAN
);

-- 4. slack_users: 통합 매핑 테이블 (핵심!)
CREATE TABLE slack_users (
    slack_user_id VARCHAR(100),  -- U0925SXQFDK
    slack_team_id VARCHAR(100),
    user_id UUID REFERENCES user(id),
    robeing_id VARCHAR(100)  -- Slack별 로빙 지정 가능
);

개별 수정 사항

1. Frontend (robeing-api.ts) ✅ 완료

// 수정 완료 - robeing-api.ts:38-41
if (token) {
  headers['Authorization'] = `Bearer ${token}`;
}

2. Gateway (main.py)

# JWT 검증 추가
from app.core.auth import decode_access_token

authorization = Header(None)
if authorization:
    token = authorization.replace("Bearer ", "")
    payload = decode_access_token(token)
    username = payload.get("sub")  # 또는 username

3. Robeing Service (rb10508_micro)

# endpoints.py 수정 필요:
# 1. JWT 토큰에서 username 추출
# 2. storage 함수 호출 시 username 전달

# storage.py는 이미 준비됨:
collection_name = f"{settings.ROBEING_ID}_{username if username else 'default'}_{memory_type}"

단계별 구현 계획

Phase 1: 긴급 패치

1. Frontend에서 토큰 전송 ✅ 완료
2. Gateway에서 토큰 검증
3. username 기반 ChromaDB 분리

Phase 2: 표준화

1. 변수명 통일 (username vs user_id)
2. JWT 페이로드 표준화
3. API 문서 작성

Phase 3: 개선

1. 이메일-유저명 매핑 DB화
2. 토큰 갱신 로직 구현
3. 권한 체계 구현

Phase 4: OAuth 권한 분리

1. 기본 로그인용 엔드포인트 구현 (최소 권한)
2. 스킬별 추가 권한 연결 엔드포인트 구현
3. DB에 사용자별 권한 상태 저장
4. Frontend에 권한 관리 UI 추가

Phase 5: Slack-Google 인증 통합

1. 이메일 기반 자동 매칭 로직 구현
2. Slack 사용자 첫 메시지 시 자동 계정 생성
3. 수동 연결 UI 개발
4. 통합 대시보드 구현

참고 사항

• JWT Secret: 모든 서비스가 같은 키 공유 필요
• CORS 설정: frontend URL 추가 필요
• Redis: 토큰 캐싱 및 세션 관리 활용
• 로그: 모든 인증 실패 상세 로깅

문서 작성자

• 작성일: 2025-08-16
• 작성자: 51123 서버 관리 Claude
• 목적: 인증 시스템 통합을 위한 현황 분석