Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

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

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

  • 미국 정부 로그인 포털 Login.gov가 패스키를 1차 인증 옵션으로 추가했다.
  • Apple Passwords 앱이 iOS 18 / macOS Sequoia에서 1급 시민 자격으로 분리됐다. iCloud 키체인의 후속이지만 UX가 완전히 다르다.
  • Android 15 Credential Manager가 패스키와 패스워드를 단일 API로 통합했다.
  • 1Password / Bitwarden / Dashlane이 크로스 플랫폼 패스키 동기화를 정식 지원한다.
  • WebAuthn Level 3가 2024년 9월에 W3C 권고가 됐다. Conditional UI(자동완성처럼 보이는 패스키 선택)가 표준의 일부다.
  • Hybrid transport(caBLE → CTAP 2.2) 로 데스크톱에서 폰을 인증기로 쓰는 시나리오가 안정화됐다.

이 글은 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·금융인증서 진영이 여전히 강하지만 일부 빅테크가 움직였다.

남은 과제도 있다.

  • 계정 복구: 모든 디바이스를 잃었을 때 어떻게 복구하나. 아직 표준이 없고 사업자마다 다르다.
  • 사용자 교육: "패스키가 뭔지" 설명하는 비용이 여전히 크다.
  • 레거시 호환: 비밀번호 관리자·SMS OTP·2FA 앱이 동시에 존재해서 사용자 혼란이 있다.
  • B2B / SCIM: 엔터프라이즈에서 패스키 정책을 IdP 레벨에서 관리하는 시나리오는 이제 막 시작이다.

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

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

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

  • FIDO2 = WebAuthn(W3C) + CTAP(FIDO Alliance) 두 표준의 묶음 이름.
  • WebAuthn = 브라우저와 서버 사이의 JavaScript API. navigator.credentials.create() / .get().
  • CTAP = 브라우저와 외부 인증기(Authenticator) 사이의 와이어 프로토콜. CTAP 1(U2F), CTAP 2.0, 2.1, 2.2.
  • Passkey = WebAuthn credential 중 "동기화되고 발견 가능한(Discoverable)" 것의 마케팅 이름. 기술적으로는 resident key + multi-device.

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

[사용자 브라우저/앱]
   |  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 안에 묻혀 있었는데, 이걸 독립 앱으로 떼어내면서 사용자에게 명확히 "암호 관리자"로 보이게 만들었다.

핵심 변화.

  • 독립 앱: Spotlight·Dock·홈 화면에서 직접 접근. macOS·iOS·iPadOS·visionOS·Windows(iCloud for Windows) 동기화.
  • 카테고리 분리: Passwords / Passkeys / Wi-Fi / Verification Codes(TOTP) / Security 추천. 패스키가 독립 카테고리.
  • 공유 그룹: 가족·팀과 패스키를 공유. 비밀번호 공유의 후속.
  • Verification Codes 통합: 기존 6자리 OTP도 같은 앱이 채워준다. 별도 Authenticator 앱이 약화.
  • Security 추천: 약한 비밀번호·재사용·유출 데이터셋 매칭 알림.

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

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

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

  • Associated Domains: 네이티브 iOS 앱이 패스키를 쓰려면 apple-app-site-association 파일에 webcredentials 도메인을 등록해야 한다.
  • AutoFill 통합: ASAuthorizationPlatformPublicKeyCredentialProvider로 폼 자동완성. SwiftUI에선 .textContentType(.username) + .authorizationController().
  • Same Sign-in Account: 같은 Apple ID로 로그인한 모든 기기에 패스키가 자동 동기화. iCloud Keychain의 E2EE 모델 그대로.
  • 공유 그룹: iOS 18부터 ASCredentialIdentityStore가 그룹 공유 패스키를 노출.

주의할 점은 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)

장점은 명확하다.

  • 단일 진입점: 사용자가 "패스키냐 비밀번호냐"를 모르고도 로그인이 된다.
  • 써드파티 제공자: 1Password·Bitwarden·Dashlane이 OS 레벨로 같은 다이얼로그에 노출된다.
  • Digital Asset Links: 웹 도메인과 앱을 묶는 표준. assetlinks.json에 delegate_permission/common.get_login_creds를 선언하면 같은 패스키를 앱·웹 양쪽에서 쓴다.

