API & 웹앱 인증 라이브러리 2026 완벽 가이드 - Auth.js v5 · Lucia v3 · better-auth · Clerk · Stytch · WorkOS · Kinde · SuperTokens · Frontegg 심층 분석

프롤로그 — 2026년에 "인증을 직접 만드는 게 맞나?"

2010년대에 "로그인 화면 정도는 직접 만든다"가 기본값이었다. 2020년대 초반에 Auth0와 Firebase Auth가 등장하면서 "인증은 SaaS에 외주 주는 게 맞다"가 주류가 됐다. 그리고 2026년, 우리는 다시 한 번 갈림길에 섰다.

• 한쪽에서는 Clerk, Stytch, WorkOS, Kinde, Frontegg 같은 매니지드 SaaS가 패스키, MFA, SSO, SCIM까지 박스 안에 넣고 월 $25~$1000+로 판매한다.
• 다른 한쪽에서는 Auth.js v5(구 NextAuth), Lucia v3(2025년 EOL 예정이었지만 better-auth로 흐름이 옮겨감), better-auth 같은 OSS 라이브러리가 "당신의 DB, 당신의 코드, 당신의 도메인"을 외친다.
• 그 사이에 SuperTokens, Logto, Ory 같은 "오픈소스 SaaS" 옵션이 끼어 있다. 셀프호스트도 되고, 매니지드 호스팅도 받을 수 있다.

이 글은 그 지형 전체를 본다. 라이브러리·SaaS 옵션을 하나씩 보고, OAuth 흐름과 패스키 같은 프로토콜 레이어를 풀고, B2B 요구사항(SSO/SCIM/감사로그)을 정리하고, 한국·일본 로컬 인증 제공자까지 다룬다. 마지막에 "누가 무엇을 골라야 하는지" 권고한다.

1장 · 2026년 웹앱 인증 지형도 — Library vs Managed vs OSS-SaaS

크게 세 가지 진영이 있다.

┌──────────────────────────────────────────────────────────────────────┐
│                  2026년 웹앱 인증 옵션 3 카테고리                      │
│                                                                      │
│  ┌────────────────┐   ┌────────────────┐   ┌────────────────────┐   │
│  │  Library       │   │  Managed SaaS  │   │  OSS-SaaS / Hybrid │   │
│  │  (DIY)         │   │  (Buy)         │   │  (Self-host OK)    │   │
│  │                │   │                │   │                    │   │
│  │ - Auth.js v5   │   │ - Clerk        │   │ - SuperTokens      │   │
│  │ - Lucia v3     │   │ - Stytch       │   │ - Logto            │   │
│  │ - better-auth  │   │ - WorkOS       │   │ - Ory Network      │   │
│  │ - iron-session │   │ - Kinde        │   │ - Keycloak Cloud   │   │
│  │ - Passport.js  │   │ - Frontegg     │   │ - Hanko Cloud      │   │
│  │ - JOSE/jose    │   │ - Auth0        │   │                    │   │
│  └────────────────┘   └────────────────┘   └────────────────────┘   │
│       ↑                     ↑                       ↑                │
│   당신의 DB             그들의 DB                 둘 다 가능          │
│   당신의 도메인         그들의 위젯               대부분 둘 다        │
│   $0/MAU              $25~$2000+/M             $0~수백/M            │
└──────────────────────────────────────────────────────────────────────┘

각 진영의 강점과 약점.

2026년의 큰 흐름: 하이브리드가 늘었다. "Clerk으로 시작하고 MAU 5만 넘으면 better-auth로 이주"가 흔한 시나리오다. 이주 비용이 만만찮으니 초기 선택이 여전히 중요하다.

2장 · Auth.js v5 (구 NextAuth.js) — Node/Next.js 사실상 표준

Auth.js v5는 NextAuth.js의 후속이다. 2024년 v5로 메이저 리브랜드를 하면서 Next.js 외에 SvelteKit, SolidStart, Express, Hono 등으로 어댑터를 확장했다.

핵심 모델

• Auth Core + 프레임워크 어댑터 + DB 어댑터 + 프로바이더 4계층.
• DB 어댑터: Prisma, Drizzle, Kysely, TypeORM, MongoDB, DynamoDB 등.
• 프로바이더: Google, GitHub, Apple, Microsoft, NAVER, Kakao 등 80+ OAuth 프로바이더 + Email + Credentials.
• 세션은 기본 JWT 쿠키. 어댑터를 붙이면 DB 세션도 가능.

// auth.ts (Next.js App Router)
import NextAuth from 'next-auth'
import Google from 'next-auth/providers/google'
import { PrismaAdapter } from '@auth/prisma-adapter'
import { prisma } from '@/lib/prisma'

