Skip to main content

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

통합 회원 관리(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에 가입하는 과정은 다음과 같다.

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

이 프로세스에서 핵심은 "조직(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 서버의 설정만 변경하면 된다. 인증은 플랫폼의 기반 인프라이며, "로그인은 단일화되고, 관리자는 세계 어디서나 통제할 수 있다"는 원칙이 기술적으로 완성되었다.

관련 글

Labels:

Popular posts from this blog

11년의 무역 데이터가 AI를 만든다 , RAG 지식 베이스 구축 과정

AI를 제품에 넣겠다고 하면 대부분 두 가지 중 하나를 떠올린다. GPT를 fine-tuning하거나, RAG를 쓰거나. 우리는 RAG를 택했다. 이유가 있다. REINDEERS는 2015년 IMARKET Thailand 설립 이후 약 11년간 동남아시아에서 B2B 무역을 해왔다. 25,000건 이상의 거래, 4,300개 이상의 파트너, 4개국의 규제 데이터. 이 데이터가 우리의 경쟁력이다. 문제는 이 데이터를 AI가 활용할 수 있는 형태로 만드는 과정이 생각보다 훨씬 복잡했다는 거다. 이 글은 그 과정에 대한 기록이다. 한 가지를 먼저 밝히고 시작한다. 이 RAG 지식 베이스는 단순히 "챗봇이 무역 지식을 참조하는 데이터 창고"가 아니다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 Agent들 , 구매 Agent, 물류 Agent, 통관 Agent, 재무 Agent , 이 사람 대신 판단을 내릴 때 "왜 이렇게 결정했는가"를 반드시 설명할 수 있어야 한다. 그 설명의 출처가 바로 이 RAG 지식 베이스다. 11년의 무역 데이터는 Agent가 환각 없이 결정을 내릴 수 있는 유일한 근거다. RAG를 선택한 이유 먼저 RAG(Retrieval-Augmented Generation)가 뭔지를 간단히 정리하자. LLM에 질문을 던질 때, 질문만 보내는 게 아니라 관련 데이터를 함께 보내는 방식이다. "태국산 베어링 수입 단가가 얼마야?"라고 물으면, 우리 데이터베이스에서 관련 거래 이력을 찾아서 LLM에 컨텍스트로 넘긴다. LLM은 그 컨텍스트를 바탕으로 답을 생성한다. Fine-tuning을 선택하지 않은 이유는 명확하다. 무역 데이터는 계속 바뀐다. 베어링 단가는 분기마다 변동한다. 태국 FDA 규제는 수시로 개정된다. 선사 운임은 매...
Read more

B2B 견적의 AI Agent화 , 고객사·공급사·포워더가 AI로 견적을 주고받는 구조

B2B 거래에서 견적은 단순한 가격표가 아니다. 바이어의 구매 이력, 공급사의 재고 상황, 물류 비용, 인코텀즈, 납기일, 결제 조건 , 이 모든 변수가 얽힌 협상의 산물이다. 현재 이 과정은 이메일과 전화, 스프레드시트로 이루어진다. 바이어가 RFQ를 보내면 공급사가 검토하고, 포워더에게 물류 견적을 받아 합산하고, 다시 바이어에게 회신한다. 건당 수일이 걸리는 이 과정을 AI Agent가 대신할 수 있다면 어떨까. REINDEERS는 이 구조를 설계하고 있다. 먼저 이 글의 전제를 분명히 한다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중에서 선택할 수 있고, 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 글의 Buyer Agent / Supplier Agent / Forwarder Agent는 외부 AI 도구가 아니라, 각 회사의 조직도 안에 '구매팀 담당자', '영업팀 담당자', '물류팀 담당자'로 실제 등록되는 AI 직원이다. 사람 직원과 동일한 권한 모델, 동일한 예산 한도, 동일한 감사 로그 위에서 일한다. B2B 견적의 AI Agent 간 통신 시퀀스 # Buyer Agent → Supplier Agent → Forwarder Agent 1 RFQ 발송 → RFQ 수신 2 물류 견적 요청 → 요청 수신 3 견적 수신 ← 상품 견적 발송 4 물류 견적 수신 ← 물류 견적 발송 ★ 비교표 생성 → 담당자 승인 5 PO 발행 → 주문 확정 6 부킹 요청 → 부킹 확정 왜 견적에 AI Agent인가 견적 업무가 느린 이유는 복잡해서가 아니다. 반복적인 정보 수집과 조합이 사람의 시간을 잡아먹기 때문이다. 공급사 담당자가 바이어의 과거 주문 이력을 ...
Read more

Reindeers Workflow: B2B 파트너 업무 효율과 자동화를 위한 워크플로우 플랫폼

B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다. 이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다. 이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다" 는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다. Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다. REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다 Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결 된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다. 거래 이벤트 트리거되는 워크플로우 실행 내용 quote.confirmed 공...
Read more