프롤로그 — 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 / UV | User Present / User Verified 비트 |
| signCount | counter가 단조 증가하는지(복제 탐지) |
| 서명 검증 | 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 예제 (개념)
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 (개념)
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 컴포넌트 (개념) -->
register({ shadow: true })
오픈소스 진영의 공통 강점.
- **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
**표준 / 사양.**
- W3C WebAuthn Level 3 — https://www.w3.org/TR/webauthn-3/
- W3C WebAuthn Level 2 — https://www.w3.org/TR/webauthn-2/
- FIDO Alliance CTAP 2.2 — https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html
- FIDO Alliance Passkeys — https://fidoalliance.org/passkeys/
- IANA COSE Algorithms — https://www.iana.org/assignments/cose/cose.xhtml
**OS / 플랫폼.**
- Apple Passwords 앱 — https://www.apple.com/legal/privacy/data/en/passwords/
- Apple Developer "Supporting passkeys" — https://developer.apple.com/documentation/authenticationservices/public-private-key-authentication
- Android Credential Manager — https://developer.android.com/identity/sign-in/credential-manager
- Windows Hello WebAuthn — https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/passwordless-strategy
**라이브러리.**
- SimpleWebAuthn — https://simplewebauthn.dev/
- @simplewebauthn/server — https://github.com/MasterKale/SimpleWebAuthn
- py-webauthn — https://github.com/duo-labs/py_webauthn
- webauthn-rs — https://github.com/kanidm/webauthn-rs
**SaaS / 오픈소스 인증.**
- Auth0 Passkeys — https://auth0.com/docs/authenticate/database-connections/passkeys
- Okta FastPass — https://www.okta.com/products/fastpass/
- Clerk — https://clerk.com/docs/authentication/configuration/passkeys
- Stytch — https://stytch.com/docs/passkeys
- SuperTokens — https://supertokens.com/
- Logto — https://logto.io/
- Hanko — https://www.hanko.io/
- Passage by 1Password — https://passage.id/
**비밀번호 관리자 패스키 sync.**
- 1Password Passkeys — https://blog.1password.com/passkeys/
- Bitwarden Passkeys — https://bitwarden.com/passwordless-passkeys/
- Dashlane Passkeys — https://www.dashlane.com/passkeys
**한국 / 일본 사례.**
- Yahoo!Japan WebAuthn 사례 (Internet Week) — https://yahoo-id.github.io/
- 네이버 패스키 — https://nid.naver.com/
- LINE Passkey — https://developers.line.biz/
- docomo dアカウント FIDO — https://www.docomo.ne.jp/
**정부 / 컴플라이언스.**
- Login.gov 패스키 — https://www.login.gov/help/
- NIST SP 800-63B — https://pages.nist.gov/800-63-3/sp800-63b.html
- FedRAMP 정책 가이드 — https://www.fedramp.gov/
현재 단락 (1/360)
2022년 5월에 Apple·Google·Microsoft가 "패스키를 도입한다"고 공동 발표했을 때, 대부분의 사람은 시큰둥했다. "또 그 소리? OAuth도 2.0이 나오고 1...