Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — In 2026, "Should we still build our own auth?"

In the 2010s, "build your own login screen" was the default. In the early 2020s, Auth0 and Firebase Auth pushed everyone to "outsource auth to SaaS." In 2026, we are back at the crossroads.

- On one side, **Clerk, Stytch, WorkOS, Kinde, Frontegg** ship passkeys, MFA, SSO, and SCIM in a box for $25 to $1000+ per month.

- On the other side, **Auth.js v5** (formerly NextAuth), **Lucia v3** (now in maintenance mode), and **better-auth** evangelize "your DB, your code, your domain."

- In the middle, **SuperTokens**, **Logto**, **Ory** offer the "open-source SaaS" option — self-host or take their managed cloud.

This article walks the whole landscape. We compare libraries vs managed vs OSS-SaaS, unpack the protocol layer (OAuth, passkeys), cover B2B requirements (SSO/SCIM/audit), and survey Korean and Japanese local ID providers. We end with a who-picks-what recommendation.

1. The 2026 Web Auth Landscape — Library vs Managed vs OSS-SaaS

Three camps.

┌──────────────────────────────────────────────────────────────────────┐

│ Three Categories of 2026 Web Auth Options │

│ │

│ ┌────────────────┐ ┌────────────────┐ ┌────────────────────┐ │

│ │ 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 │ │ │ │

│ └────────────────┘ └────────────────┘ └────────────────────┘ │

│ ↑ ↑ ↑ │

│ Your DB Their DB Either │

│ Your domain Their widgets Usually either │

│ $0/MAU $25 to $2000+/M $0 to hundreds/M │

└──────────────────────────────────────────────────────────────────────┘

Strengths and weaknesses.

| --- | --- | --- | --- |

| **Library** | Full code control, $0 cost, you own the data | 100% security responsibility, time-consuming, build passkeys/SSO yourself | 1 to 2 senior full-stack devs, MAU under 100k, you take compliance |

| **Managed** | Fast time to market, MFA/SSO/SCIM in a box, inherited SOC2 | Cost explodes with MAU, lock-in, domain coupling | Seed to Series B startups, MAU expected to spike |

The 2026 trend: **hybrid migrations** are common. "Start with Clerk, move to better-auth after 50k MAU" is a frequent path. Migration is expensive, so the initial choice still matters a lot.

2. Auth.js v5 (formerly NextAuth.js) — The Node/Next.js De Facto Standard

**Auth.js v5** is the successor to NextAuth.js. The 2024 major rebrand expanded adapters beyond Next.js to SvelteKit, SolidStart, Express, Hono, and more.

Core model

- **Auth Core** + **framework adapter** + **DB adapter** + **provider** — four layers.

- DB adapters: Prisma, Drizzle, Kysely, TypeORM, MongoDB, DynamoDB, etc.

- Providers: Google, GitHub, Apple, Microsoft, NAVER, Kakao — 80+ OAuth providers plus Email and Credentials.

- Default session is a JWT cookie. With a DB adapter you can use DB sessions.

// auth.ts (Next.js App Router)

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

})

What changed in v5 (v4 to v5)

- `getServerSession` is replaced by the single `auth()` helper.

- Auto-inferred env vars (AUTH_GOOGLE_ID, etc.).

- Better Edge runtime compatibility.

- `account.providerAccountId` policy changed — a migration guide is mandatory.

Strengths and weaknesses

- Strengths: fully OSS, free, Next.js friendly, massive community, 80+ providers.

- Weaknesses: passkeys are still a beta adapter, no built-in MFA/SCIM (build it yourself), some magic that's hard to debug.

- One-liner: "If you use Next.js and you're not going managed, your starting point is Auth.js v5."

3. The Lucia v3 to better-auth Shift

**Lucia v3** (author: pilcrowOnPaper) was popular in 2023 to 2024 as "a framework-agnostic minimal session library." Its core was a `Lucia` object + adapter + routes you wrote yourself. Almost no magic — security-sensitive teams loved it.

