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

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

간단히 말해

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

핵심 내용

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

1. 암호화된 서버 측 세션 쿠키(HttpOnly + SameSite=Lax)를 인증 상태로 사용합니다. 클라이언트 측 JWT는 이제 끝났습니다.
2. OIDC(Google/Apple/GitHub)를 비밀번호 없이 온보딩할 때 사용합니다.
3. 패스키(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년에 시작한다면 규제적 이유가 없다면 제공업체(Clerk, WorkOS, Stack Auth)를 사용하세요. 절약한 엔지니어링 시간을 제품 개발에 투자하세요. 둘째, JWT-in-localStorage 기반의 레거시 스택이 있다면 세션 쿠키로 마이그레이션 계획을 세우세요.これは安全性向上을 위한 필수 작업이지, 단순 미화 작업이 아닙니다. 셋째, 패스키는 준비되었습니다. 지금은 옵션으로 활성화하고 2027년까지 엔터프라이즈에서 필수로 전환하세요. 주시할 점: 플랫폼 간 패스키 표준화(실제 B2B 장애 요소)입니다.