인증 구현 가이드 2026 — JWT, OAuth, Passkey

JWT의 가장 큰 함정은 한번 발급한 토큰을 서버에서 강제로 만료시킬 수 없다는 점을 잊는 것입니다. Access Token 수명을 길게 잡아두면 탈취당했을 때 차단할 방법이 없으니, 짧은 만료 + DB에 저장한 Refresh Token으로 폐기 가능하게 만들어야 합니다. 또 Refresh Token을 회전(rotation) 없이 재사용하면 한 번 새면 계속 악용되니 1회 사용 후 폐기가 원칙입니다. 비밀번호를 SHA256으로 해싱하거나 JWT Secret을 짧게 두는 것, OAuth를 모바일·SPA에서 PKCE 없이 쓰는 것도 반복되는 실수입니다.

인증 방식부터 보면, 자체 서버에서 무상태 세션을 유지하려면 JWT, 사용자가 가진 구글·깃허브 계정으로 가입을 간소화하려면 OAuth 2.0, 피싱을 원천 차단하고 비밀번호 자체를 없애려면 Passkey가 적합합니다. 다만 Passkey는 아직 모든 사용자 기기·브라우저가 지원하는 게 아니라, 단독으로만 두면 일부 사용자가 로그인 못 하는 상황이 생기므로 기존 방식과 병행하는 게 안전합니다. 라이브러리는 Next.js 단일 프로젝트면 무료 오픈소스 NextAuth.js, 프레임워크에 묶이기 싫고 세션을 직접 통제하고 싶으면 Lucia, 가입 UI까지 통째로 맡기고 비용을 감수할 수 있으면 유료 SaaS인 Clerk, 이미 Supabase를 쓴다면 내장된 Supabase Auth가 맞습니다. 어떤 경우든 인증 로직을 처음부터 직접 짜는 것은 보안 사고 위험이 커서 부적합합니다.

Next.js에서 바로 써먹을 거라면 Auth.js 공식 문서(authjs.dev)가 첫 자료입니다. 프로바이더 설정부터 세션 콜백, JWT 전략까지 예제 코드가 있어 그대로 따라 하기 좋습니다. OAuth의 동작 원리를 제대로 이해하려면 Authorization Code Flow와 PKCE를 다이어그램으로 설명한 RFC 6749·RFC 7636을 읽거나, oauth.net의 정리본을 보시면 됩니다. Passkey는 W3C의 WebAuthn 명세와 함께 webauthn.guide를 보면 공개키 등록·인증 과정을 그림으로 빠르게 잡을 수 있고, 토큰 구조가 헷갈리면 jwt.io에서 실제 JWT를 디코딩해 헤더·페이로드·서명을 눈으로 확인하는 것이 도움이 됩니다.

2026년 인증의 큰 흐름은 비밀번호 없는 Passkey(FIDO2/WebAuthn)로 이동 중이지만, 현실의 기존 시스템에서는 여전히 JWT에 짧은 Access Token과 DB 저장 Refresh Token을 더하고 소셜 로그인은 OAuth 2.0(Authorization Code + PKCE)으로 위임하는 조합이 가장 실용적입니다. 직접 구현하지 말고 NextAuth.js·Lucia·Clerk·Supabase Auth 같은 검증된 라이브러리를 쓰는 것이 핵심이며, 비밀번호는 bcrypt나 argon2로 해싱하고 HTTPS와 토큰 회전(rotation)은 타협 불가 원칙으로 지켜야 합니다.

인증을 직접 짜지 말고 검증된 라이브러리부터 고르는 것이 먼저입니다. Next.js라면 NextAuth.js(Auth.js)가 소셜 로그인·세션·CSRF 보호를 기본으로 주고, 프레임워크에 안 묶이고 싶으면 Lucia, UI까지 통째로 맡기려면 유료 SaaS인 Clerk, 이미 Supabase를 쓴다면 Supabase Auth를 그대로 쓰면 됩니다. 라이브러리를 정한 뒤에는 Access Token 만료를 15분 안팎으로 짧게 두고 Refresh Token은 DB에 저장하도록 토큰 수명 설계를 먼저 확정하세요. 직접 구현은 보안 사고 위험이 커서 권하지 않습니다.