DOCS/ideas/auth_system_analysis.md

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

현재 구조 분석

1. 데이터베이스 (PostgreSQL - auth_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
- robing_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_ACCESS_TOKEN_EXPIRE_MINUTES: 30일

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

# 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 (하드코딩)

현재 문제점

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

4. Robing Gateway (포트 10100)

현재 처리 방식

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

5. Robing Services (51124 서버)

ChromaDB 컬렉션명 생성

# storage.py:84 (추정)
collection_name = f"{robing_id}_{user_id}_episodic"
# 현재: rb10508_test_default_episodic (모든 사용자 공유!)

주요 문제점

1. 인증 토큰 미전송 ⚠️

• Frontend가 API 호출 시 JWT 토큰을 전송하지 않음
• robing-api.ts에 Authorization 헤더 없음
• 모든 사용자가 'test_user'로 처리

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

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

3. 사용자 식별 실패 ⚠️

• username이 제대로 전달되지 않아 'default'로 폴백
• ChromaDB 컬렉션을 모든 사용자가 공유

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

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

5. OAuth 권한 과다 요청 🔐

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

6. 변수명 불일치 혼란 🔄

• user_id vs username vs email 혼용
• JWT의 'sub'가 username인지 user_id인지 불명확

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 등
  • 같은 사용자가 두 가지 인증 경로 보유

결정 필요 사항

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: {robing_id}_{username}_episodic
예: rb10508_happybell80_episodic

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

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

5. 토큰 저장 키 통일

현재: 'auth_token'
대안: 'jwt_token', 'access_token', 'robing_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. Frontend (robing-api.ts)

// 토큰 전송 추가
const token = localStorage.getItem('auth_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. Robing Service (storage.py)

# username 기반 컬렉션 생성
collection_name = f"{robing_id}_{username}_episodic"

단계별 구현 계획

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
• 목적: 인증 시스템 통합을 위한 현황 분석