현대 인증: 패스키, OIDC, 세션 - 진짜 짧은 목록

HN에서 인기 있는 스레드가 2026년에는 앱을 어떻게 인증해야 하는지 질문을 다시 제기했습니다. 더 이상 « JWT + refresh token »이 정답이 아닙니다. 정리된 개요를 살펴보겠습니다.

간단히 말해

2026년에는 웹 애플리케이션을 인증하는 ‘올바른’ 방법은 두 가지 질문에 달려 있습니다: (1) B2C 대중용 앱인가, 아니면 B2B SaaS인가? (2) 자체 IdP를 운영할 준비가 되었는가, 아니면 provider에 맡길 것인가? 2020년대 중반의 패턴(JWT 무상태 + localStorage의 리프레시 토큰)은 더 이상 유효하지 않습니다—그럴 만한 이유가 있습니다.

핵심 내용

HN 스레드에서 전형적인 논쟁이 반복되다 흥미로운 결론에 도달했습니다. 대부분의 애플리케이션에서 2026년의 실용적인 스택은 다음과 같습니다:

1. 암호화된 서버 측 세션 쿠키(HttpOnly + SameSite=Lax)로 인증 상태 관리. 클라이언트 측 JWT는 이제 끝났습니다.
2. OIDC(Google/Apple/GitHub)로 비밀번호 없이 온보딩.
3. 패스키(Passeys, WebAuthn)를 두 번째 단계 또는 비밀번호 완전 대체로 사용. 이제 모든 곳에서 채택되었습니다(iOS 17+, Android 13+, 모든 브라우저).
4. 서버 측 세션 짧은 회전(~1시간) + 긴 리프레시(~14일, 별도 쿠키).
5. 클라이언트 측 JWT는 진정한 무상태 멀티테넌트 기능이 필요할 때만 사용.

구조적으로 바뀐 것은 세 가지입니다. 첫째, 민감한 토큰을 localStorage에 저장하지 않음(XSS 공격 시 전체 컴퓨팅이 노출됩니다. 더 이상 논쟁의 여지가 없습니다). 둘째, 패스키의 대중화—주요 에코시스템(Google, Apple, Microsoft)에서 채택이 임계점을 넘어섰습니다(최신 상세 통계는 없지만). 셋째, Clerk, WorkOS, Auth0 같은 호스팅 IdP가 SSO/SCIM/패스키를 키트 형태로 제공하며, 5인 이하 팀은 재구현할 필요가 없습니다.

내부 동작

• 세션 쿠키: Secure; HttpOnly; SameSite=Lax; __Host- 접두사. 권한 상승 시마다 회전.
• CSRF: SameSite=Lax가 95%의 경우를 커버; 민감한 뮤테이션에는 CSRF 토큰을 추가로 사용.
• PKCE: 모든 공개 OAuth 플로우(SPA, 모바일)에서 필수.
• 흔한 함정: 패스키를 2FA로 ‘강제’ 도입하는 시기를 너무 이르면—사용자가 단일 디바이스만 보유한 경우 계정 손실로 이어질 수 있습니다.
• 유행하는 취약점: 브라우저 확장 프로그램이 SPA 메모리를 읽는 경우—localStorage에 아무것도 저장하지 말아야 한다는 또 다른 근거.

결론

세 가지 핵심 인사이트. 첫째, 2026년에 시작한다면 규제적 이유가 없다면 provider(Clerk, WorkOS, Stack Auth)를 사용하세요. 절약한 엔지니어링 시간을 제품 개발에 투자하세요. 둘째, JWT-in-localStorage 기반의 레거시 스택이 있다면 세션 쿠키로의 마이그레이션을 계획하세요—이는 보안 우선순위 작업입니다. 셋째, 패스키는 준비되었습니다. 지금은 옵션으로 활성화하고, 2027년까지 엔터프라이즈에서 필수로 도입하세요. 주시해야 할 부분: 플랫폼 간 패스키 표준화(실제 B2B 장애 요소).