LabHub

블로그

패스키·WebAuthn 2026 — FIDO2·Auth0·Clerk·Stytch·Logto·SuperTokens·Hanko 심층 가이드

2026-05-15 · 31 분 읽기 · #passkey#webauthn#fido2#passwordless#auth0#clerk#stytch#logto#supertokens#hanko#passage#authentication#deep-dive

한국어English日本語

프롤로그 — 2026년, 비밀번호의 종말이 진짜 시작됐다

2022년 5월에 Apple·Google·Microsoft가 "패스키를 도입한다"고 공동 발표했을 때, 대부분의 사람은 시큰둥했다. "또 그 소리? OAuth도 2.0이 나오고 10년 걸렸는데" 같은 반응이 대다수였다. 그런데 2026년 5월 현재, 진짜로 바뀐 게 보인다.

이 글은 2026년 5월 기준으로 패스키와 WebAuthn 생태계의 지도를 그린다. 사용자 시점·개발자 시점·운영자 시점을 모두 다룬다. 표준 스택부터 시작해서, 플랫폼 UX(iOS·Android), 인증 SaaS(Auth0·Clerk·Stytch·SuperTokens·Logto·Hanko·Passage), 한국과 일본 사업자 현황, 그리고 기존 비밀번호 시스템에서 점진적으로 마이그레이션하는 전략까지 짚는다.

코드 예제는 의도적으로 @simplewebauthn/server 와 @simplewebauthn/browser 를 표준 reference로 쓴다. 이 라이브러리가 사실상 Node 진영의 표준이고, 다른 SaaS도 내부적으로 같은 모양의 API를 노출한다.

1장 · 2026년 패스워드의 종말 — 어디까지 왔나

2022년 발표 이후 4년 동안 무엇이 바뀌었을까. 가장 의미 있는 변화 다섯 개만 정리한다.

첫째, OS 레벨 일등 시민화. iOS 17까지 패스키는 iCloud 키체인의 하위 기능이었다. iOS 18에서 Passwords 앱이 분리되면서, 사용자에게 "패스키는 비밀번호보다 더 좋은 것"이라는 명확한 신호가 갔다. Android 15도 Credential Manager API로 동일한 통합을 했다.

둘째, 크로스 플랫폼 동기화. 패스키의 약점은 "한 생태계에 갇힌다"였다. 2024-2025년 사이에 1Password·Bitwarden·Dashlane이 모두 패스키 sync를 지원하면서 이 문제가 풀렸다. iCloud로 만든 패스키를 Windows에서 1Password로 쓸 수 있다.

셋째, Conditional UI. WebAuthn Level 3의 가장 중요한 기능. 로그인 폼의 사용자명 칸을 클릭하면 자동완성처럼 패스키 후보가 뜬다. 사용자가 별도 버튼을 누를 필요가 없다. 이 UX 덕분에 "패스키 = 익숙한 자동완성"으로 인식이 바뀐다.

넷째, Hybrid transport. 데스크톱 브라우저에서 폰의 패스키를 쓰는 시나리오. QR 코드를 띄우고, 폰으로 스캔하고, BLE로 가까이 있는지 확인한다. 이건 CTAP 2.2 명세에 정식 편입됐다.

다섯째, 정부·금융권 도입. Login.gov가 패스키를 받기 시작했고, 미국 SSA도 따라온다. 일본은 2025년에 마이넘버 카드와 패스키를 연동하는 실증을 시작했다. 한국은 PASS·금융인증서 진영이 여전히 강하지만 일부 빅테크가 움직였다.

남은 과제도 있다.

이 글의 후반부에서 이 과제들을 다시 다룬다.

2장 · WebAuthn / FIDO2 / CTAP — 표준 스택 정리

용어가 헷갈리기 쉽다. 한 줄로 정리하면.

이걸 그림처럼 보면 이렇다.

[사용자 브라우저/앱]
   |  WebAuthn JS API (navigator.credentials)
   v
[OS Credential Provider]  (iOS Passwords / Android Credential Manager / Windows Hello)
   |  CTAP 2.x (USB-HID, NFC, BLE/caBLE)
   v
[Authenticator]  (Secure Enclave / TPM / Titan / YubiKey / iPhone / Android phone)

WebAuthn API의 핵심은 두 함수다.

// 1) 등록(Registration) — 새 패스키 생성
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,            // 서버가 보낸 무작위 nonce
    rp: { id: 'example.com', name: 'Example' },
    user: {
      id: new Uint8Array(userIdBytes),     // 서버의 user.id (UTF-8 bytes)
      name: 'alice@example.com',
      displayName: 'Alice',
    },
    pubKeyCredParams: [
      { type: 'public-key', alg: -7 },     // ES256
      { type: 'public-key', alg: -257 },   // RS256
    ],
    authenticatorSelection: {
      residentKey: 'required',             // = passkey
      userVerification: 'preferred',
    },
    attestation: 'none',                   // 대부분의 컨슈머 서비스는 none
  }
})

// 2) 인증(Authentication) — 기존 패스키로 로그인
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,
    rpId: 'example.com',
    userVerification: 'preferred',
    // allowCredentials를 비우면 Discoverable credential 선택 UI
    allowCredentials: [],
  },
  mediation: 'conditional', // ← Conditional UI 활성화
})

서버 측에서 검증해야 하는 것은 다음과 같다.

검증 항목의미
challenge 일치서버가 보낸 challenge가 응답에 포함되는지
origin 일치clientDataJSON.origin이 RP의 origin인지
rpIdHash 일치authenticatorData의 rpIdHash가 RP의 SHA-256인지
flags.UP / UVUser Present / User Verified 비트
signCountcounter가 단조 증가하는지(복제 탐지)
서명 검증clientDataJSON과 authenticatorData를 합쳐 공개키로 검증

이걸 직접 구현하면 100% 망친다. 그래서 거의 모든 사람이 라이브러리를 쓴다. 다음 장에서 본다.

3장 · iOS 18 + macOS Sequoia Passwords 앱 — 애플의 한 수

2024년 9월의 iOS 18 발표에서 가장 조용했지만 가장 의미 있는 변화가 Passwords 앱이었다. iCloud 키체인은 원래 Settings 안에 묻혀 있었는데, 이걸 독립 앱으로 떼어내면서 사용자에게 명확히 "암호 관리자"로 보이게 만들었다.

핵심 변화.

사용자 흐름은 다음과 같다.

1. Safari에서 example.com 가입
2. 폼 채우다가 "Passwords"가 자동으로 제안
3. 사용자: Face ID 한 번
4. → 패스키 등록 완료, iCloud Keychain에 저장
5. 다른 기기(Mac/iPad)에서 곧장 동일 계정 로그인 가능

개발자 관점에서 알아야 할 점.

주의할 점은 attestation이 사실상 없다는 것. Apple Anonymous Attestation은 제공되지만 대부분의 컨슈머 서비스는 attestation: 'none'을 받아들이는 게 정상이다. 강한 attestation이 필요한 건 엔터프라이즈·정부·금융권뿐.

4장 · Android 15 Credential Manager — 패스키와 패스워드 통합

구글은 Android에서 인증 API가 너무 파편화된 걸 정리하려고 Credential Manager를 만들었다. Android 14에 베타로 나왔고, Android 15에서 정식. 핵심 아이디어는 "패스워드·패스키·페더레이션 로그인(Google Sign-In)을 하나의 API로".

// Android Credential Manager — 등록
val request = CreatePublicKeyCredentialRequest(
  requestJson = serverChallengeJson,
  preferImmediatelyAvailableCredentials = true,
)
val credential = CredentialManager.create(context)
  .createCredential(activity, request)

// 인증
val getRequest = GetCredentialRequest(
  credentialOptions = listOf(
    GetPublicKeyCredentialOption(serverRequestJson),
    GetPasswordOption(),  // 기존 비밀번호도 함께 노출
  ),
)
val response = CredentialManager.create(context)
  .getCredential(activity, getRequest)

장점은 명확하다.

WebAuthn 표준과의 차이점.

5장 · 1Password / Bitwarden / Dashlane — 크로스 플랫폼 패스키 동기화

OS 진영(Apple Keychain·Google Password Manager)의 동기화는 한 생태계 안에서만 작동한다. 그래서 써드파티 비밀번호 관리자의 역할이 커졌다. 2024-2025년 사이에 주요 세 곳이 모두 패스키 sync를 지원한다.

1Password.

Bitwarden.

Dashlane.

세 곳의 공통점은 WebAuthn Conditional UI를 정확히 구현한다는 것. 브라우저 확장이 OS의 credential provider와 경쟁하지 않고 사용자가 어느 쪽을 쓸지 선택하게 한다.

6장 · WebAuthn Level 3 (2024.9 W3C 권고) — Conditional UI / Auto-fill

WebAuthn Level 2가 2021년에 W3C 권고였고, Level 3가 2024년 9월에 최종 권고로 올라왔다. 주요 변화 다섯 개.

1. Conditional UI (Auto-fill).

// 페이지 로드 시점에 미리 호출. mediation: 'conditional'이 핵심.
const cred = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,
    rpId: 'example.com',
    allowCredentials: [],          // 비워야 Discoverable 후보 검색
  },
  mediation: 'conditional',
  signal: abortController.signal,
})

2. JSON-encoding. PublicKeyCredential.toJSON() 표준화. 서버가 ArrayBuffer를 직접 다루지 않고 JSON으로 받는다.

3. PRF extension. Pseudo-Random Function 익스텐션. 패스키로부터 결정론적 비밀(예: E2EE 키)을 유도할 수 있다. 1Password가 이걸로 vault 잠금 해제를 시도하는 PoC를 보였다.

4. largeBlob 확장의 안정화. 인증기에 작은 데이터(예: 사용자 정의 라벨)를 같이 저장.

5. attestation의 직접 형식. Apple/Google이 더 많은 attestation 형식을 표준에 합류시켰다.

7장 · Hybrid transport (caBLE → CTAP 2.2) — phone-as-authenticator