export const { auth, handlers, signIn, signOut } = NextAuth({
  adapter: PrismaAdapter(prisma),
  providers: [Google],
  session: { strategy: 'database' },
  callbacks: {
    async session({ session, user }) {
      session.user.id = user.id
      return session
    },
  },
})

v5의 변경점 (v4 → v5)

• getServerSession → auth() 단일 헬퍼.
• 환경변수 자동 추론 (AUTH_GOOGLE_ID 등).
• Edge 런타임 호환 개선.
• account.providerAccountId 정책 변경 — 마이그레이션 가이드 필수.

강점 / 약점

• 강점: 풀 OSS, 무료, Next.js 친화, 거대 커뮤니티, 80+ 프로바이더.
• 약점: 패스키는 베타 어댑터, MFA/SCIM 미지원(직접 구현), 디버깅 어려운 마법 존재.
• 한 줄 평: "Next.js를 쓰면서 매니지드를 안 쓸 거면 시작점은 Auth.js v5"

3장 · Lucia v3 → better-auth로의 흐름

Lucia v3 (저자: pilcrowOnPaper)는 2023~2024년에 "프레임워크에 종속되지 않은 미니멀 세션 라이브러리"로 인기를 끌었다. 핵심은 Lucia 객체 + 어댑터 + 직접 작성하는 라우트. 매직이 거의 없어서 보안에 민감한 팀이 선호했다.

그러나 2025년 3월, 저자는 Lucia의 메인티넌스 모드 진입을 선언했다. 이유: "라이브러리보다는 학습 자료(Copy & Paste)로 가는 게 맞다." 그 자리를 빠르게 채운 게 better-auth다.

better-auth — TypeScript-first, 플러그인 아키텍처

better-auth (저자: bekacru)는 2024년 등장해 2025년 폭발적으로 성장했다. 디자인은 다음과 같다.

• TypeScript-first, 타입 추론 완벽.
• 플러그인 아키텍처 — 패스키, OAuth, 매직링크, 2FA, 조직(Organization) 등 모두 플러그인.
• 프레임워크 어댑터 — Next.js, SvelteKit, Nuxt, Hono, Express, Astro 등.
• 자체 클라이언트 SDK — useSession, signIn, signOut을 프레임워크별로 자동 생성.

// auth.ts
import { betterAuth } from 'better-auth'
import { prismaAdapter } from 'better-auth/adapters/prisma'
import { passkey, twoFactor, organization } from 'better-auth/plugins'

export const auth = betterAuth({
  database: prismaAdapter(prisma, { provider: 'postgresql' }),
  emailAndPassword: { enabled: true },
  socialProviders: {
    google: { clientId: process.env.GOOGLE_CLIENT_ID!, clientSecret: process.env.GOOGLE_CLIENT_SECRET! },
  },
  plugins: [passkey(), twoFactor(), organization()],
})

Auth.js vs better-auth

2026년 시점에서 신규 Next.js 프로젝트라면 better-auth를 진지하게 검토할 가치가 있다. Auth.js는 안정성과 생태계, better-auth는 기능 풍부함과 타입 안전성으로 갈린다.

4장 · Clerk — 매니지드 UX의 황금 표준

Clerk(2021 창업, YC W21)은 2024~2026년 매니지드 인증 SaaS의 사실상 표준이 됐다. 강점은 명확하다.

• 박스 안의 아름다운 React UI 컴포넌트 — <SignIn />, <SignUp />, <UserButton />.
• 패스키, MFA(TOTP/SMS/백업코드), 매직 링크, OAuth 50+ 프로바이더 박스 안.
• 조직(B2B), 권한, 초대, 영구 세션, 디바이스 관리, 활성 세션 보기.
• Next.js, React, Remix, Expo 등 SDK 풍부.

가격 (2026년 1분기 기준)

• Free: MAU 10,000까지, 기본 기능.
• Pro: $25/월 + MAU$0.02 (~10,000 MAU 추가시).
• Business: $99/월부터, SAML SSO 추가.
• Enterprise: 요청 견적, SCIM, 감사 로그, SOC2 Type II.

코드 샘플

// app/layout.tsx
import { ClerkProvider } from '@clerk/nextjs'

export default function RootLayout({ children }) {
  return (
    <ClerkProvider>
      <html><body>{children}</body></html>
    </ClerkProvider>
  )
}

// app/sign-in/page.tsx
import { SignIn } from '@clerk/nextjs'
export default function Page() {
  return <SignIn />
}

Clerk의 함정

• MAU 가격 폭증 — MAU 5만 넘으면 월 $1,000+ 쉽게 넘는다. 시드/프리시드 스타트업은 안전하지만 시리즈 A 이후 청구서 충격 흔하다.
• 도메인 종속 — Clerk이 호스팅하는 페이지(accounts.your-app.com)에 의존. 100% 자기 도메인은 Business 이상.
• 데이터 이전 — 사용자 데이터는 Clerk이 보유. 마이그레이션 가능하지만 패스워드는 다시 받아야 함.

