--- term: '비밀번호 없는 인증' seoTitle: '비밀번호 없는 인증이란? 패스키, 매직 링크, WebAuthn' headline: '비밀번호 없는 인증이란?' slug: passwordless-authentication category: auth-security shortDefinition: '비밀번호 없는 인증은 외워 둔 비밀 대신 디바이스에 보관된 키나 생체 인식으로 신원을 확인하는 로그인 방식입니다.' relatedTerms: - multi-factor-authentication-mfa - oauth-2-social-login - json-web-token-jwt - identity-access-management-iam contrastsWith: - multi-factor-authentication-mfa aboutTerms: - 'Passkeys' - 'WebAuthn' - 'Magic Links' faq: - question: '비밀번호 없는 인증을 쉽게 설명하면 무엇입니까?' answer: '비밀번호를 입력하지 않고 로그인하는 방식입니다. 가진 것(암호 키를 보관한 디바이스, 받은편지함, 보안 키)이나, 그것을 잠금 해제하는 생체 인식을 통한 본인의 특성으로 신원을 증명합니다. 핵심 속성은 누군가 훔치거나, 재사용하거나, 피싱할 공유 비밀 자체가 존재하지 않는다는 점입니다.' - question: '비밀번호 없는 인증은 비밀번호보다 안전합니까?' answer: '실제로 침해를 일으키는 공격, 즉 피싱, 크리덴셜 스터핑, 재사용, 무차별 대입에 대해서는 확실히 그렇습니다. 서버 측에서 훔치거나 사용자를 속여 빼낼 비밀이 없기 때문입니다. 그렇다고 뚫을 수 없는 것은 아닙니다. 코드는 가로챌 수 있고, 디바이스는 도난당할 수 있으며, 약한 복구 경로는 튼튼한 정문을 무력화합니다.' - question: '패스키란 무엇이며 어떻게 동작합니까?' answer: 'WebAuthn 위에 구축된 FIDO 자격 증명입니다. 등록 시 디바이스가 키 쌍을 만들고 공개 키만 사이트로 보냅니다. 로그인 시에는 로컬 생체 인식이나 PIN으로 잠금을 해제한 뒤 디바이스가 사이트의 챌린지에 서명합니다. 자격 증명은 진짜 도메인에 묶여 있으므로 유사 사이트가 받는 서명은 아무 가치가 없으며, 이것이 피싱 방지의 원천입니다.' - question: '동기화 패스키와 디바이스 종속 패스키의 차이는 무엇입니까?' answer: '동기화 패스키는 자격 증명 관리자를 통해 배포되는 종단 간 암호화된 사본입니다. 디바이스를 잃어도 살아남고 복구가 쉬운 대신, 동기화 계정을 신뢰해야 합니다. 디바이스 종속 키는 하드웨어를 결코 떠나지 않습니다. 보증 수준은 가장 높지만 복구용 사본이 없습니다. 현재 미국 연방 지침은 일반적인 보증 수준에서 동기화 패스키를 인정합니다.' - question: '매직 링크는 안전합니까?' answer: '대부분의 사용자에게는 비밀번호보다 안전하며, 링크가 도착하는 받은편지함과 정확히 같은 수준으로 안전합니다. 실제 인증 수단은 이메일이며, 그래서 NIST 지침은 이메일을 대역 외(out-of-band) 인증 수단으로 인정하지 않습니다. 기본 위생 수칙은 일회용 토큰, 짧은 만료 시간, 무작위 생성, HTTPS 전용 링크입니다.' - question: '비밀번호 없는 인증은 MFA와 같은 것입니까?' answer: '아닙니다. 그리고 둘 중 하나를 고르라는 흔한 구도는 잘못되었습니다. MFA는 요소를 더하고, 비밀번호 없는 인증은 기억에 의존하는 요소를 없앱니다. 생체 인식으로 잠금 해제하는 패스키는 그 둘을 동시에 충족합니다. 디바이스의 소유와 그것을 잠금 해제하는 본인의 특성이 결합된, 비밀번호가 어디에도 없는 한 번의 동작으로 끝나는 다중 인증입니다.' - question: '디바이스를 잃어버리면 어떻게 됩니까?' answer: '동기화 패스키는 자격 증명 관리자를 통해 복원되지만, 디바이스 종속 키는 설계상 복원되지 않습니다. 원칙은 이렇습니다. 서로 다른 디바이스에 최소 두 개의 인증 수단을 등록하고, 오프라인 복구 코드를 보관해야 합니다. 그리고 약한 대체 수단, 예컨대 패스키 뒤에 둔 이메일 OTP는 계정 전체의 강도를 그 대체 수단의 수준으로 조용히 제한한다는 점을 기억해야 합니다.' - question: '앱에 비밀번호 없는 로그인을 어떻게 추가합니까?' answer: '한 번에 갈아엎지 말고 기능을 더하는 방식으로 추가해야 합니다. 기존 로그인은 유지하고, 패스키나 매직 링크를 권장 경로로 제공하며, 설정 단계에서 대체 수단을 등록받고, 비밀번호는 나중에 격하합니다. WebAuthn의 경우 챌린지와 출처 검사를 직접 구현하기보다 유지 관리되는 오픈소스 서버 라이브러리로 절차 검증을 처리하는 것이 좋습니다.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'W3C Web Authentication (WebAuthn) Level 3' url: 'https://www.w3.org/TR/webauthn-3/' - name: 'FIDO Alliance — Passkeys' url: 'https://fidoalliance.org/passkeys/' - name: 'NIST SP 800-63B — Digital Identity Guidelines: Authentication' url: 'https://pages.nist.gov/800-63-4/sp800-63b.html' - name: 'CISA — Implementing Phishing-Resistant MFA' url: 'https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf' - name: 'Passwordless authentication — Wikipedia' url: 'https://en.wikipedia.org/wiki/Passwordless_authentication' cta: title: '비밀번호 없는 인증, Cloud Function 하나면 충분합니다' text: 'Back4app에서 Cloud Code로 매직 링크 로그인을 구축할 수 있습니다. 토큰 생성, 이메일 발송, 세션 발급이 모두 서버 측에서 이루어집니다. 또는 Back4app의 커스텀 인증 어댑터로 어떤 OTP나 패스키 제공업체든 연결할 수 있습니다.' linkText: '무료로 시작하기' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-11-02' translationKey: passwordless-authentication --- **비밀번호 없는 인증은 외워 둔 비밀 대신 디바이스에 보관된 키나 생체 인식으로 신원을 확인하는 로그인 방식입니다.** 인증 요소의 언어로 말하면, "아는 것"을 없애고 "가진 것"과 "본인의 특성"으로 인증합니다. 가장 강력한 형태에서는 공유 비밀이 아예 존재하지 않습니다. 서버는 공개 키를 저장하고 개인 키는 결코 사용자의 디바이스를 떠나지 않으므로, 피싱하거나 크리덴셜 스터핑에 쓰거나 대량으로 유출할 대상이 없습니다. 비밀번호가 여전히 남아 있는 것은 좋아서가 아니라 이미 깔려 있기 때문이며, 비밀번호 없는 인증은 마침내 대규모로 진행 중인 마이그레이션입니다. ## 핵심 요약 | 질문 | 답변 | | --- | --- | | 바뀌는 것 | 지식 요소는 빠지고, 소유 요소 + 본인의 특성(생체 인식)이 들어옵니다 | | 최고 기준 | 패스키(FIDO2/WebAuthn) – 출처에 묶인 키, 피싱 방지 | | 정직한 서열 | 패스키 > 푸시/TOTP > 매직 링크 > SMS – 각각 무언가의 보안 수준을 물려받습니다 | | vs. MFA | 거짓 경쟁 구도 – 생체 인식으로 잠금 해제하는 패스키는 비밀번호를 뺀 MFA *그 자체*입니다 | | 약한 고리 | 복구 – 정문보다 약한 대체 수단은 그 자체가 정문이 됩니다 | ## WebAuthn 절차, 알기 쉽게 모든 패스키 확인 창 뒤에 있는 메커니즘입니다. 두 가지 절차(ceremony)로 이루어지며, 전송되는 비밀은 없습니다: ```text 등록 로그인 1 서버가 무작위 챌린지를 전송 1 서버가 새로운 챌린지를 전송 2 navigator.credentials.create() 2 navigator.credentials.get() 3 디바이스가 키 쌍을 생성하고, 3 로컬 생체 인식/PIN으로 잠금 해제, 생체 인식이나 PIN으로 보호 디바이스가 챌린지에 서명(SIGNS) 4 공개 키 → 서버, 개인 키는 4 서버가 저장된 공개 키로 디바이스를 절대 떠나지 않음 검증 → 세션 발급 자격 증명은 출처(ORIGIN)에 묶여 있습니다. 유사 도메인이 받는 서명은 어디에서도 검증되지 않습니다. "피싱 방지"의 의미는 생체 인식이 아니라 바로 이 속성입니다. ``` 대부분의 앱이 먼저 도입하는 더 완만한 진입로는 받은편지함이 인증 요소가 되는 매직 링크입니다: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link await Parse.Cloud.run('requestMagicLink', { email: 'ada@example.com' }); // 2 · The link opens the app with the token; exchange it for a session const { sessionToken } = await Parse.Cloud.run('redeemMagicLink', { token: tokenFromLink, // single-use, expires in 15 minutes }); await Parse.User.become(sessionToken); // logged in — no password exists ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link await ParseCloudFunction('requestMagicLink') .execute(parameters: {'email': 'ada@example.com'}); // 2 · The deep link opens the app with the token; exchange for a session final result = await ParseCloudFunction('redeemMagicLink') .execute(parameters: {'token': tokenFromLink}); // single-use, 15 min // Adopt the returned session token — logged in, no password exists ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link _ = try await Cloud.run(name: "requestMagicLink", parameters: ["email": "ada@example.com"]) // 2 · The universal link opens the app with the token; exchange for a session let result = try await Cloud.run(name: "redeemMagicLink", parameters: ["token": tokenFromLink]) try await User.become(sessionToken: result["sessionToken"] ?? "") // logged in — no password exists ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link ParseCloud.callFunction>( "requestMagicLink", mapOf("email" to "ada@example.com")) // 2 · The deep link opens the app with the token; exchange for a session val result = ParseCloud.callFunction>( "redeemMagicLink", mapOf("token" to tokenFromLink)) // single-use, 15 min ParseUser.becomeInBackground(result["sessionToken"] as String) // logged in — no password exists ``` ## 패스키 vs. 매직 링크 vs. OTP: 방법별 순위 모든 비밀번호 없는 방법은 무언가의 보안 수준을 물려받습니다. 아래 표는 그것이 무엇인지 보여 줍니다: | 방법 | 요소 | 피싱 방지? | 위험을 물려받는 곳 | 복구 방식 | | --- | --- | --- | --- | --- | | **패스키(동기화)** | 소유 + 특성 | **예** – 출처에 묶임 | 자격 증명 관리자 계정 | 여러 디바이스에 걸쳐 복원 | | **보안 키(디바이스 종속)** | 소유(+ 특성) | **예** | 물리적 보관 | 없음 – 예비 키를 등록해야 함 | | TOTP / 인증 앱 코드 | 소유 | 아니요 – 코드는 중계될 수 있음 | 등록 시의 비밀 값 | 재등록 | | 푸시 승인 | 소유 | 아니요 – 푸시 폭탄(MFA 피로) 공격에도 취약 | 사용자의 주의력 | 재등록 | | 매직 링크 | 소유(받은편지함) | 아니요 | **사용자의 이메일 계정** | *그 자체가* 복구 경로 | | SMS 일회용 코드 | 소유(전화번호) | 아니요 | 통신사 – SIM 스와핑 | 이 중 가장 약함 | 중요한 경계선은 처음 두 행과 나머지 사이를 지나갑니다. 코드, 링크, 승인은 모두 실시간 피싱 프록시를 통해 중계될 수 있지만, [출처에 묶인 서명은 그렇지 않습니다](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf). [MFA 글의 방법별 순위](/glossary/ko/multi-factor-authentication-mfa/)에 그어진 경계선과 같은데, 실제로 같은 선이기 때문입니다. ```mermaid flowchart LR accTitle: 패스키가 피싱 프록시를 무력화하는 이유 accDescr: 패스키를 쓰면 디바이스가 진짜 출처에 묶인 챌린지에 서명하므로, 로그인을 중계하는 가짜 사이트가 받는 서명은 검증에 실패합니다. 일회용 코드를 쓰면 피해자가 속아서 가짜 사이트에 코드를 입력할 수 있고, 가짜 사이트는 이를 진짜 사이트에 성공적으로 중계합니다. V["피해자"] -->|"OTP 코드 입력"| F["가짜 사이트
(프록시)"] -->|"중계 – 성공"| R["진짜 사이트"] V2["패스키를 쓰는 피해자"] -->|"디바이스가 가짜 출처용으로
서명"| F2["가짜 사이트"] -.->|"진짜 출처에서는
서명이 무효"| X["실패"] ``` ## 동기화 vs. 디바이스 종속: 진짜 트레이드오프 패스키는 두 가지 보관 모델로 나뉘며, 그 차이는 현학이 아니라 정책의 문제입니다. **동기화 패스키**는 자격 증명 관리자에 저장되어 사용자의 여러 디바이스에 종단 간 암호화된 상태로 복제됩니다. 휴대폰을 잃어버려도 아무 문제가 되지 않으며, 그래서 마침내 소비자 도입이 움직였습니다. 신뢰 측면의 대가는 동기화 계정이 가장 중요한 자산이 되고, 그 계정은 자체 복구 흐름으로 보호된다는 점입니다. **디바이스 종속 키**(하드웨어 보안 키, 기업용 증명(attestation)을 거친 인증 수단)는 하드웨어를 결코 떠나지 않습니다. 관리자와 규제 대상 접근을 위한 높은 보증 수준의 선택이며, 복구 계획은 "예비 키 등록"이 전부입니다. [NIST의 현행 지침](https://pages.nist.gov/800-63-4/sp800-63b.html)은 일반적인 경우에 대한 논쟁을 정리했습니다. 동기화 인증 수단은 표준 보증 수준에서 허용되며, 디바이스 종속 방식은 최상위 등급을 위해 남겨 둡니다. ## 다시, 복구 문제 비밀번호 없는 인증은 인증에서 가장 오래된 규칙을 더 날카롭게 만듭니다. **계정의 강도는 가장 약한 복구 경로의 강도와 같습니다.** 이메일 OTP를 대체 수단으로 둔 패스키 로그인은 공격자에게는 단계가 몇 개 더 붙은 이메일 OTP 로그인일 뿐입니다. 디바이스 종속 키에는 설계상 "재설정"이 없으므로 규율은 앞단에 집중되어야 합니다. 설정 단계에서 서로 다른 디바이스에 두 개 이상의 인증 수단을 등록하고, 오프라인 복구 코드를 발급하며, 대체 수단을 지원 편의가 아니라 보안 결정으로 다루고, 인증 수단 제거를 단계적 인증이 필요하고 기록되며 경보를 발생시키는 이벤트로 만들어야 합니다. 이 과정을 건너뛴 배포는 헬프데스크를 통해 이를 다시 배우게 됩니다. ## MFA와의 대결이 아니라 결합 벤더 비교 페이지의 "비밀번호 없는 인증 vs. MFA" 구도는 잘못된 이분법입니다. [MFA](/glossary/ko/multi-factor-authentication-mfa/)는 여러 *범주*의 요소를 뜻하고, 비밀번호 없는 인증은 기억에 의존하는 비밀이 없다는 뜻입니다. 지문으로 잠금을 해제하는 패스키는 **둘 다**입니다. 디바이스의 소유에 잠금 해제 시점의 본인 특성이 더해진, 한 번의 동작으로 끝나는 다중 인증이며, 피싱당할 수 있는 요소는 보완되는 대신 삭제되었습니다. 실무적인 결론은 이렇습니다. 조직은 둘 중 하나를 고르는 것이 아니라 "비밀번호 + 두 번째 요소"에서 "패스키"로 옮겨 갑니다. 같은 곡선 위에서 엄밀하게 더 강한 지점입니다. ## 일반적인 사용 사례 - **소비자 앱 로그인** – 패스키를 권장 경로로, 매직 링크를 마찰이 적은 대체 수단으로 제공합니다. - **재방문 커머스** – 로그인 마찰이 측정 가능한 매출로 직결되는 곳에서는 한 번의 동작으로 끝나는 로그인이 제값을 합니다. - **직원 접근** – 관리자와 높은 권한의 역할에 대해 피싱 방지 인증 수단을 정책으로 요구합니다. - **비밀번호 없는 방식을 우선하는 제품** – 비밀번호 입력란을 한 번도 제공하지 않고 이메일 링크나 OTP로 온보딩합니다. - **단계적 인증 시점** – 결제, 삭제, 키 내보내기 전에 재인증 수단으로 패스키 절차를 사용합니다. ## 비밀번호 없는 인증으로 전환해야 할까? 결정 매트릭스 | 상황 | 권장 방향 | | --- | --- | | 새 소비자 앱 | 패스키 + 매직 링크 대체 수단, 비밀번호 입력란은 생략 | | 기존 앱, 대규모 사용자층 | 공존: 패스키를 권장 경로로 추가하고, 비밀번호는 나중에 격하 | | 관리자 / 높은 권한의 계정 | 피싱 방지 방식만 – 패스키나 하드웨어 키 | | 공유 디바이스나 오래된 디바이스를 쓰는 사용자층 | 기대치를 정직하게 잡고 매직 링크 / OTP | | 규제 대상, 높은 보증 수준의 접근 | 디바이스 종속 인증 수단, 증명(attestation), 예비 키 등록 | | "이번 스프린트에 보안만 좀 추가" | 지금은 [기존 로그인에 MFA](/glossary/ko/multi-factor-authentication-mfa/), 비밀번호 없는 인증은 그다음 | ## 한계와 트레이드오프 - **지원 범위가 아직 보편적이지 않습니다.** 모든 사이트, 브라우저, 기업 스택이 패스키를 지원하는 것은 아닙니다. 비밀번호는 호환성을 위한 비계로 남아 있으며, 그래서 한 번에 넘어가는 마이그레이션보다 공존이 낫습니다. - **키는 생태계가 쥐고 있습니다.** 동기화 패스키는 보관을 플랫폼의 자격 증명 관리자에 위임합니다. 직접 운영하는 대신 물려받는 가용성과 신뢰에 대한 의존성입니다. - **복구가 진짜 프로젝트입니다.** 약한 재설정 경로를 가진 가장 강력한 절차는 보여 주기식 보안일 뿐입니다. WebAuthn 연동뿐 아니라 등록 UX와 대체 수단 정책에도 예산을 배정해야 합니다. - **약한 비밀번호 없는 인증은 여전히 약합니다.** 매직 링크와 SMS는 비밀번호를 없애지만 피싱 방지 기능을 더하지는 않습니다. 개선이지 목적지가 아닙니다. - **지원 모델이 바뀝니다.** "비밀번호 분실" 티켓은 "디바이스 분실" 티켓이 됩니다. 헬프데스크에는 새로운 사회공학 공격의 구멍이 되지 않는 본인 확인 절차가 필요합니다. ## Back4app에서의 비밀번호 없는 인증 Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 여기서 비밀번호 없는 인증은 플랫폼의 기본 요소로 조합하는 패턴이며, 코드 탭은 그 대표적인 형태를 보여 줍니다. 두 개의 Cloud Code 함수로 구축하는 매직 링크 흐름입니다. `requestMagicLink`는 짧은 만료 시간을 가진 일회용 토큰을 생성해 사용자 객체에 저장하고 링크를 이메일로 보냅니다. `redeemMagicLink`는 서버 측에서 토큰을 검증하고 SDK가 채택하는 [세션 토큰](/glossary/ko/session-management/)을 반환하므로, 클라이언트는 자격 증명을 전혀 다루지 않습니다. 링크 외에도 Back4app의 커스텀 인증 어댑터는 [소셜 로그인](/glossary/ko/oauth-2-social-login/)을 구동하는 것과 같은 `authData` 메커니즘에 OTP와 패스키 제공업체를 연결합니다. 하나의 사용자 객체에 여러 로그인 방법을 두고 사용자별로 연결하거나 해제할 수 있으며, 이는 복구 규율(여러 개의 등록된 방법)을 데이터 모델링으로 표현한 것입니다. 세션은 처음부터 끝까지 폐기 가능한 상태로 유지됩니다. 어떤 절차를 거쳤든, 그 절차가 발급한 자격 증명은 이상 징후가 보이는 즉시 무효화할 수 있습니다.