But in March 2025, the author announced [Lucia is entering maintenance mode](https://github.com/lucia-auth/lucia). The reasoning: "It belongs more as a learning resource (copy-paste) than as a library." The slot was quickly filled by **better-auth**.

better-auth — TypeScript-first, plugin architecture

**better-auth** (author: bekacru), launched in 2024, exploded in 2025. The design:

- TypeScript-first, perfect type inference.

- Plugin architecture — passkeys, OAuth, magic links, 2FA, Organization, all plugins.

- Framework adapters — Next.js, SvelteKit, Nuxt, Hono, Express, Astro, etc.

- Built-in client SDKs — `useSession`, `signIn`, `signOut` auto-generated per framework.

// auth.ts

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

| Dimension | Auth.js v5 | better-auth |

| --- | --- | --- |

| Launched | 2018 (NextAuth) to 2024 (v5) | 2024 |

| Frameworks | Next.js-first, multi-framework | Next.js, SvelteKit, Nuxt — equal support |

| Passkeys | Beta adapter | First-class plugin |

| 2FA / MFA | Build yourself | Plugin |

| Organizations / multi-tenant | Build yourself | Plugin |

| Type inference | OK | Stronger |

| Maturity | High | Catching up fast |

For new Next.js projects in 2026, better-auth deserves a serious look. Auth.js wins on stability and ecosystem, better-auth on feature richness and type safety.

4. Clerk — The Gold Standard of Managed UX

**Clerk** (founded 2021, YC W21) became the de facto standard for managed auth SaaS in 2024 to 2026. Its strengths are obvious.

- **Beautiful React UI components** in the box — `<SignIn />`, `<SignUp />`, `<UserButton />`.

- Passkeys, MFA (TOTP/SMS/backup codes), magic links, 50+ OAuth providers in the box.

- Organizations (B2B), permissions, invitations, persistent sessions, device management, active session view.

- Rich SDKs for Next.js, React, Remix, Expo, etc.

Pricing (Q1 2026)

- Free: up to 10,000 MAU, core features.

- Pro: $25/month + MAU at $0.02 (beyond 10,000 MAU).

- Business: starts at $99/month, SAML SSO added.

- Enterprise: custom quote, SCIM, audit logs, SOC2 Type II.

Sample code

// app/layout.tsx

export default function RootLayout({ children }) {

return (

)

}

// app/sign-in/page.tsx

export default function Page() {

return <SignIn />

}

Clerk's traps

- **MAU pricing explodes** — past 50k MAU you cross $1,000+/month easily. Seed/pre-seed is fine, Series A often gets bill shock.

- **Domain coupling** — you depend on Clerk-hosted pages (`accounts.your-app.com`). 100% your domain requires Business or above.

- **Data portability** — Clerk holds the user data. Migration is possible but you can't take password hashes.

5. Stytch — Passwordless-First, Separated B2C/B2B

**Stytch** (founded 2020, Series B) was the earliest to focus hard on passwordless.

- Magic links, email OTP, SMS OTP, WhatsApp OTP, passkeys, OAuth, TOTP.

- Separate **B2C SDK** and **B2B SDK** — B2B has organizations, SSO, SCIM, member management built in.

- Headless SDKs are a key strength — you build your UI, backend talks to Stytch.

B2B SaaS strengths

Stytch B2B is designed around the **organization** unit.

- SSO (SAML/OIDC) per organization.

- MFA policy per organization (required/optional).

- Roles and permissions per organization (Owner, Admin, Member, plus Stytch Resource-based RBAC).

- Domain-matched auto-join (e.g. `user@acme.com` emails auto-add to the Acme org).

const stytch = new StytchClient({

project_id: process.env.STYTCH_PROJECT_ID!,

secret: process.env.STYTCH_SECRET!,

})

// Send a magic link

await stytch.magicLinks.email.loginOrCreate({

email: 'user@acme.com',

login_magic_link_url: 'https://app.example.com/auth/callback',

})

Pricing

- Stytch Consumer Free: up to 10,000 MAU.

- Pro: $0.05/MAU plus per-feature.

- Stytch B2B: per-organization, typically $99/org/month + features.

6. WorkOS — Specialized in Enterprise SSO/SCIM

**WorkOS** positions itself as "the box that unblocks B2B SaaS moving upmarket — SSO, SCIM, and audit logs."

- **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** (customers connect their IdP directly).

- AuthKit — free hosted login page (similar to Clerk).

Pricing model

WorkOS prices differently from the rest.

- **SSO**: $99 per connection per month. Volume discount past the 10th connection.

- **SCIM (Directory Sync)**: $0.125 per user per month.

- **Audit Logs**: $0.05 per event.

- **AuthKit**: free up to 1M MAU.

A single B2B (enterprise) customer with SSO is $99/month revenue equivalent. This pricing maps to SaaS economics where one enterprise customer = average LTV of tens of thousands of dollars.

Sample code — SSO flow

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

// 1) Generate login URL

const authUrl = workos.sso.getAuthorizationUrl({

connection: 'conn_01EHWNCE74X7JSDV0X3SZ3KJNY',

redirectUri: 'https://app.example.com/callback',

clientId: process.env.WORKOS_CLIENT_ID!,

})

// 2) Get profile from callback

const { profile, accessToken } = await workos.sso.getProfileAndToken({

code: searchParams.code,

clientId: process.env.WORKOS_CLIENT_ID!,

})

7. Kinde — Full-Stack Managed, "Cheaper and Simpler Than Auth0"

**Kinde** (founded 2022 in Australia) aimed to "remove Auth0's complexity and price." The result is the following in one box.

- B2C user auth + B2B organizations (tenants).

- Feature flags (includes its own flag system).

- Billing (Stripe integration), permissions, roles.

- Hosted login page or your own UI.

Pricing

- Free: up to 10,500 MAU.

- Plus: from $25/month + MAU.

- Scale and Enterprise are quote-based.

Notable: **the Free plan is the most generous**. 10k MAU free is the most lenient in 2026.

8. SuperTokens — OSS SaaS, Self-Host Option

**SuperTokens** (founded 2020, YC W21) has a dual model: open source + managed.

- All code is open source. Apache 2.0.

- Core service (SuperTokens Core) + backend SDK + frontend SDK separated.

- Host on the SaaS or your own infra (Docker, Kubernetes).

- Passwordless, passkeys, OAuth, sessions, MFA, multi-tenant.

Pricing

- Self-hosted: $0 on your infra.

- Managed Core: up to 5,000 MAU free, then $0.02/MAU.

Sample code

SuperTokens.init({

framework: 'express',

supertokens: {

connectionURI: 'http://localhost:3567', // or managed core URL

appInfo: {

appName: 'My App',

apiDomain: 'https://api.example.com',

websiteDomain: 'https://example.com',

recipeList: [

ThirdPartyEmailPassword.init({ /* providers */ }),

Session.init(),

})

SuperTokens in one line: "When you want OSS loyalty but optional managed hosting."

9. Frontegg — Managed B2B Customer Auth

**Frontegg** (founded 2019 in Israel) positions itself as a full-stack solution to B2B SaaS customer auth.

- Organizations (tenants), users, roles, permissions, SSO, SCIM, audit logs, notifications.

- Hosted login box + admin portal.

- Quote-based pricing — typically expensive for seed/Series A.

It overlaps with WorkOS in positioning, but differs.

- **WorkOS**: the SSO/SCIM infrastructure layer for B2B. You combine it with your own auth system.

- **Frontegg**: the full B2B auth box. You rarely build your own auth system.

10. Hanko — Passkey-First OSS

**Hanko** is a Germany-based OSS project with the slogan "Kill the password." Centered on passkeys, WebAuthn, passcodes (OTP).

- Go backend service + JS web components.

- Managed Hanko Cloud option + self-host.

- The `<hanko-auth />` web component is the core — works in any framework.

For "just ship passkeys fast," Hanko is the simplest. The catch: thinner OAuth social login coverage than other libraries.

11. Passport.js / iron-session / jose — Node Legacy + Minimal

Three classics.

- **Passport.js** (Jared Hanson, 2011 onward) — the Node Express era standard. 500+ strategies. Not under active maintenance as of 2026 but still widely used. Useful when you want to bolt together modular OAuth/OIDC.

- **iron-session** (Vercel/community) — encrypted cookie sessions. No separate DB, "everything in the cookie." Light enough for Next.js Edge.

- **jose** (Filip Skokan) — JWT/JWS/JWE/JWK standards library. The de facto choice when you mint and verify JWTs by hand.

// Mint and verify a JWT with 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)

These three are the "internal components" of the bigger SaaS/library packages. Fewer teams build from scratch with them, but **API gateways** and **microservice auth** still reach for them first.

12. OAuth Flows — Authorization Code with PKCE Is the Answer

In 2026, OAuth flows have settled.

┌─────────────────────────────────────────────────────────────────┐

│ 2026 OAuth Flow Recommendations │

│ │

│ Authorization Code + PKCE -> Web, mobile, SPA (standard) │

│ Client Credentials -> Server-to-server (M2M) │

│ Device Authorization -> TV/CLI/IoT │

│ Refresh Token Rotation -> Combine with all flows │

│ Resource Owner Password -> Forbidden (legacy only) │

│ Implicit Flow -> Deprecated, replaced by PKCE│

└─────────────────────────────────────────────────────────────────┘

OAuth 2.1 (draft, with the RFC process advancing in 2024 to 2025) formally removes Implicit and ROPC. Never use them in new code.

PKCE — Mandatory for SPA and Mobile

PKCE (Proof Key for Code Exchange, RFC 7636) solves the problem that SPAs and mobile apps cannot keep a client_secret.

1. The client generates a `code_verifier` (random string).

2. The SHA256 hash is sent to the IdP as `code_challenge`.

3. The IdP issues an `authorization_code`.

4. On token exchange the client sends the original `code_verifier`.

5. The IdP compares the hash and then issues the access token.

This way, **a man in the middle who steals the authorization_code** cannot exchange it for a token. By 2026 every modern IdP/library enables this by default.

13. Passkeys / WebAuthn — The Effective Standard in 2026

By 2026, passkey adoption is past the tipping point.

- Apple, Google, and Microsoft OSes all support passkeys as first-class citizens.

- 1Password, Bitwarden, and Dashlane sync passkeys across devices.

- Major sites (GitHub, Google, Amazon, Microsoft, eBay, PayPal, X, Best Buy, etc.) enable passkey login.

- FIDO Alliance statistics show passkey auth attempts are about 4x faster than passwords on average.

Passkey mechanics in brief

1. On registration the device generates a **public/private key pair**. The private key never leaves the device (Secure Enclave/TPM).

2. The server stores only the public key.

3. On login the server issues a challenge (random nonce). The device signs with the private key. The server verifies with the public key.

4. iCloud Keychain / Google Password Manager sync the keys across devices.

Passkey support by library/SaaS (2026Q1)

| Solution | Passkey Support | Notes |

| --- | --- | --- |

| Clerk | First-class | Smoothest UI/UX |

| Stytch | First-class | Headless SDK |

| Hanko | First-class (first-mover) | Passkey-centric design |

| better-auth | Plugin | Enable in 1 to 2 lines |

| SuperTokens | First-class | Most freedom when self-hosted |

| Auth.js v5 | Beta adapter | Some limitations |

| WorkOS AuthKit | First-class | Enterprise-friendly |

SimpleWebAuthn — For Hand-rolled Implementations

If you handle WebAuthn directly, [SimpleWebAuthn](https://github.com/MasterKale/SimpleWebAuthn) is the de facto library in 2026. It provides both backend (`@simplewebauthn/server`) and browser (`@simplewebauthn/browser`) packages.

14. Magic Links / OTP / TOTP — The Three Pillars of Passwordless

**Magic links**, **OTP (SMS/email)**, and **TOTP (authenticator apps)** are password alternatives and second-factor options for MFA.

| --- | --- | --- | --- | --- |

Magic link implementation essentials

Magic links must be **single-use, short expiry, and IP/device-bound**.

// Issue a magic link token

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, // never store the raw token

expiresAt: new Date(Date.now() + 15 * 60 * 1000), // 15 minutes

ip: request.ip,

})

const url = `https://example.com/auth/verify?token=${token}`

await sendEmail({ to: user.email, magicLinkUrl: url })

Twilio Verify — The De Facto SMS OTP

Do not roll SMS OTP from scratch. Use a managed product like [Twilio Verify](https://www.twilio.com/docs/verify), [Vonage](https://www.vonage.com/communications-apis/verify/), or [AWS SNS](https://aws.amazon.com/sns/). Why:

- Country-specific SMS deliverability, carrier blocks, AUP complexity.

- Carrier lookup, voice OTP fallback.

- Defending against SMS bombing attacks (infinite OTP requests on a signup form).

In 2026, SMS itself costs $0.01 to $0.10 per message. **Traffic pumping** attacks have caused multi-thousand-dollar monthly losses. Always combine OTP with rate limiting and reCAPTCHA/Turnstile.

15. Sessions vs JWT — The Right 2026 Answer

The eternal debate. The 2026 answer is clear: **sessions > JWT, but use short-lived JWT as your access token**.

Comparison

| Dimension | Server sessions (DB/Redis) | JWT (stateless) |

| --- | --- | --- |

| Immediate revoke | Yes (delete a row) | No (valid until expiry) |

| Verify cost | DB/Redis round-trip | Just signature verification |

| Scaling | Needs Redis cluster | Infinite (assumes secret stays safe) |

| Data exposure | Cookie only (opaque) | Payload base64 visible |

| Recovery | Can rotate keys | Re-login after key rotation |

| Recommended use | User sessions | M2M, short-lived access tokens |

Recommended 2026 pattern — Hybrid

┌─────────────────────────────────────────────────────────┐

│ Recommended Hybrid Flow │

│ │

│ 1) After login the server issues: │

│ - access_token (JWT, 5 to 15 min, perms in payload) │

│ - refresh_token (opaque, in DB, 7 to 30 days) │

│ │

│ 2) API calls authenticate with the access_token │

│ - Signature verification only, no DB lookup │

│ │

│ 3) On access expiry, refresh to get a new one │

│ - Verify the refresh row in DB, mint new access │

│ - Refresh rotation — used tokens are invalidated │

│ │

│ 4) On immediate logout, delete the refresh row │

│ - Access stays valid until natural expiry │

│ - Want faster cutoff? Keep access very short │

└─────────────────────────────────────────────────────────┘

This pattern is OAuth 2.0's **refresh token rotation**. By 2026 it's the default in every modern IdP/library.

16. Token Storage — HttpOnly Cookies Are the Answer

Where to store tokens in the browser is a perennial debate.

| --- | --- | --- | --- | --- |

Recommended combination

- Session ID or refresh token in an **HttpOnly + Secure + SameSite=Lax cookie**.

- Access token in memory (re-mint via refresh on reload).

- Or everything in HttpOnly cookies (BFF pattern).

CSRF defense: SameSite=Lax/Strict + state token or double-submit cookie. SameSite alone is not a complete CSRF defense (same-site subdomain attacks, GET state changes, etc.).

17. OWASP A07 — Top 5 Authentication Failure Traps

OWASP Top 10 2021 lists A07: Identification and Authentication Failures. Still alive in 2026.

1) Missing brute-force protection

- Per-username/IP/device counters.

- Exponential backoff or CAPTCHA.

- Lockout for 15 minutes after 5 failures, 1 hour after 10, admin intervention beyond.

2) Account enumeration

- Login error messages must not differ between "no such user" and "wrong password" — always show "Email or password is incorrect."