5장 · Stytch — 패스워드리스 중심, B2C/B2B 분리

Stytch(2020 창업, 시리즈 B $$로 평가)는 패스워드리스 인증에 가장 일찍 집중했다.

• 매직 링크, 이메일 OTP, SMS OTP, WhatsApp OTP, 패스키, OAuth, TOTP.
• B2C SDK와 B2B SDK 분리 — B2B는 조직, SSO, SCIM, 멤버 관리를 내장.
• 헤드리스 SDK가 강점 — 자기 UI를 만들고 백엔드는 Stytch.

B2B SaaS 시나리오에서 강점

Stytch B2B는 조직 단위로 인증이 설계됐다.

• 조직마다 SSO(SAML/OIDC) 연결 가능.
• 조직마다 MFA 정책 (필수/선택).
• 조직마다 권한과 역할 (Owner, Admin, Member, Stytch Resource 기반 RBAC).
• 도메인 매칭 자동 가입 (예: @acme.com 이메일은 Acme 조직 자동 추가).

import { StytchClient } from 'stytch'

const stytch = new StytchClient({
  project_id: process.env.STYTCH_PROJECT_ID!,
  secret: process.env.STYTCH_SECRET!,
})

// 매직 링크 발송
await stytch.magicLinks.email.loginOrCreate({
  email: 'user@acme.com',
  login_magic_link_url: 'https://app.example.com/auth/callback',
})

가격

• Stytch Consumer Free: MAU 10,000까지.
• Pro: MAU $0.05 + 기능별.
• Stytch B2B: 조직별, 보통 $99/조직/월 + 기능.

6장 · WorkOS — 엔터프라이즈 SSO/SCIM에 특화

WorkOS는 "B2B SaaS가 엔터프라이즈로 올라갈 때 막히는 SSO/SCIM/감사로그를 한 박스로 푼다"가 포지셔닝이다.

• SSO Connections: SAML 2.0, OIDC, Google Workspace, Microsoft Entra, Okta, OneLogin, JumpCloud 등 30+.
• Directory Sync (SCIM): Okta, Microsoft Entra, JumpCloud, Rippling, BambooHR, Workday 등 25+.
• Audit Logs, Magic Link, MFA, Admin Portal(고객이 직접 IdP 연결).
• AuthKit — 무료 호스티드 로그인 페이지(Clerk 비슷).

핵심 가격 모델

WorkOS의 가격은 다른 곳과 다르다.

• SSO: $99 / 연결 / 월. 10번째 연결부터 할인.
• SCIM(Directory Sync): $0.125 / 사용자 / 월.
• Audit Logs: $0.05 / 이벤트.
• AuthKit: 1M MAU까지 무료.

즉 B2B 한 고객(엔터프라이즈)이 SSO로 $99/월이면 그게 곧 매출인 셈이다. "엔터프라이즈 한 명 = 평균 LTV 수만 달러"라는 SaaS 비즈니스에 잘 맞춘 가격.

코드 샘플 — SSO 흐름

import { WorkOS } from '@workos-inc/node'

const workos = new WorkOS(process.env.WORKOS_API_KEY!)

// 1) 로그인 URL 생성
const authUrl = workos.sso.getAuthorizationUrl({
  connection: 'conn_01EHWNCE74X7JSDV0X3SZ3KJNY',
  redirectUri: 'https://app.example.com/callback',
  clientId: process.env.WORKOS_CLIENT_ID!,
})

// 2) 콜백에서 프로필 가져오기
const { profile, accessToken } = await workos.sso.getProfileAndToken({
  code: searchParams.code,
  clientId: process.env.WORKOS_CLIENT_ID!,
})

7장 · Kinde — 풀스택 매니지드, "Auth0보다 싸고 단순"

Kinde(2022 호주 창업)는 "Auth0의 복잡함과 가격을 줄인다"가 목표였다. 결과적으로 다음을 박스 안에 넣는다.

• B2C 사용자 인증 + B2B 조직(테넌트).
• 기능 플래그(자체 플래그 시스템 포함).
• 결제(Stripe 연동), 권한, 역할.
• 호스티드 로그인 페이지 또는 자기 UI.

가격

• Free: MAU 10,500까지.
• Plus: $25/월 부터 + MAU.
• Scale, Enterprise는 견적.

특이점: Free 플랜이 가장 넉넉. 1만 MAU 무료가 2026년 시점에서 가장 후하다.

8장 · SuperTokens — 오픈소스 SaaS, 셀프호스트 가능

SuperTokens (2020 창업, YC W21)는 오픈소스 + 매니지드의 양다리 모델이다.