WebAuthn 표준과의 차이점.

  • Android의 requestJson은 WebAuthn JSON-encoding 표준(W3C PublicKeyCredential.toJSON())을 그대로 따른다. 즉 서버는 WebAuthn 라이브러리를 그대로 쓰면 된다.
  • mediation: 'conditional' 에 해당하는 것이 preferImmediatelyAvailableCredentials = true다.

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

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

1Password.

  • 2023년 6월에 패스키 생성·저장 지원, 2024년부터 sync 안정.
  • Windows·macOS·Linux·iOS·Android·웹 브라우저 확장. Linux에서 Apple Keychain 패스키를 못 쓰는 사용자에게 가장 매력적.
  • 2024년에 Passage(passage.id)를 인수했다. 자기네 인증 SaaS로 끌어들이는 전략.
  • Watchtower로 패스키 보유 사이트 추천.

Bitwarden.

  • 오픈소스(OSS). self-hosting 가능(vaultwarden은 비공식이지만 인기).
  • 2023년 11월에 브라우저 확장에서 패스키 저장 시작. 2024년에 모바일로 확장.
  • 무료 플랜도 패스키 기능을 제한 없이 쓸 수 있다는 점이 강점.

Dashlane.

  • 2022년 9월에 가장 먼저 컨슈머 패스키 발표. 마케팅 측면에선 선두였다.
  • 2024년부터 엔터프라이즈 라인업 강화. SCIM 통합·SSO 라우팅.
  • Confidential SSO(클라이언트 사이드 E2EE)로 차별화.

세 곳의 공통점은 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,
})
  • 사용자가 로그인 폼의 username 인풋(autocomplete="username webauthn")에 포커스하면 자동완성처럼 패스키 후보가 뜬다.
  • 사용자가 별도 "패스키로 로그인" 버튼을 누를 필요가 없다.
  • iOS Safari·Chrome·Edge·Firefox 모두 지원.

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 서버로 전송 → 로그인 성공

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

  • BLE proximity: 클라우드를 통한 릴레이만 있으면 안 되니까, BLE로 "물리적으로 가까이 있는지" 확인한다.
  • End-to-end encryption: QR 코드에 임시 ECDH 공개키가 들어 있고, 폰과 PC가 그 키로 직접 E2EE 채널을 만든다. Apple/Google 클라우드는 암호화된 trafffic만 봄.
  • One-shot: 한 번 쓰면 끝. 영구 페어링이 아니다.

이게 왜 좋은가.

  • Windows PC에서도 iPhone 패스키를 쓸 수 있다.
  • Mac에서 Android phone의 패스키를 쓸 수 있다.
  • 다른 사람의 PC(예: 인터넷 카페)에서도 안전.

단점.

  • BLE를 켜야 한다. 회사 보안 정책상 BLE를 막은 노트북에서는 안 됨.
  • 한 번에 30-60초 정도 걸린다. Conditional UI보다 느리다.

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

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

Auth0 (현재 Okta 자회사).

  • Database connections에 "Passkey"를 토글하면 패스키 로그인 가능. Universal Login에 통합.
  • "Progressive profiling" 워크플로우와 결합 가능. 첫 가입은 패스키로, 나중에 추가 정보 수집.
  • 가격: B2C는 MAU 기반, B2B는 시트 기반. 패스키 자체는 추가 과금 없음.

Okta Workforce Identity Cloud.

  • 직원용 IdP. SCIM·SAML·OIDC·MFA·정책 엔진.
  • 2024년에 Okta FastPass에 패스키 통합. 사용자 디바이스에 등록된 패스키를 IdP 레벨에서 정책으로 관리한다.
  • Yubikey · Windows Hello · Touch ID 동시 지원.

Microsoft Entra ID(구 Azure AD).

  • 같은 카테고리지만 Microsoft 생태계 묶음. Entra가 패스키를 지원하면서 Authenticator 앱과 통합.
  • 사내 Windows 디바이스에서 Hello for Business와 매끄럽게.

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

  • 어떤 attestation을 받을지 (예: FIPS 인증 키만)
  • 어떤 디바이스에 등록할 수 있는지
  • 분실 시 어떻게 재발급할지

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

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

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