"노트북에서 웹사이트 로그인하는데 패스키는 폰에 있다"는 시나리오는 가장 흔한 트레이드오프 지점이었다. 2022년부터 caBLE(Cloud Assisted Bluetooth Low Energy) 라는 이름으로 실험됐고, 2024년에 CTAP 2.2 명세에 Hybrid transport 라는 공식 이름으로 들어갔다.

흐름.

1. PC 브라우저가 QR 코드를 표시
2. 사용자가 폰 카메라로 스캔
3. 폰이 클라우드로 핸드셰이크 (Apple/Google 푸시 인프라)
4. 폰과 PC가 가까이 있는지 BLE 신호로 확인
5. 폰에서 Face ID/Touch ID/지문
6. 폰이 서명을 만들어 클라우드 경유로 PC에 전달
7. PC가 그 서명을 RP 서버로 전송 → 로그인 성공

이 흐름의 보안 모델은 흥미롭다.

이게 왜 좋은가.

단점.

8장 · Auth0 / Okta — 엔터프라이즈 진영

큰 회사들이 패스키를 도입할 때 가장 먼저 떠올리는 게 Auth0/Okta다. 두 곳 다 패스키를 정식 지원한다.

Auth0 (현재 Okta 자회사).

Okta Workforce Identity Cloud.

Microsoft Entra ID(구 Azure AD).

이 진영의 공통 강점은 거버넌스. 패스키 정책을 사용자가 아니라 IT가 관리한다.

컨슈머 SaaS가 잘 안 다루는 부분이다.

9장 · Clerk / Stytch / Passage — 개발자 친화 SaaS

스타트업·개발자 진영에선 다른 류의 SaaS가 인기다.

Clerk.

// Clerk — Next.js 예제 (개념)
import { SignIn } from '@clerk/nextjs'

export default function Page() {
  return <SignIn signInUrl="/sign-in" />
  // 패스키·이메일·OAuth가 자동으로 노출된다
}

Stytch.

Passage (1Password 인수).

세 곳의 공통점.

10장 · Logto / SuperTokens / Hanko — 오픈소스 옵션

자체 호스팅(self-host)이 필요한 팀, GDPR/데이터 주권 이슈가 있는 팀, 가격을 통제하고 싶은 팀에겐 오픈소스 옵션이 있다.

SuperTokens.

// SuperTokens — passkey recipe (개념)
import Passkey from 'supertokens-node/recipe/passkey'

SuperTokens.init({
  recipeList: [
    Passkey.init({
      // RP 정보·challenge 생성·검증을 라이브러리가 담당
    }),
    Session.init(),
  ],
})

Logto.

Hanko.

<!-- Hanko — drop-in 컴포넌트 (개념) -->
<hanko-auth></hanko-auth>
<script type="module">
  import { register } from '@teamhanko/hanko-elements'
  register({ shadow: true })
</script>

오픈소스 진영의 공통 강점.

단점.

11장 · 한국 — 네이버 / 카카오 / 토스 패스키 도입

한국은 패스키 도입이 글로벌 평균보다 느린 편이다. 이유는 두 가지. 첫째, 금융인증서·공동인증서·PASS라는 자체 인증 생태계가 강하다. 둘째, 금융권의 ARS·OTP 의존이 깊다.

네이버.

카카오.

토스.

공공·금융.

시사점.

12장 · 일본 — docomo / au / SoftBank ID · Yahoo!Japan

일본은 한국보다 인증 표준화가 조금 더 진행돼 있다. 통신사 ID와 마이넘버, 그리고 LINE/Yahoo!의 전략이 맞물려 있다.

docomo ID.

au ID (KDDI).

SoftBank ID / Y!mobile.

Yahoo!Japan.

LINE.

마이넘버 카드.

일본의 특징은 통신사·플랫폼이 패스키 도입에 적극적이라는 것. 정부도 마이넘버 카드를 통해 호환을 잡아 가는 중.

13장 · 패스키 마이그레이션 전략 — 점진적 도입 방법

기존 비밀번호 시스템이 있는 서비스에 패스키를 어떻게 끼워 넣을까. 다섯 단계로 정리한다.

1단계: 패스키 등록을 옵션으로 추가.

2단계: 로그인 폼에 Conditional UI 추가.

3단계: 신규 가입에서 패스키를 default.

4단계: 기존 비밀번호 사용자에게 업셀.

5단계: 패스키 단독 옵션 등장.

계정 복구 시나리오 — 가장 중요한 부분.

메트릭.

이 네 가지를 보면서 점진적으로 비밀번호의 비중을 줄여 간다.

14장 · 참고 / References

표준 / 사양.

OS / 플랫폼.

라이브러리.

SaaS / 오픈소스 인증.

비밀번호 관리자 패스키 sync.

한국 / 일본 사례.

정부 / 컴플라이언스.

원문 보기: https://www.youngju.dev/blog/culture/2026-05-15-passkeys-webauthn-2026-fido2-clerk-stytch-logto-supertokens-hanko-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다