• 코드는 모두 오픈소스. Apache 2.0.
• Core 서비스(SuperTokens Core) + 백엔드 SDK + 프론트 SDK 분리.
• SaaS로 호스팅하거나, 자신의 인프라(Docker, K8s)에 띄울 수 있다.
• 패스워드리스, 패스키, OAuth, 세션, MFA, 멀티테넌트.

가격

• Self-hosted: $0. 본인 인프라.
• Managed Core: MAU 5,000까지 무료, 이후 $0.02/MAU.

코드 샘플

import SuperTokens from 'supertokens-node'
import Session from 'supertokens-node/recipe/session'
import ThirdPartyEmailPassword from 'supertokens-node/recipe/thirdpartyemailpassword'

SuperTokens.init({
  framework: 'express',
  supertokens: {
    connectionURI: 'http://localhost:3567', // 또는 managed core URL
  },
  appInfo: {
    appName: 'My App',
    apiDomain: 'https://api.example.com',
    websiteDomain: 'https://example.com',
  },
  recipeList: [
    ThirdPartyEmailPassword.init({ /* providers */ }),
    Session.init(),
  ],
})

SuperTokens의 한 줄 평: "오픈소스 충성도가 높지만 매니지드도 받고 싶을 때."

9장 · Frontegg — B2B 매니지드 고객 인증

Frontegg(2019 이스라엘 창업)는 B2B SaaS의 고객 인증을 풀스택으로 풀겠다는 포지셔닝이다.

• 조직(테넌트), 사용자, 역할, 권한, SSO, SCIM, 감사로그, 알림.
• 호스티드 로그인 박스 + 어드민 포털.
• 가격은 견적 기반 — 보통 시드/시리즈 A에는 비싸다.

WorkOS와 포지셔닝이 겹치지만 차이가 있다.

• WorkOS: B2B의 SSO/SCIM 인프라 레이어. 자기 인증 시스템과 결합.
• Frontegg: B2B 인증 전체 박스. 자기 인증 시스템 거의 안 만든다.

10장 · Hanko — 패스키-퍼스트 OSS

Hanko는 독일발 OSS 프로젝트로 "패스워드를 죽이자"가 슬로건. 패스키, WebAuthn, 패스코드(OTP) 중심.

• Go로 작성된 백엔드 서비스 + JS 웹 컴포넌트.
• Hanko Cloud 매니지드 옵션 + 셀프호스트.
• <hanko-auth /> 웹 컴포넌트가 핵심 — 어느 프레임워크든 동작.

<script type="module" src="https://esm.sh/@teamhanko/hanko-elements/dist/elements.js"></script>
<hanko-auth api="https://your-hanko-api.example.com"></hanko-auth>

패스키만 빠르게 깔고 싶다면 Hanko가 가장 단순하다. 다만 OAuth 소셜 로그인 지원이 다른 라이브러리보다 얇다.

11장 · Passport.js / iron-session / jose — Node 레거시 + 미니멀

세 가지 클래식.

• Passport.js (Jared Hanson, 2011~) — Node Express 시대의 표준. 500+ 전략(strategy). 2026년 기준 활발한 유지보수는 아니지만 여전히 광범위하게 사용. 모듈러 OAuth/OIDC를 직접 조립할 때 유용.
• iron-session (Vercel/community) — 암호화된 쿠키 세션. 별도 DB 없이 "쿠키 안에 세션을 다 넣는다". Next.js Edge에서 가볍게 쓰기 좋다.
• jose (Filip Skokan) — JWT/JWS/JWE/JWK 표준 라이브러리. 직접 JWT를 발급/검증할 때 사실상 표준.

// jose로 JWT 발급 / 검증
import { SignJWT, jwtVerify } from 'jose'

const secret = new TextEncoder().encode(process.env.JWT_SECRET!)

const token = await new SignJWT({ sub: 'user-42' })
  .setProtectedHeader({ alg: 'HS256' })
  .setExpirationTime('15m')
  .sign(secret)

const { payload } = await jwtVerify(token, secret)

세 라이브러리는 위의 큰 SaaS/라이브러리들의 "내부 부품"이다. 직접 조립하는 팀이 줄었지만, API 게이트웨이나 마이크로서비스 인증에서는 여전히 1선 도구.

12장 · OAuth 흐름 — Authorization Code with PKCE가 정답

2026년에 OAuth 흐름은 다음과 같이 정리됐다.