Clerk.

  • 2020년 창업. Next.js와 React 생태계에 최적화. <SignIn />, <UserButton /> 같은 컴포넌트가 즉시 작동.
  • 패스키는 2024년부터 정식 지원. clerkClient.users.createPasskey() API와 자동 UI.
  • 다중 세션·organizations·invitations 같은 SaaS 패턴이 즉시 작동.
  • 가격: MAU 기반. 무료 10K MAU.
// Clerk — Next.js 예제 (개념)
import { SignIn } from '@clerk/nextjs'

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

Stytch.

  • 2020년 창업. Plaid 출신 창업자. API-first 강조.
  • B2C는 Frontend SDK + Backend SDK 조합. B2B(Stytch B2B)는 SCIM·SSO 라우팅 별도.
  • 패스키는 2023년부터 정식. M2M 토큰까지 포함하는 풀스택.
  • "Passwordless" 시나리오(Magic Link + Passkey)에 집중.

Passage (1Password 인수).

  • 2022년 창업. 패스키 전용 SaaS로 출발.
  • 2024년 1월에 1Password가 인수. 이후 패스키 + 1Password vault 통합 시나리오로 방향 전환.
  • 무료 플랜 관대(10K MAU 무료).
  • React/JavaScript/Next.js SDK 잘 갖춤.

세 곳의 공통점.

  • Conditional UI 자동 활성화: 사용자가 username을 입력하는 칸을 만들면 자동완성이 작동.
  • 계정 복구 흐름: 패스키 분실 시 매직 링크·OTP로 폴백.
  • Drop-in UI vs Headless: 두 가지 모드 다 지원. 디자인을 통제하고 싶으면 Headless.

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

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

SuperTokens.

  • 2020년 창업. Y Combinator. MIT 라이선스.
  • 코어 서비스 + Node/Python/Go backend SDK + React/플레인 JS frontend SDK.
  • "recipe" 개념: passwordless·password·third-party·MFA를 조합.
  • 패스키는 2024년부터 정식. self-host 가능.
  • 가격: OSS는 무료. Managed(SuperTokens Cloud)는 MAU 기반.
// SuperTokens — passkey recipe (개념)
import Passkey from 'supertokens-node/recipe/passkey'

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

Logto.

  • 2022년 창업. 중국·아시아 시장에서 강함. Apache 2.0.
  • Customer Identity(CIAM)에 특화. 다국어·SSO·소셜 로그인.
  • self-host와 Logto Cloud 둘 다 제공.
  • 패스키는 2024년에 정식 지원. WebAuthn Level 3 호환.

Hanko.

  • 2022년 창업. 독일 회사. EU 데이터 주권 메시지 강조.
  • AGPL + 상용 듀얼 라이선스. Hanko Cloud.
  • "Passkey-first"가 슬로건. 패스키를 default로, 비밀번호를 폴백으로 미는 정책 강제.
  • Drop-in UI("hanko-elements")가 깔끔.
<!-- Hanko — drop-in 컴포넌트 (개념) -->
<hanko-auth></hanko-auth>
<script type="module">
  import { register } from '@teamhanko/hanko-elements'
  register({ shadow: true })
</script>

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

  • self-host 가능: 데이터를 자기 인프라에 둘 수 있다.
  • lock-in 회피: 가격 정책 변경 위험이 적다.
  • 감사 가능: 코드 자체를 읽고 검증 가능.

단점.

  • 운영 부담: DB·세션 스토리지·키 로테이션을 직접 관리.
  • UX 폴리시 격차: SaaS만큼 매끄럽지 않을 수 있다.
  • 컴플라이언스 인증: SOC 2·ISO 27001을 자기 인프라에 적용해야 한다.

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

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

네이버.

  • 2024년 10월에 "네이버 패스키" 베타. 네이버 앱에서 발급, 웹에서 로그인.
  • 2025년 일부 사용자에게 기본 옵션으로 노출.
  • 네이버 시리즈(웨일·웍스·네이버 페이) 진입에 쓰임.

카카오.

  • 카카오톡 인증과 카카오 계정 인증을 합치는 작업. 패스키는 2025년 초에 베타.
  • 보안 강도가 높은 일부 서비스(카카오뱅크·페이)는 여전히 PIN + 생체.
  • 카카오 i 클라우드 사용자에 한해 패스키 동기화.