- On signup, immediately revealing "already registered" is dangerous — notify via email instead.

3) Weak password policy

- NIST 800-63B says: **minimum length 8 to 12**, **never force rotation** (rotate on breach instead), **block common passwords** (HaveIBeenPwned list).

- Forcing complexity (special characters, etc.) helps little — length matters more.

4) Session fixation

- Always **regenerate the session ID** right after login.

- Also regenerate on privilege escalation (entering admin mode).

5) Insecure password storage

- Pick bcrypt (cost more than 12), Argon2id, or scrypt.

- Do not use MD5/SHA1/SHA256 alone. PBKDF2 needs at least 600,000 iterations.

- Salt with 16+ random bytes per user.

18. B2B Auth Requirements — SSO / SCIM / Audit / IP / MFA Enforcement

B2B SaaS chasing enterprise customers needs five things, almost mandatory.

1. **SSO (SAML 2.0 + OIDC)** — connect to Okta, Microsoft Entra, Google Workspace, etc.

2. **SCIM (System for Cross-domain Identity Management)** — provisioning/deprovisioning in the customer's IdP propagates automatically.

3. **Audit logs** — who did what when. SOC2, ISO 27001, HIPAA requirements.

4. **IP allowlist / denylist** — restrict login to certain IP ranges.

5. **MFA enforcement** — organization-level "MFA is required" policy.