┌─────────────────────────────────────────────────────────────────┐
│                  2026년 OAuth 흐름별 권고                       │
│                                                                 │
│  Authorization Code + PKCE      → 웹앱, 모바일, SPA ✓ (표준)   │
│  Client Credentials              → 서버 간 (M2M) ✓             │
│  Device Authorization            → TV/CLI/IoT ✓                │
│  Refresh Token Rotation          → 모든 흐름과 결합 ✓          │
│  Resource Owner Password         → 금지 (레거시 호환만)         │
│  Implicit Flow                   → 폐지 (PKCE로 대체)           │
└─────────────────────────────────────────────────────────────────┘

OAuth 2.1 (드래프트 → 2024~2025년 RFC 진행)에서 Implicit과 ROPC는 공식 제거됐다. 새 코드에서 절대 쓰지 말 것.

PKCE — SPA/모바일의 필수

PKCE(Proof Key for Code Exchange, RFC 7636)는 SPA와 모바일에서 client_secret을 보관할 수 없는 문제를 푼다.

1. 클라이언트가 code_verifier(랜덤 문자열) 생성.
2. SHA256 해시를 code_challenge로 IdP에 전송.
3. IdP가 authorization_code 발급.
4. 토큰 교환 시 클라이언트가 원래 code_verifier를 보냄.
5. IdP가 해시 비교 후 액세스 토큰 발급.

이 흐름으로 중간자가 authorization_code를 가로채도 토큰 교환을 못한다. 2026년 모든 모던 IdP/라이브러리가 기본 활성화한다.

13장 · 패스키 / WebAuthn — 2026년 사실상 표준

2026년 시점에서 패스키 채택은 임계점을 넘었다.

• Apple, Google, Microsoft 세 OS가 모두 패스키를 1급 시민으로 지원.
• 1Password, Bitwarden, Dashlane이 크로스 디바이스 패스키 동기화 지원.
• 주요 사이트(GitHub, Google, Amazon, Microsoft, eBay, PayPal, X, Best Buy 등)가 패스키 로그인 활성화.
• FIDO Alliance 통계상 패스키 인증 시도가 패스워드 대비 평균 4배 빠름.

패스키의 작동 원리 요약

1. 등록 시: 디바이스가 공개키/비공개키 쌍 생성. 비공개키는 디바이스(Secure Enclave/TPM)에 머무름.
2. 서버는 공개키만 받음.
3. 로그인 시: 서버가 챌린지(랜덤 nonce) 발급. 디바이스가 비공개키로 서명. 서버가 공개키로 검증.
4. iCloud Keychain / Google Password Manager로 디바이스 간 동기화 가능.

라이브러리/SaaS별 패스키 지원 (2026Q1)

SimpleWebAuthn — 직접 구현할 때

직접 WebAuthn을 다룬다면 SimpleWebAuthn이 2026년 사실상 표준 라이브러리다. 백엔드(@simplewebauthn/server)와 브라우저(@simplewebauthn/browser) 양쪽 제공.

14장 · 매직 링크 / OTP / TOTP — 패스워드리스의 세 축

매직 링크, OTP(SMS/이메일), **TOTP(인증 앱)**는 패스워드의 대안이자 MFA의 두 번째 요소로 쓰인다.

매직 링크 구현 핵심

매직 링크는 단일 사용, 짧은 만료, IP/디바이스 바인딩이 핵심이다.

// 매직 링크 토큰 발급
const token = crypto.randomBytes(32).toString('base64url')
const hash = createHash('sha256').update(token).digest('hex')

await db.magicLink.create({
  data: {
    userId: user.id,
    tokenHash: hash, // 원본 저장 금지
    expiresAt: new Date(Date.now() + 15 * 60 * 1000), // 15분
    ip: request.ip,
  },
})

const url = `https://example.com/auth/verify?token=${token}`
await sendEmail({ to: user.email, magicLinkUrl: url })

Twilio Verify — SMS OTP의 사실상 표준

SMS OTP는 직접 구현하지 말고 Twilio Verify, Vonage, AWS SNS 같은 매니지드를 쓰는 게 일반적이다. 이유:

• 국가별 SMS 도달률, 통신사 차단, AUP가 복잡.
• 캐리어 룩업, 음성 OTP 폴백.
• SMS 폭격 공격 방어(가입 폼에 무한 OTP 요청).

2026년 시점에서 SMS 비용 자체가 1통 $0.01~$0.10. 트라피킹(traffic pumping) 공격으로 한 달 수천 달러 손해 사례가 늘었다. 반드시 rate limiting + reCAPTCHA/Turnstile를 결합.

15장 · 세션 vs JWT — 2026년의 올바른 답

영원한 토론. 2026년의 답은 명확하다: 세션 > JWT, 단 액세스 토큰은 단명 JWT.

비교표

2026년 권장 패턴 — 하이브리드

