통합 회원 관리(SSO/OIDC)와 글로벌 인증 구조

1. 배경 — "로그인은 하나, 서비스는 전 세계"

이전까지는 각 국가별로 별도의 회원 시스템을 운영했다. 태국, 한국, 중국, 말레이시아의 서비스가 모두 다른 사용자 DB를 가졌고, 글로벌 공급사는 국가별로 중복 계정을 등록해야 했다. 로그인 토큰도 서버별로 상이해 SSO(Single Sign-On)가 불가능했다.

이 구조가 만들어낸 문제는 명확했다. 하나의 공급사가 태국과 한국에서 모두 활동하려면 두 개의 계정이 필요하고, 각각 별도로 로그인해야 하며, 프로필 정보도 따로 관리해야 한다. 5개 플랫폼(Trade, Logistics, Workflow, Document AI, Delivery)이 각자 독립된 인증 시스템을 가지고 있다면 파트너 수가 4,300개를 넘어선 시점에서 운영은 사실상 불가능하다.

6월에 이 구조를 완전히 개편하며, 단일 로그인으로 모든 국가의 모든 서비스에 접근할 수 있는 통합 인증 체계를 구축했다.

2. 왜 SSO와 OIDC인가

SSO는 한 번의 로그인으로 여러 서비스에 접근하는 것을 의미한다. OIDC(OpenID Connect)는 OAuth 2.0 위에 구축된 인증 표준으로, 사용자의 신원을 검증하고 ID Token을 발급하는 프로토콜이다.

REINDEERS가 OIDC를 선택한 이유는 세 가지다. 첫째, 각 플랫폼이 독립적으로 배포되더라도 하나의 인증 서버만 바라보면 된다. 둘째, Google, LINE, WeChat, Kakao 등 소셜 로그인 제공자와의 연동이 표준화된 방식으로 가능하다. 셋째, ID Token의 서명 검증만으로 인증 상태를 확인할 수 있어 각 서비스가 Auth 서버에 매번 질의하지 않아도 된다.

3. MCP Auth 아키텍처

인증 서버는 MCP Auth라는 이름으로 독립 구축되었다. 모든 프런트엔드(Nuxt/Vue3), API Gateway, Cloud Function은 이 Auth 서버를 통해 인증을 수행한다.

Auth Server: FastAPI + PostgreSQL + Redis
Token: PASETO(v2.local) + JWT(v5 hybrid)
Cache: Redis 복제 (홍콩 ↔ 서울)
SSO Provider: Google, LINE, WeChat, Kakao
Notification: Telegram Bot (로그인 실패, 세션 만료)

API 서버는 MCP Auth의 공개키를 이용해 모든 토큰을 검증한다. 공개키는 JWKS(JSON Web Key Set) 엔드포인트를 통해 배포되며, 각 서비스는 시작 시점에 키를 캐싱하고 1시간마다 갱신한다. Auth 서버에 장애가 발생해도 이미 캐싱된 키로 토큰 검증이 가능하므로 서비스 전체가 동시에 중단되는 상황을 방지한다.

4. 회원 및 권한 테이블 구조

CREATE TABLE organization (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(255) NOT NULL,
  country_code CHAR(2) NOT NULL,
  type ENUM('CUSTOMER','SUPPLIER','FORWARDER','OPERATOR') NOT NULL
);

CREATE TABLE user_account (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  org_id BIGINT NOT NULL,
  email VARCHAR(255) UNIQUE,
  password_hash VARCHAR(255),
  display_name VARCHAR(255),
  status ENUM('ACTIVE','SUSPENDED','PENDING') DEFAULT 'PENDING',
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (org_id) REFERENCES organization(id)
);

CREATE TABLE user_role (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  role_name VARCHAR(64) NOT NULL,
  platform VARCHAR(64) NOT NULL,
  FOREIGN KEY (user_id) REFERENCES user_account(id)
);

권한은 RBAC(Role-Based Access Control)으로 관리된다. 역할은 플랫폼별로 분리되어 있어, 동일한 사용자가 Trade 플랫폼에서는 buyer 역할을, Logistics 플랫폼에서는 logistics_admin 역할을 가질 수 있다.

리소스 수준의 세밀한 접근 제어는 ABAC(Attribute-Based Access Control) 정책으로 보완한다. 예를 들어, country_code='TH' 속성을 가진 계정만 태국 세관 API에 접근할 수 있고, org_type='FORWARDER' 속성을 가진 계정만 배송 추적 데이터를 수정할 수 있다. RBAC는 "어떤 기능에 접근할 수 있는가"를 결정하고, ABAC는 "어떤 데이터에 접근할 수 있는가"를 결정한다.

5. OIDC 로그인 플로우와 토큰 발급

로그인은 OIDC Authorization Code Flow를 따른다. 사용자가 소셜 로그인 버튼을 클릭하면 Provider(Google, LINE 등)로 리다이렉트되고, 인증 성공 후 Authorization Code가 MCP Auth로 전달된다. Auth 서버는 이 코드를 Provider와 교환하여 사용자 정보를 획득하고, 내부 계정과 매칭한 뒤 Access Token과 Refresh Token을 발급한다.

from paseto import PasetoV2
from datetime import datetime, timedelta
import jwt

SECRET = os.getenv("PASETO_SECRET")
JWT_SECRET = os.getenv("JWT_SECRET")

def issue_tokens(user_id, roles, org_id):
    now = datetime.utcnow()
    access = PasetoV2.encrypt({
        "uid": user_id,
        "org": org_id,
        "roles": roles,
        "exp": (now + timedelta(minutes=30)).timestamp()
    }, SECRET)
    refresh = jwt.encode({
        "uid": user_id,
        "exp": now + timedelta(days=7)
    }, JWT_SECRET, algorithm="HS256")
    return {
        "access_token": access,
        "refresh_token": refresh,
        "expires_in": 1800
    }