"Enterprise auth tax"

The B2B SaaS industry has a joke: "Add enterprise SSO and the price goes up 10x." Why:

- It's hard to build (the SAML debugging nightmare).

- SaaS like WorkOS and Frontegg charge $99/month per SSO connection.

- So SaaS products lock SSO behind their own enterprise plans and charge $1,000+/month.

If you build it yourself, [boxyhq/saml-jackson](https://github.com/boxyhq/jackson) or SuperTokens multi-tenant mode are worth looking at.

19. Korean Authentication — NAVER · Kakao · PASS · KakaoTalk Certificate

Auth flows specific to the Korean market.

- **NAVER Login** — OAuth 2.0 standard. Built into Auth.js and better-auth.

- **Kakao Login** — OAuth 2.0. High share in 30s and 40s demographics.

- **KakaoTalk Wallet / Certificate** — mobile certification. Fintech and public sector.

- **PASS app** — unified identity verification from the three carriers (SKT, KT, LG U+).

- **Simple identity verification** — phone number + carrier auth.

- **i-PIN** — resident ID alternative. Effectively dead after 2024.

- **Joint certificate (formerly public certificate)** — banking. Being replaced by mobile OS-based PASS certificate.

Add NAVER to Auth.js

// auth.ts

export const { auth } = NextAuth({

providers: [

Naver({

clientId: process.env.NAVER_CLIENT_ID!,

clientSecret: process.env.NAVER_CLIENT_SECRET!,

}),

})

Kakao follows the same pattern. Both are nearly mandatory if Korean users are a primary target.

20. Japanese Authentication — LINE · Yahoo!Japan · Mercari · d ACCOUNT

Japan-market specifics.

- **LINE Login** — built on the LINE messenger. Nearly mandatory for Japan B2C.

- **Yahoo!Japan ID** — huge Yahoo!Japan user base.

- **Mercari ID** — Mercari ecosystem.

- **d ACCOUNT (NTT DOCOMO)** — carrier-unified.

- **au ID, SoftBank ID** — other carriers.

- **My Number Card** — public identity verification. eKYC.

Add LINE Login

Auth.js has a LINE provider. Services with heavy Japanese user share (especially e-commerce, food delivery, gaming) treat LINE as their primary option as standard.

21. Bot Defense — Turnstile · hCaptcha · reCAPTCHA Enterprise · Arkose

CAPTCHA in 2026 has evolved to be nearly invisible.

- **Cloudflare Turnstile** — free, invisible challenges. Bot detection by Cloudflare traffic signals. The 2026 trend leader.

- **hCaptcha** — free/paid, visual challenge alternative. Adopted by Cloudflare, Discord, and others.

- **Google reCAPTCHA Enterprise** — score-based (0 to 1), very precise. Paid.

- **Arkose Labs** — puzzle challenges. Drives up bot-farm operating cost.

Cloudflare Turnstile side by side

Server verification.

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,

}),

})