┌─────────────────────────────────────────────────────────┐
│                  하이브리드 권장 흐름                    │
│                                                         │
│  1) 로그인 후 서버가 발급:                              │
│     - access_token (JWT, 5~15분, 페이로드에 권한)       │
│     - refresh_token (불투명, DB 저장, 7~30일)           │
│                                                         │
│  2) API 호출 시 access_token으로 인증                   │
│     - 서명 검증만, DB 안 봄                             │
│                                                         │
│  3) access 만료 시 refresh로 갱신                       │
│     - DB의 refresh 행 확인 후 새 access 발급            │
│     - refresh도 회전(rotation) — 사용된 건 무효화       │
│                                                         │
│  4) 즉시 로그아웃 시 refresh 행 삭제                    │
│     - access는 자연 만료까지 유효                       │
│     - 더 빠른 차단이 필요하면 access도 짧게             │
└─────────────────────────────────────────────────────────┘

이 패턴은 OAuth 2.0의 refresh token rotation과 동일하다. 2026년 모던 IdP/라이브러리 디폴트.

16장 · 토큰 저장 — HttpOnly 쿠키가 정답

브라우저에서 토큰을 어디 저장하는가가 끊임없는 논쟁이다.

권장 조합

• 세션 ID 또는 refresh token → HttpOnly + Secure + SameSite=Lax 쿠키.
• 액세스 토큰 → 메모리 (페이지 새로고침 시 refresh로 재발급).
• 또는 모두 HttpOnly 쿠키(BFF 패턴).

CSRF 방어: SameSite=Lax/Strict + state 토큰 또는 double-submit cookie. SameSite만으로 CSRF가 완전 방어되지는 않는다(같은 사이트 sub-domain 공격, GET state-changing 등).

17장 · OWASP A07 — 인증 실패 Top 5 함정

OWASP Top 10 2021의 A07: Identification and Authentication Failures. 2026년에도 살아있는 함정.

1) 무차별 대입 보호 부재

• 사용자명/IP/디바이스별 카운터.
• 점진적 지연(exponential backoff) 또는 CAPTCHA.
• 5번 실패 시 15분 락아웃, 10번 실패 시 1시간, 그 이상은 관리자 개입.

2) 계정 열거(Account Enumeration)

• 로그인 실패 메시지가 "사용자 없음" / "패스워드 틀림"으로 다르면 안 됨 → 항상 "이메일 또는 비밀번호가 일치하지 않습니다".
• 가입 시 "이미 등록된 이메일"도 즉시 알려주면 위험 → 이메일 발송으로 알림.

3) 약한 비밀번호 정책

• NIST 800-63B 권고: 최소 길이 8~12, 회전 강제 금지(공격받으면 즉시 교체), 공통 패스워드 차단(HaveIBeenPwned 리스트).
• 복잡도 강요(특수문자 등)는 효과 미미 — 길이가 더 중요.

4) 세션 고정(Session Fixation)

• 로그인 직후 세션 ID 반드시 재발급.
• 권한 상승 시(예: 관리자 모드 진입)에도 재발급.

5) 비밀번호 저장 실패

• bcrypt (코스트 ≥ 12), Argon2id, scrypt 중 택일.
• MD5/SHA1/SHA256 단독 사용 금지. PBKDF2는 최소 600,000 iteration.
• 솔트는 사용자별 무작위 16바이트 이상.

18장 · B2B 인증 요구사항 — SSO / SCIM / 감사 / IP / MFA 강제

B2B SaaS가 엔터프라이즈 고객을 잡으려면 다음 다섯이 거의 필수다.

1. SSO (SAML 2.0 + OIDC) — Okta, Microsoft Entra, Google Workspace 등 IdP 연동.
2. SCIM (System for Cross-domain Identity Management) — 고객 IdP에서 사용자 생성/비활성화가 자동 반영.
3. 감사 로그 — 누가 언제 무엇을 했는지. SOC2, ISO 27001, HIPAA 요건.
4. IP 허용목록 / 거부목록 — 특정 IP 대역에서만 로그인.
5. MFA 강제 — 조직 단위로 "MFA 필수" 정책.

"엔터프라이즈 인증 세금"

B2B SaaS 업계에는 "엔터프라이즈 SSO 요구하면 가격이 10배"라는 농담이 있다. 이유:

• 직접 구현이 어렵다(SAML 디버깅의 악몽).
• WorkOS, Frontegg 같은 SaaS가 SSO 연결당 $99/월을 받는다.
• 그래서 SaaS 자체도 엔터프라이즈 플랜에서 SSO를 잠그고 $1,000+/월을 받는다.

라이브러리로 만들 때는 boxyhq/saml-jackson이나 SuperTokens의 멀티테넌트 모드를 검토할 가치가 있다.

19장 · 한국 인증 — NAVER · Kakao · PASS · 카카오 인증서

한국 시장에 특화된 인증 흐름.