Access Token은 PASETO로 발급된다. PASETO는 JWT의 보안 취약점을 보완한 토큰 형식으로, 알고리즘 혼동 공격(Algorithm Confusion Attack)이 원천적으로 불가능하다. Refresh Token은 JWT로 발급되며, 만료 시간은 7일이다. Access Token이 만료되면 클라이언트는 Refresh Token으로 새 Access Token을 발급받는다.

6. 클라이언트 토큰 관리 — LocalStorage 표준

클라이언트 단의 토큰 저장은 LocalStorage를 표준으로 한다. Access/Refresh 토큰 및 메타 정보는 다음 키로 저장된다.

reindeers.access — Access Token
reindeers.refresh — Refresh Token
reindeers.session.meta — 만료시간, 사용자, 스코프 정보

export default defineNuxtPlugin((nuxtApp) => {
  const ACCESS_KEY = 'reindeers.access'
  const REFRESH_KEY = 'reindeers.refresh'
  const META_KEY = 'reindeers.session.meta'
  const accessToken = useState('access', () => null)
  const refreshToken = useState('refresh', () => null)
  const sessionMeta = useState('sessionMeta', () => null)

  if (process.client) {
    accessToken.value = localStorage.getItem(ACCESS_KEY)
    refreshToken.value = localStorage.getItem(REFRESH_KEY)
    const raw = localStorage.getItem(META_KEY)
    sessionMeta.value = raw ? JSON.parse(raw) : null
  }

  watch(accessToken, (v) => v
    ? localStorage.setItem(ACCESS_KEY, v)
    : localStorage.removeItem(ACCESS_KEY))
  watch(refreshToken, (v) => v
    ? localStorage.setItem(REFRESH_KEY, v)
    : localStorage.removeItem(REFRESH_KEY))

  window.addEventListener('storage', (e) => {
    if (e.key === ACCESS_KEY) accessToken.value = e.newValue
    if (e.key === REFRESH_KEY) refreshToken.value = e.newValue
  })
})

브라우저의 storage 이벤트를 활용하여 여러 탭에서도 로그인 상태가 즉시 동기화된다. 한 탭에서 로그아웃하면 다른 탭에서도 자동으로 로그아웃된다. CSP(Content Security Policy)가 적용되어 외부 스크립트의 토큰 접근을 차단하며, 토큰 수명은 30분으로 제한하여 XSS 노출 시 피해 범위를 최소화한다.

7. 파트너 온보딩 인증 플로우

신규 파트너(공급사, 바이어, 포워더)가 REINDEERS에 가입하는 과정은 다음과 같다.

파트너가 가입 신청서를 제출하면 user_account가 PENDING 상태로 생성된다.
운영팀이 사업자 등록 정보와 연락처를 검증한다.
승인 시 ACTIVE로 전환되며, 소속 조직(organization)에 연결된다.
역할(role)이 할당되고, 해당 파트너에게 초대 이메일이 발송된다.
파트너가 최초 로그인 시 비밀번호 설정 또는 소셜 계정 연동을 진행한다.

이 프로세스에서 핵심은 "조직(Organization)"과 "사용자(User)"가 분리되어 있다는 점이다. 한 조직에 여러 사용자가 소속될 수 있고, 각 사용자에게 다른 역할을 부여할 수 있다. 조직의 대표자가 탈퇴해도 조직 데이터는 유지되며, 새 대표자가 권한을 이어받는다.

8. 리전 간 세션 동기화와 보안 모니터링

세션은 Redis를 통해 지역 간 자동 동기화된다. 홍콩 리전에서 로그인한 사용자의 세션 데이터가 MQ 이벤트를 통해 서울 리전의 Redis에도 복제되므로, 리전을 이동해도 재로그인이 필요 없다.

보안 모니터링은 Telegram Bot으로 통합되었다. 동일 계정에서 5분 내 3회 이상 로그인 실패가 감지되면 즉시 알림이 발송되고, 10회 이상 실패 시 해당 계정이 자동으로 일시 정지된다. 운영자는 /authstatus 명령으로 현재 활성 세션 수, 최근 로그인 실패 이력, 리전별 세션 분포를 실시간으로 모니터링할 수 있다.

import os, requests

def notify_auth_failure(user_email, ip, fail_count):
    msg = (f"로그인 실패 알림\n"
           f"계정: {user_email}\n"
           f"IP: {ip}\n"
           f"연속 실패: {fail_count}회\n"
           f"{'계정 일시 정지됨' if fail_count >= 10 else '모니터링 중'}")
    requests.post(
        f"https://api.telegram.org/bot{os.getenv('TELEGRAM_TOKEN')}/sendMessage",
        json={"chat_id": os.getenv("TELEGRAM_CHAT_ID"), "text": msg})

9. 결론 — 글로벌 단일 인증의 완성

이제 REINDEERS의 5개 플랫폼은 하나의 계정으로 로그인된다. 국가와 리전에 상관없이 동일한 인증 체계를 공유하며, 세션은 Redis를 통해 실시간 복제된다. 4,300개 이상의 파트너가 중복 계정 없이 단일 ID로 모든 서비스에 접근한다.

OIDC 표준을 채택함으로써 향후 새로운 소셜 로그인 제공자를 추가하거나 새로운 플랫폼을 런칭할 때도 Auth 서버의 설정만 변경하면 된다. 인증은 플랫폼의 기반 인프라이며, "로그인은 단일화되고, 관리자는 세계 어디서나 통제할 수 있다"는 원칙이 기술적으로 완성되었다.

Blog

Search This Blog