For new projects in 2026, start with Turnstile. It's free and the UX is the smoothest.

22. Bot Defense in the AI Era — Passive Signals + Behavioral Analysis

LLMs caused an explosion of automated attacks. 2026 bot defense combines:

- **Passive device fingerprinting** (canvas, WebGL, fonts, timezone).

- **Mouse / keystroke dynamics**.

- **Network signals** (IP reputation, ASN, VPN/proxy detection, residential vs data-center IP).

- **Session behavior analysis** (statistical anomalies across signup-to-action sequences).

**Castle**, **Sift**, **Stytch Fraud & Risk**, **Arkose Bot Manager**, and similar managed providers fill this space. Building it yourself is extremely hard.

23. Migration Scenarios — Clerk → Auth.js, Auth0 → Stytch

Moving from managed to library (or between managed providers) is common.

Clerk → Auth.js + Postgres

1. Export users (JSON) from the Clerk Admin Dashboard.

2. Create `users`, `accounts`, `sessions` tables in Postgres and import.

3. **Password hash migration is not possible** — Clerk does not hand over its hashes. Two options:

- Option A: send "Reset your password" emails to every user.

- Option B: drop password auth — only allow magic links and OAuth.

4. Re-map OAuth accounts via `providerAccountId` in the `accounts` table.