• NAVER 로그인 — OAuth 2.0 표준. Auth.js, better-auth에 빌트인.
• Kakao 로그인 — OAuth 2.0. 30~40대 사용자 비중 큼.
• KakaoTalk 지갑 / 인증서 — 모바일 인증. 핀테크/공공.
• PASS 앱 — 통신 3사(SKT, KT, LG U+)의 통합 본인 확인 서비스.
• 간편 본인 확인 — 휴대폰 번호 + 통신사 인증.
• i-PIN(아이핀) — 주민번호 대체 — 2024년 이후 사실상 사장.
• 공동인증서(舊 공인인증서) — 금융권. 모바일 OS 패스 인증서로 대체 추세.

Auth.js에서 NAVER 추가

// auth.ts
import Naver from 'next-auth/providers/naver'

export const { auth } = NextAuth({
  providers: [
    Naver({
      clientId: process.env.NAVER_CLIENT_ID!,
      clientSecret: process.env.NAVER_CLIENT_SECRET!,
    }),
  ],
})

Kakao도 동일한 패턴. 한국 사용자가 주 타겟이면 둘 다 거의 필수.

20장 · 일본 인증 — LINE · Yahoo!Japan · Mercari · d ACCOUNT

일본 시장 특화.

• LINE Login — 메신저 LINE 기반. 일본 B2C 거의 필수.
• Yahoo!Japan ID — 야후 재팬 사용자 베이스 광범위.
• Mercari ID — 메르카리 생태계.
• d ACCOUNT (NTT 도코모) — 통신사 통합.
• au ID, SoftBank ID — 다른 통신사.
• マイナンバーカード(My Number Card) — 공공 본인 확인. eKYC.

LINE Login 추가

Auth.js에 LINE 프로바이더가 있다. 일본 사용자 비중이 큰 서비스(특히 이커머스, 음식 배달, 게임)는 LINE을 1차 옵션으로 두는 게 표준.

21장 · 봇 방어 — Turnstile · hCaptcha · reCAPTCHA Enterprise · Arkose

CAPTCHA는 2026년에 거의 보이지 않는 방향으로 진화했다.

• Cloudflare Turnstile — 무료, 보이지 않는 챌린지. Cloudflare 트래픽 신호로 봇 판정. 2026년 추세 1위.
• hCaptcha — 무료/유료, 시각 챌린지 대체. Cloudflare/Discord 등 채택.
• Google reCAPTCHA Enterprise — 점수 기반(0~1), 매우 정밀. 유료.
• Arkose Labs — 패즐 챌린지. 봇 농장 운영비를 비싸게 만들어 차단.

Cloudflare Turnstile 사이드 by 사이드

<form action="/login" method="POST">
  <div class="cf-turnstile" data-sitekey="YOUR_SITE_KEY"></div>
  <button type="submit">Sign in</button>
</form>
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>

서버 검증.

const response = await fetch('https://challenges.cloudflare.com/turnstile/v0/siteverify', {
  method: 'POST',
  body: new URLSearchParams({
    secret: process.env.TURNSTILE_SECRET!,
    response: token,
    remoteip: clientIp,
  }),
})

2026년 신규 프로젝트라면 Turnstile부터 검토. 무료이고 UX가 가장 매끄럽다.

22장 · AI 시대의 봇 방어 — 패시브 신호 + 행동 분석

LLM 시대에 자동화 공격이 폭증했다. 2026년의 봇 방어는 다음이 결합된다.

• 패시브 디바이스 지문(canvas, WebGL, 폰트, 타임존).
• 마우스 / 키스트로크 다이내믹스.
• 네트워크 신호(IP 평판, ASN, VPN/프록시 감지, 거주지 IP vs 데이터센터).
• 세션 행동 분석(가입 → 로그인 → 행동 시퀀스의 통계적 이상).

Castle, Sift, Stytch Fraud & Risk, Arkose Bot Manager 같은 매니지드가 이 영역을 채운다. 직접 구현은 매우 어렵다.

23장 · 마이그레이션 시나리오 — Clerk → Auth.js, Auth0 → Stytch

매니지드에서 라이브러리로(또는 다른 매니지드로) 이주하는 시나리오가 흔하다.

Clerk → Auth.js + Postgres

1. Clerk Admin Dashboard에서 사용자 export(JSON).
2. Postgres에 users, accounts, sessions 테이블 만들고 import.
3. 비밀번호 해시 이관 불가 — Clerk는 자기 해시를 안 준다. 두 가지 옵션:
   • 옵션 A: 모든 사용자에게 "비밀번호 재설정" 이메일 발송.
   • 옵션 B: 패스워드 없이 매직 링크/OAuth만 허용.
4. OAuth 계정은 accounts 테이블의 providerAccountId로 다시 매핑.
5. 활성 세션은 무효화 → 모두 재로그인.