토스.

  • 토스 인증서로 자체 인증 생태계를 만들어 두고 있어 패스키 도입에 신중.
  • 2025년 말부터 패스키를 PoC. 정식 도입은 2026년 하반기 예상.
  • 토스 페이먼츠에서 가맹점 사장님 대시보드용 패스키가 먼저 들어옴.

공공·금융.

  • PASS(통신 3사) 는 자체 생태계 유지 중. 패스키 직접 도입보다 PASS 안에서 FIDO를 쓰는 방향.
  • 금융인증서(2020 사설인증 도입) 는 금융결제원 인프라. 패스키와는 다른 기술 스택이지만 사용자 경험은 유사.
  • 모바일 신분증(2024) 은 DID 기반. 패스키와는 다른 표준이지만 같은 "공유키" 흐름을 가진다.

시사점.

  • 한국은 인증 시장이 파편화돼 있고, 패스키가 자리잡으려면 시간이 더 걸린다.
  • B2C 서비스는 패스키를 "한국 사용자를 위한 옵션" 정도로 도입하는 게 현실적이다.
  • B2B SaaS는 한국 진출 시 SAML/OIDC + 패스키를 모두 노출하는 게 안전하다.

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

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

docomo ID.

  • 2024년에 패스키 베타. dアカウント의 일부로 통합.
  • d払い·dカード 같은 결제 인증으로 확장 중.

au ID (KDDI).

  • 2024년 후반에 패스키 정식. au PAY 결제에서 쓰임.

SoftBank ID / Y!mobile.

  • LINE 야후가 인수한 후, Yahoo!Japan ID와의 통합을 진행. 패스키는 그 통합 과정의 한 축.

Yahoo!Japan.

  • 2022년부터 패스키 시범 도입한 일본 최대 사례. 가장 일찍 시작.
  • 2024년 기준 수천만 사용자가 패스키 보유.
  • 운영 사례가 가장 풍부해서 일본 내에서 reference로 인용된다.

LINE.

  • 2023년부터 LINE 로그인에 패스키. 일본·태국·대만에서 빠르게 전개.
  • LINE Pay 결제 인증에 적용.

마이넘버 카드.

  • 일본 정부의 디지털 ID. 본래 마이나포털에서 카드+PIN 인증.
  • 2025년부터 마이넘버 카드의 인증서를 패스키 형식으로 노출하는 실증.

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

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

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

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

  • 로그인 후 "보안 설정"에서 "패스키 등록"을 노출.
  • 기존 비밀번호 사용자가 추가 인증 수단으로 패스키를 등록.
  • 한 사용자당 여러 개의 패스키 등록 가능(데스크톱·폰·iPad).

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

  • username 인풋에 autocomplete="username webauthn".
  • 페이지 로드 시 navigator.credentials.get({ mediation: 'conditional' }).
  • 비밀번호 사용자는 영향 없음. 패스키 사용자만 자동완성처럼 후보가 뜸.

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

  • 신규 사용자에게 "비밀번호 대신 패스키" 옵션을 default로 제시.
  • 사용자가 명시적으로 거부해야 비밀번호.
  • 폴백으로 이메일 매직 링크.

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

  • 로그인할 때 "패스키로 다음에 더 빠르게 로그인하시겠어요?"
  • A/B 테스트해서 conversion 모니터링. (보통 20-40% 전환.)
  • 부드럽게 권유하되 강제하지 않음.

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

  • 사용자가 옵션으로 "비밀번호 비활성화"를 선택 가능하게.
  • 정부·금융권 컴플라이언스가 허락하는 한도 내에서.

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

  • 모든 디바이스를 잃어도 계정에 들어갈 길이 있어야 한다.
  • 이메일 매직 링크·SMS OTP·복구 코드(recovery codes)·신원 확인.
  • "패스키 = 더 안전" 이지만 "패스키 = 복구 불가능" 이면 채택 실패.

메트릭.

  • 패스키 등록률(가입한 사용자 중 패스키 등록한 비율)
  • 패스키 로그인 비율(로그인 중 패스키 사용한 비율)
  • 패스키 인증 성공률(시도 대비 성공)
  • 패스키 폴백률(실패해서 비밀번호로 폴백한 비율)

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

14장 · 참고 / References

표준 / 사양.

OS / 플랫폼.

라이브러리.

SaaS / 오픈소스 인증.

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

한국 / 일본 사례.

정부 / 컴플라이언스.

Discuss on Twitter • View on GitHub