5. Invalidate active sessions — everyone re-logs in.

Auth0 → Stytch

Auth0 lets you export password hashes (bcrypt). Stytch accepts bcrypt hash import, so passwords migrate as-is.

See [Stytch Migration Docs](https://stytch.com/docs/api/password-migrate).

Key rotation and gradual migration

Large services use a **dual-issuance** window.

- Issue tokens from both Auth0 and Stytch for a while.

- Clients prefer the new token, fall back to the old one on failure.

- After a period, retire the old IdP.

24. Who Picks What

Decision tree.

START

│

├─ MVP / side project / MAU < 10,000?

│ YES -> Auth.js v5 or Clerk Free

│ (Next.js -> consider better-auth)

│

├─ Large B2C (MAU 100k+) and managed is OK?

│ YES -> Clerk or Stytch

│ (Run a pricing simulation first)

│

├─ B2B SaaS that needs enterprise SSO?

│ YES -> WorkOS (SSO/SCIM)

│ + your own auth (Auth.js / better-auth)

│ or Stytch B2B / Frontegg integration

│

├─ Data sovereignty / self-host required?

│ YES -> SuperTokens (self-hosted)

│ or Logto, Ory Network (separate post)

│

├─ Passkey-first, kill the password?

│ YES -> Hanko or Clerk

│

├─ Minimal / code visibility / fewest deps?

│ YES -> iron-session + jose assembled by hand

│

└─ Heavy Korean / Japanese user share?

YES -> Pick one above + add NAVER/Kakao (KR)

or LINE/Yahoo!JP (JP) provider manually

Epilogue — The Next Decision Point for 2026 Auth

Three big takeaways.

1. **Passkeys are no longer optional.** A new 2026 project shipping without passkeys starts in security debt. Whether you choose Clerk, Stytch, Hanko, or better-auth, turn passkeys on.

2. **Simulate MAU pricing.** Clerk/Stytch/Auth0's $25 to $99/month is the starting point. Model the bill at 100k MAU and plan migration around 50k MAU. That's the safe move.

3. **Look at SSO layers like WorkOS early when going B2B.** When an enterprise customer asks for SSO, building from scratch eats 2 to 4 weeks in SAML debugging. Pre-paving is cheaper.

> "Choosing an auth library/SaaS decides 6 months of fast shipping and 5 years of operating cost at the same time. Look beyond the fast start to the migration cost."

Among managed options, data portability (especially password hash export) decides your 5-year freedom. Treat auth as an infrastructure decision — as heavy as your database choice.

References

- [Auth.js v5 Documentation](https://authjs.dev/)

- [NextAuth.js → Auth.js Migration Guide](https://authjs.dev/getting-started/migrating-to-v5)

- [Lucia auth — github lucia-auth/lucia (maintenance mode)](https://github.com/lucia-auth/lucia)

- [better-auth — Documentation](https://www.better-auth.com/)

- [better-auth GitHub — bekacru/better-auth](https://github.com/bekacru/better-auth)

- [Clerk Documentation](https://clerk.com/docs)

- [Clerk Pricing](https://clerk.com/pricing)

- [Stytch Documentation](https://stytch.com/docs)

- [Stytch B2B Authentication](https://stytch.com/b2b)

- [WorkOS Documentation](https://workos.com/docs)

- [WorkOS Pricing](https://workos.com/pricing)

- [Kinde Documentation](https://kinde.com/docs/)

- [SuperTokens GitHub — supertokens/supertokens-core](https://github.com/supertokens/supertokens-core)

- [Frontegg Documentation](https://docs.frontegg.com/docs)

- [Hanko — Passkey-first OSS](https://www.hanko.io/)

- [Logto — github logto-io/logto](https://github.com/logto-io/logto)

- [Ory Network — Kratos / Hydra / Keto](https://www.ory.sh/)

- [Keycloak](https://www.keycloak.org/)

- [SimpleWebAuthn — MasterKale/SimpleWebAuthn](https://github.com/MasterKale/SimpleWebAuthn)

- [Passport.js](https://www.passportjs.org/)

- [iron-session — vvo/iron-session](https://github.com/vvo/iron-session)

- [jose — panva/jose JWT library](https://github.com/panva/jose)

- [boxyhq/jackson — SAML Jackson](https://github.com/boxyhq/jackson)

- [OAuth 2.1 Draft RFC](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/)

- [RFC 7636 — PKCE](https://datatracker.ietf.org/doc/html/rfc7636)

- [OWASP Top 10 2021 — A07 Identification and Authentication Failures](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/)

- [NIST SP 800-63B Digital Identity Guidelines](https://pages.nist.gov/800-63-3/sp800-63b.html)

- [FIDO Alliance — Passkeys](https://fidoalliance.org/passkeys/)

- [Have I Been Pwned — Pwned Passwords](https://haveibeenpwned.com/Passwords)

- [Cloudflare Turnstile](https://www.cloudflare.com/products/turnstile/)

- [hCaptcha](https://www.hcaptcha.com/)

- [Twilio Verify API](https://www.twilio.com/docs/verify)

- [NAVER Login Developers](https://developers.naver.com/products/login/api/api.md)

- [Kakao Login Developers](https://developers.kakao.com/docs/latest/ko/kakaologin/common)

- [LINE Login Developers](https://developers.line.biz/en/docs/line-login/overview/)

- [Yahoo! JAPAN Developer Network — Yahoo ID連携](https://developer.yahoo.co.jp/yconnect/)