Auth0 → Stytch

Auth0 패스워드 해시는 export 시 받을 수 있다(bcrypt). Stytch가 bcrypt 해시 import를 받기 때문에 비밀번호 그대로 이관 가능.

Stytch Migration Docs 참조.

키 회전과 점진적 이주

대규모 서비스는 이중 발행 기간을 둔다.

• 한동안 Auth0와 Stytch 양쪽에 토큰 발급.
• 클라이언트가 신규 토큰을 우선 사용하고, 실패 시 구 토큰 폴백.
• 일정 기간 후 구 IdP 종료.

24장 · 누가 무엇을 골라야 하나

지형을 다 봤으니 결정 트리.

START
  │
  ├─ MVP / 사이드 프로젝트 / MAU < 10,000인가?
  │     YES → Auth.js v5 또는 Clerk Free
  │            (Next.js → better-auth 검토)
  │
  ├─ B2C 대규모 (MAU 10만+) + 매니지드 가능?
  │     YES → Clerk 또는 Stytch
  │     (가격 시뮬레이션 필수)
  │
  ├─ B2B SaaS 엔터프라이즈 SSO 필요?
  │     YES → WorkOS (SSO/SCIM)
  │           + 자체 인증 (Auth.js / better-auth)
  │           또는 Stytch B2B / Frontegg 통합
  │
  ├─ 데이터 주권 / 셀프호스트 필수?
  │     YES → SuperTokens (셀프호스트)
  │           또는 Logto, Ory Network (별도 글)
  │
  ├─ 패스키-퍼스트로 패스워드 없애기?
  │     YES → Hanko 또는 Clerk
  │
  ├─ 미니멀 / 코드 가시성 / 의존성 최소?
  │     YES → iron-session + jose 조립
  │
  └─ 한국 / 일본 사용자 비중 큼?
        YES → 위 선택 + NAVER/Kakao(KR) 또는 LINE/Yahoo!JP(JP) 프로바이더
              직접 추가

에필로그 — 2026년 인증의 다음 결정 지점

세 가지 큰 흐름을 정리한다.

1. 패스키는 더 이상 옵션이 아니다. 2026년 신규 프로젝트가 패스키 없이 출시되는 건 보안 부채의 시작이다. Clerk, Stytch, Hanko, better-auth 중 어느 걸 쓰든 패스키를 켜라.
2. MAU 가격 모델을 시뮬레이션하라. Clerk/Stytch/Auth0의 $25~99/월은 출발 단가일 뿐이다. MAU 10만에서의 청구서를 모델링하고, 5만 시점에 이주 계획을 세워두는 게 안전하다.
3. B2B로 가면 WorkOS 같은 SSO 레이어를 일찍 검토하라. 엔터프라이즈 고객이 SSO를 요구할 때 직접 구현하면 2~4주가 SSO 디버깅에 녹는다. 미리 깔아두는 게 싸다.

"인증 라이브러리/SaaS 선택은 6개월의 빠른 출시와 5년의 운영 비용을 동시에 결정한다. 빠른 시작만 보지 말고 마이그레이션 비용을 함께 보라."

같은 매니지드라도 데이터 포터빌리티(특히 비밀번호 해시 export 가능 여부)가 5년 후의 자유도를 결정한다. 인증을 인프라 결정으로 다룰 것 — 데이터베이스 선택만큼 무겁게.

참고 / References

• Auth.js v5 Documentation
• NextAuth.js → Auth.js Migration Guide
• Lucia auth — github lucia-auth/lucia (maintenance mode)
• better-auth — Documentation
• better-auth GitHub — bekacru/better-auth
• Clerk Documentation
• Clerk Pricing
• Stytch Documentation
• Stytch B2B Authentication
• WorkOS Documentation
• WorkOS Pricing
• Kinde Documentation
• SuperTokens GitHub — supertokens/supertokens-core
• Frontegg Documentation
• Hanko — Passkey-first OSS
• Logto — github logto-io/logto
• Ory Network — Kratos / Hydra / Keto
• Keycloak
• SimpleWebAuthn — MasterKale/SimpleWebAuthn
• Passport.js
• iron-session — vvo/iron-session
• jose — panva/jose JWT library
• boxyhq/jackson — SAML Jackson
• OAuth 2.1 Draft RFC
• RFC 7636 — PKCE
• OWASP Top 10 2021 — A07 Identification and Authentication Failures
• NIST SP 800-63B Digital Identity Guidelines
• FIDO Alliance — Passkeys
• Have I Been Pwned — Pwned Passwords
• Cloudflare Turnstile
• hCaptcha
• Twilio Verify API
• NAVER Login Developers
• Kakao Login Developers
• LINE Login Developers
• Yahoo! JAPAN Developer Network — Yahoo ID連携