아키텍트의 딜레마: Clerk에서 Auth0로 인증 마이그레이션

Source: Dev.to

배경 스토리

풀‑스택 엔지니어이자 Delta Auth의 설립자로서, 저는 사용자와 애플리케이션 사이의 “핸드쉐이크”에 무수히 많은 시간을 투자해 왔습니다. 최근 사이버보안 회사의 전체 인프라를 Clerk에서 Auth0로 이전하는 중요한 마이그레이션을 주도했습니다.

Clerk가 개발자 경험 면에서 “왕”이라 할지라도, Auth0와 같은 엔터프라이즈 급 솔루션으로 전환하면 대부분의 튜토리얼이 다루지 않는 아키텍처적 난관이 발생합니다.

핵심 과제: 보이지 않는 지속성

제가 마주한 가장 큰 마찰점은 API가 아니라 httpOnly 쿠키를 이해하는 것이었습니다. 처음에는 사용자가 전역 상태 라이브러리인 Zustand나 Redux에 데이터를 저장하지 않고도 라우트 간에 로그인 상태를 유지할 수 있는 방법을 파악하는 데 어려움을 겪었습니다.

제가 발견한 논리는 다음과 같습니다: 브라우저는 당신의 보안 담당자이며, 상태 관리자가 아닙니다.

1. 왜 httpOnly인가?

고보안 환경에서는 JavaScript가 위험 요소가 됩니다. 악성 스크립트가 localStorage를 읽을 수 있다면 세션이 탈취됩니다. httpOnly 쿠키를 사용하면 세션 토큰을 JavaScript가 접근할 수 없는 “잠긴 금고”에 넣는 것이므로 보안이 강화됩니다.

2. “Sync” 패턴

Next.js 프론트엔드가 쿠키를 “볼 수” 없기 때문에 서버‑사이드 브리지를 설계해야 했습니다. 프론트엔드가 “토큰이 있나요?” 라고 물어보는 대신, 백엔드 미들웨어가 모든 요청에서 자동으로 쿠키를 확인합니다.

// middleware.ts – The Onwodi Logic Bridge
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  // The 'invisible' cookie being checked server‑side
  const session = request.cookies.get('auth0_session_token');

  const { pathname } = request.nextUrl;

  // Protect sensitive routes without needing Frontend State
  if (!session && pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  return NextResponse.next();
}