인증
인증 vs 권한 부여
- 인증: 이 사용자는 누구입니까? (로그인/로그아웃, 신원 확인)
- 권한 부여: 이 사용자는 무엇을 할 수 있습니까? (권한, 역할, 접근 제어)
아키텍처 개요
풀스택 인증 모델
서버 측(보안)
- 세션 저장 및 검증
- 사용자 자격 증명 검증
- 데이터베이스 작업
- 토큰 생성/검증
- 보호된 API 엔드포인트
클라이언트 측(공개)
- 인증 상태 관리
- 라우트 보호 로직
- 로그인/로그아웃 사용자 인터페이스
- 리디렉션 처리
이소모픽(둘 다)
- 라우트 로더가 인증 상태를 확인합니다
- 공유 검증 로직
- 사용자 프로필 데이터 접근
세션 관리 패턴
HTTP 전용 쿠키(권장)
- 가장 안전한 방식입니다 - JavaScript로는 접근할 수 없습니다.
- 브라우저가 자동으로 처리합니다.
sameSite와 함께 제공되는 내장 CSRF 보호 기능- 전통적인 웹 애플리케이션에 가장 적합합니다.
JWT 토큰
- 무상태 인증
- API 우선 애플리케이션에 적합합니다.
- XSS 취약점을 피하려면 신중하게 처리해야 합니다.
- 리프레시 토큰 순환을 고려합니다.
서버 측 세션
- 중앙 집중식 세션 제어
- 세션을 쉽게 폐기할 수 있습니다.
- 세션 저장소(데이터베이스, Redis)가 필요합니다.
- 즉시 세션 제어가 필요한 애플리케이션에 적합합니다.
라우트 보호 아키텍처
레이아웃 라우트 패턴(권장)
- 부모 레이아웃 라우트로 전체 라우트 하위 트리를 보호합니다.
- 인증 로직을 중앙 집중화합니다.
- 모든 자식 라우트가 자동으로 보호됩니다.
- 인증된 라우트와 공개 라우트를 깔끔하게 분리합니다.
컴포넌트 수준 보호
- 컴포넌트 내 조건부 렌더링
- UI 상태에 대한 더 세밀한 제어
- 같은 라우트에서 공개/비공개 콘텐츠가 섞인 경우에 적합합니다.
- 레이아웃 이동을 방지하려면 신중하게 처리해야 합니다.
데이터/API 보호(보안 경계)
- 비공개 데이터를 읽거나 쓰는 모든 서버 함수, 서버 라우트 또는 API 엔드포인트에 권한 부여를 적용합니다.
- 보호된 라우트가 먼저 로드되지 않았더라도 권한 없는 요청은 거부합니다.
- route guard를 UX와 탐색 제어로 취급하고, 데이터 경계로 보지 않습니다.
상태 관리 패턴
서버 주도 상태(권장)
- 인증 상태를 매 요청마다 서버에서 가져옵니다.
- 서버 상태와 항상 최신으로 유지됩니다.
- SSR과 매끄럽게 작동합니다.
- 가장 안전한 방식입니다 - 서버가 단일 진실 공급원입니다.
컨텍스트 기반 상태
- 클라이언트 측 인증 상태 관리
- Auth0, Firebase 같은 제3자 인증 제공자에 적합합니다.
- 서버 상태와 신중하게 동기화해야 합니다.
- 상호작용이 많은 클라이언트 우선 애플리케이션을 고려할 만합니다.
하이브리드 접근 방식
- 초기 상태는 서버에서 가져오고, 클라이언트 측에서 업데이트합니다.
- 보안과 UX 사이의 균형을 맞춥니다.
- 주기적인 서버 측 검증
인증 옵션
🏢 파트너 솔루션
🛠️ 직접 구현하는 인증
TanStack Start의 서버 함수와 세션 관리를 사용해 직접 인증 시스템을 구축합니다. 인증 서버 기본 요소 가이드를 먼저 참고하면 되며, 여기에는 세션 쿠키(HttpOnly/Secure/SameSite/__Host-), 미들웨어로서의 세션 조회, OAuth state + PKCE, 비밀번호 재설정 열거 공격 방어, CSRF, 요청 제한, 세션 회전, 그리고 흔한 실수를 잡아내는 WRONG/CORRECT 패턴이 포함됩니다.
- 완전한 제어: 인증 흐름을 완전히 맞춤화할 수 있습니다.
- 서버 기본 요소: 세션, OAuth, CSRF, 요청 제한 - 인증 서버 기본 요소를 참고하세요.
- 세션 관리:
setResponseHeader를 통해 HTTP 전용 쿠키를 사용하고,getRequestHeader로 읽습니다. - 타입 안정성: 인증 상태에 대한 엔드투엔드 타입 안정성을 제공합니다.
🌐 기타 훌륭한 옵션
오픈 소스 및 커뮤니티 솔루션:
- Better Auth - 최신 TypeScript 우선 인증 라이브러리입니다.
- Auth.js (이전 NextAuth.js) - React용으로 널리 쓰이는 인증 라이브러리입니다.
호스팅 서비스:
- Supabase Auth - 내장 인증이 포함된 오픈 소스 Firebase 대안입니다.
- Auth0 - 풍부한 기능을 갖춘 검증된 인증 플랫폼입니다.
- Firebase Auth - Google의 인증 서비스입니다.
파트너 솔루션
WorkOS - 엔터프라이즈 인증
- Single Sign-On (SSO) - SAML, OIDC, 및 OAuth 통합
- Directory Sync - Active Directory 및 Google Workspace를 위한 SCIM 프로비저닝
- Multi-factor Authentication - 엔터프라이즈급 보안 옵션
- Compliance Ready - SOC 2, GDPR, 및 CCPA 준수
Clerk - 완전한 Authentication 플랫폼
- 바로 사용 가능한 UI 컴포넌트 - 로그인, 회원가입, 사용자 프로필, 조직 관리
- 소셜 로그인 - Google, GitHub, Discord, 및 20개 이상의 제공업체
- Multi-factor Authentication - SMS, TOTP, 및 백업 코드
- Organizations & Teams - 팀 기반 애플리케이션을 위한 기본 지원
Clerk 방문하기 → | 무료로 가입하기 → | 예제 보기 →
예제
파트너 솔루션:
DIY 구현:
클라이언트 사이드 예제:
아키텍처 결정 가이드
Authentication 접근 방식 선택하기
파트너 솔루션:
- 핵심 비즈니스 로직에 집중할 수 있습니다
- 엔터프라이즈 기능(SSO, compliance)
- 관리형 보안 및 업데이트
- 사전 구축된 UI 컴포넌트
OSS 솔루션:
- 커뮤니티 주도 개발
- 특정 커스터마이징
- 자체 호스팅 솔루션
- 벤더 종속성 방지
DIY 구현:
- auth 흐름에 대한 완전한 제어
- 맞춤형 보안 요구사항
- 특정 비즈니스 로직 요구사항
- Authentication 데이터에 대한 완전한 소유권
프로덕션 Auth 체크리스트
- 프로덕션에서는 HTTPS를 사용하고 강력한 session secret을 설정합니다.
- 세션은
HttpOnly,Secure,SameSite쿠키에 저장합니다. 세션 토큰은localStorage이나sessionStorage에 저장하지 않습니다. - 개인, 테넌트, 또는 계정 데이터를 읽거나 쓰는 모든 서버 함수, server route, 또는 API endpoint에서 인증을 강제합니다. 페이지 UX에는
beforeLoad를 사용하고, 데이터 경계로는 사용하지 않습니다. - 입력을 받는 모든 서버 함수에
.validator()를 사용합니다. - 비밀번호는 bcrypt, scrypt, 또는 Argon2로 해시합니다. 사용자 정보가 없을 때는 더미 해시에 대해 검증하고 동일한 로그인/재설정 메시지를 반환합니다.
- 로그인, 등록, 비밀번호 재설정 endpoint를 rate limit합니다.
- 비-GET server function과 server route에는 CSRF 또는 same-origin 보호를 사용합니다.
- 인증 이벤트를 기록하고 실패를 모니터링합니다.
- 보호된 서버 함수에 대한 직접적인 인증되지 않은 호출을 테스트합니다. 데이터가 반환되기 전에 거부되어야 합니다.
다음 단계
리소스
구현 가이드:
- 인증 서버 프리미티브 — 세션, 쿠키, OAuth, CSRF, 요청 속도 제한(서버 측)
- 인증 패턴
- Router 인증 가이드
기반 개념:
단계별 튜토리얼: