패스키 폴백 및 복구: 식별자 우선 접근 방식

1. 서론#

패스키 지원 기기가 거의 95%에 달하면서, 패스키는 기존 인증 방식의 진정한 대안으로 성장했습니다. 그러나 아무리 진보된 시스템이라도 패스키에 접근할 수 없거나(폴백) 심지어 분실된(복구) 상황에 대처하기 위해서는 효과적인 폴백 및 복구 전략이 필요합니다. 이 가이드는 폴백 및 복구가 필요한 다양한 시나리오를 살펴보고 가능한 해결책이 어떻게 생겼는지 논의하는 것을 목표로 합니다.

폴백 및 복구 방법에 대해 생각할 때, 이러한 방법의 강도가 주 인증 방법의 강도와 일치하는 것이 중요합니다. 이 가이드는 패스키의 다양한 사용 방식을 구분하며, 특히 패스키가 독립적인 MFA로 사용되는 맥락에 중점을 두어 폴백 및 복구 방법을 적절하게 조정합니다.

핵심 질문:

• 어떤 폴백 시나리오가 존재하나요? 패스키 시스템에서 발생할 수 있는 잠재적인 폴백 시나리오는 무엇이며, 보안을 유지하기 위해 이를 어떻게 처리해야 할까요?
• 복구는 어떻게 처리해야 하나요? 패스키의 사용 패턴, 특히 MFA를 사용하는 환경에 따라 안전을 보장하기 위해 복구 프로세스를 어떻게 설계해야 할까요?

이러한 질문의 탐구를 통해 이 가이드는 제품 관리자와 개발자에게 사용자 경험을 희생하지 않으면서 패스키 시스템을 효과적으로 설계, 구현 및 관리하는 데 필요한 통찰력을 제공할 것입니다.

2. 정의: 식별자, 보안 수준 및 폴백과 복구#

폴백 및 복구 전략을 자세히 알아보기 전에, 우리가 사용할 몇 가지 기본 용어에 대한 명확한 이해를 확립하는 것이 중요합니다.

2.1 식별자: 이메일, 전화번호, 사용자 이름#

대부분의 비즈니스 및 소비자 시스템에서 인증은 이메일(email), 전화번호(phone number), **사용자 이름(username)**이라는 세 가지 주요 식별자에 의존합니다.

대부분의 시스템은 주로 웹 기반 애플리케이션에서 이메일을 기본 식별자로 사용합니다. 그러나 모바일 우선 또는 앱 우선 플랫폼은 SMS 기반 OTP(일회성 비밀번호)를 자동으로 삽입하여 미리 채우기 쉽기 때문에 식별자로 전화번호를 사용하는 것을 선호하는 경우가 많습니다. 어떤 경우에는 주로 고유한 표시 이름(display name)이 필요한 플랫폼을 위해 이러한 식별자 외에 사용자 이름을 설정해야 할 수도 있습니다. 특히 규모가 큰 플랫폼에서는 유연성을 더하기 위해 이메일과 전화번호를 모두 사용할 수 있도록 허용하는 추세가 늘고 있습니다.

초기 가입 시 이러한 식별자는 일반적으로 확인 링크/OTP(이메일용) 또는 OTP(전화번호용)를 통해 인증되어 해당 식별자가 본인의 것인지 확인합니다. 접근 권한을 잃은 경우, 이전에 확인된 이메일이나 전화번호에 대한 제어 권한을 증명하는 것으로 대개 계정 접근을 복구하기에 충분합니다. 이러한 식별자는 사용자와 소통하는 가장 신뢰할 수 있는 형태이므로 MFA(다중 요소 인증) 목적으로 전화번호가 자주 수집되며, SMS는 흔히 사용되는 두 번째 요소입니다.

사용자 이름은 소셜 미디어, 포럼 또는 특정 전문가 플랫폼과 같이 공개적인 식별자가 필요한 시스템에서 사용자 신원의 추가적인 계층을 제공하기 위해 종종 사용됩니다. 인증에서 이메일이나 전화번호와 같은 기능적 역할을 수행하지는 않지만, 사용자 이름은 공개적이거나 P2P(peer-to-peer) 컨텍스트에서 사용자가 인식할 수 있는 정체성을 제공합니다. 그러나 사용자가 이를 잊어버리는 경우가 많아 복잡성이 가중되며, 대부분의 경우 사용자 이름과 함께 다른 식별자가 필요합니다. 따라서 이 문서에서는 사용자 이름에 중점을 두지 않을 것입니다.

(TOTP 코드를 생성하는) 인증기 앱(authenticator apps)과 같은 다른 2FA 옵션은 식별자에 의존하지 않지만 평균적인 사용자가 설정하기에 더 복잡한 경우가 많습니다. 패스키는 암호화폐(crypto) 분야에서 점점 인기를 얻고 있는 기능인 식별자 없이 작동하는 가능성(사용자 이름 없는 인증, usernameless authentication)도 도입했습니다. 그러나 소비자 및 비즈니스 솔루션 모두에서 폴백이나 복구 목적으로 사용자(종종 이메일을 통해)와 소통할 필요가 있기 때문에 사용자 이름 없는 시스템은 실용성이 떨어집니다.

2.2 보안 수준: 단일 요소 인증(SFA) 및 다중 요소 인증(MFA)#

단일 요소 인증(SFA, Single Factor Authentication) 시스템은 사용자의 신원을 확인하기 위해 한 가지 형태의 인증에 의존하는 시스템입니다. 일반적으로 이 단일 요소는 비밀번호이지만, 소셜 로그인, 이메일 OTP 또는 단 한 가지 유형의 증명만 요구하는 모든 방법이 될 수 있습니다. 오늘날 웹에 있는 대부분의 시스템은 SFA 시스템입니다. 그러나 보안 측면에서 잘 알려진 절충점(trade-off)이 있습니다. 패스키를 통합할 때 이는 보통 기존 비밀번호의 애드온(add-on)이나 대체 수단으로 사용되어 시스템의 편의성을 높입니다. 이러한 시스템에서 이메일 OTP나 소셜 로그인과 같은 폴백 옵션을 여전히 허용하는 것이 일반적이며, 이는 비밀번호를 줄여 사용자 경험을 향상시키지만 시스템의 보안을 SFA 이상으로 끌어올리지는 않습니다.

**다중 요소 인증(MFA, Multi-Factor Authentication)**은 사용자의 신원을 확인하기 위해 두 가지 이상의 독립적인 요소를 포함하며, 이것이 SFA보다 더 안전한 이유입니다. 이러한 요소에는 사용자가 알고 있는 것(비밀번호 또는 PIN), 사용자가 가지고 있는 것(보안 토큰 또는 휴대폰 앱), 사용자의 생체 정보(지문이나 안면 인식과 같은 생체 검증)가 포함될 수 있습니다. MFA 시스템은 피싱 공격이나 비밀번호 유출과 같이 SFA 시스템이 방어할 수 없는 특정 취약점으로부터 보호하도록 설계되었습니다. MFA 시스템 내에서 패스키를 사용할 때 일반적으로 독립적인 MFA 옵션으로 활용됩니다. 이러한 경우 폴백이나 복구 방법이 패스키와 동일한 수준의 보안을 유지하는 것이 중요합니다.

2.3 폴백 및 복구#

**폴백(Fallback)**은 여러 인증 방식이 공존하는 모든 시스템에서 사용됩니다. 기본 방법을 사용할 수 없을 때 사용되며, 흔히 사용자는 가입 초기부터 가입 방법(예: 소셜 로그인 대 비밀번호)을 선택할 수 있습니다. 폴백에는 이메일을 통한 OTP, 비밀번호, 일치하는 이메일을 통한 소셜 로그인, 네이티브 앱 푸시, QR 코드 또는 보안 키(security keys)와 같은 대체 인증 전략이 포함될 수 있습니다. 이러한 각 폴백 방법은 보안 품질이 다르며, 적절한 폴백 옵션을 선택하는 것은 사용자 편의성과 보안 요구 사항의 균형을 맞추는 데 중요합니다.

다중 요소 인증(MFA) 시스템의 일부로 패스키를 활용하는 환경에서는 이러한 폴백 방법이 패스키에 필적하는 다중 요소 보안을 제공하는지 주의 깊게 고려해야 합니다. 복구(Recovery) 프로세스는 사용자가 요구되는 보안 표준(SFA 또는 MFA)을 충족하는 모든 설정된 인증 수단에 대한 접근 권한을 잃었을 때 중요해집니다. 이는 다수의 복구 옵션을 사용할 수 있는 단일 요소 시스템에서는 덜 중요합니다. 예를 들어 이메일 OTP를 통해 비밀번호를 재설정하는 것은 사용자가 연결된 식별자에 대한 제어 권한을 가지고 있음을 효과적으로 검증합니다. 그러나 2FA/MFA 시스템에서는 본질적으로 검증을 위해 여러 요소에 의존하기 때문에 복구가 특히 어렵습니다. 사용자가 모바일 운영 체제를 변경(예: iPhone에서 Android 휴대폰으로)하여 연결된 패스키와 전화번호를 모두 잃어버리는 시나리오에서, 남은 요소(예: 비밀번호 하나)만으로는 2FA 요구 사항을 충족할 수 없습니다. 이러한 경우의 복구는 수동 지원 요청이나 나중에 다룰 더 혁신적인 솔루션을 포함할 수 있는 새로운 신원 증명 생성을 필요로 할 수 있습니다.

3. 패스키 로그인 폴백: 수동 패스키 로그인 vs. 자동 패스키 로그인#

패스키 솔루션을 구현할 때 가장 먼저 결정해야 할 사항 중 하나는 패스키 로그인에 대한 접근 방식입니다. 사용 사례에 따라 소규모 플랫폼의 경우 수동 로그인이 충분할 수 있지만, UX 중심의 대규모 기업에는 식별자 우선 접근 방식이 권장됩니다. 이 방식은 사용자가 기본 식별자(아마도 이메일)를 입력한 후 패스키 로그인을 제공합니다.

3.1 수동 패스키 로그인: 사용자 주도 접근 방식#

3.1.1 사용자 주도 접근 방식이란 무엇인가요?#

소규모 플랫폼이나 패스키 로그인 비율 향상에 중점을 두지 않는 플랫폼에서 사용자 주도 접근 방식은 별도의 "패스키로 로그인" 버튼을 포함합니다. 이 방식에서는 패스키 사용에 대한 책임이 전적으로 사용자에게 있습니다. 계정에 패스키를 추가한 후, 사용자는 패스키를 사용하여 로그인하려면 "패스키로 로그인"을 클릭해야 함을 기억해야 합니다.

위 스크린샷은 수동 패스키 로그인 방식을 사용하는 https://my.gov.au의 패스키 구현을 보여줍니다. 이 방식은 백엔드에서 패스키 로그인 가능 여부를 판단할 필요가 없기 때문에 구현하기가 더 쉽지만, 일반적으로 훨씬 낮은 패스키 로그인 비율로 이어집니다. 이는 사용자 주도에 크게 의존하며 소비자가 자신의 패스키가 어느 플랫폼이나 클라우드 스토리지에 있는지 기억하지 못하거나 확신하지 못할 수 있기 때문입니다. 이 접근 방식은 사용자를 생각하게 만듭니다. 다음 섹션에서는 이 방식에 어떤 잠재적인 폴백 기회가 존재하는지 살펴보겠습니다.

3.1.2 폴백#

패스키 접근에 실패할 가능성이 있는 모든 시스템에서 폴백은 필수적입니다. 수동 패스키 로그인 방식에서는 모든 로그인 옵션이 동시에 표시되고 패스키가 사용자의 재량에 따라 선택되기 때문에 대화 상자와 폴백을 개별적으로 관리할 수 없습니다. 이는 몇 가지 문제로 이어집니다.

• 직관적이지 않은 오류: 패스키를 사용할 수 없거나 잘못 설정된 경우 사용자가 직면하는 오류 메시지는 명확하지 않은 경우가 많아 혼란을 일으킬 수 있습니다. 사용자는 패스키를 사용할 수 없는 이유나 무엇이 잘못되었는지 이해하지 못해 좌절감을 느낄 수 있습니다.
• 막다른 길: 사용자는 더 이상 진행할 수 없는 막다른 길에 부딪힐 수 있습니다. 패스키가 누락되거나 접근할 수 없는 경우 진행 방법이나 접근 권한 복구 방법에 대한 명확한 지침이 제공되지 않아 로그인 과정을 포기하게 될 수 있습니다.
• 안내 부족: 이러한 상황에서 시스템은 사용자를 대체 인증 방법으로 안내하는 유용한 지침을 제공할 수 없습니다. 사용자는 스스로 문제를 해결할 방법을 찾아야 하며, 이는 사용자 경험을 저하시킵니다.

위의 예시는 플랫폼 인증기에서 패스키를 찾을 수 없을 때 Windows 11의 오류 메시지가 얼마나 혼란스러운지 보여줍니다. 시스템은 패스키가 보안 키나 다른 기기에 존재한다고 가정할 수 있습니다. 특히 이전에 보안 키를 사용해 본 적이 없거나 패스키를 생성해 본 적이 없는 인증 흐름에 익숙하지 않은 사용자에게 이러한 과정은 혼란스러울 수 있습니다.

플랫폼 인증기에서 패스키를 찾을 수 없는 경우, 운영 체제와 브라우저는 패스키가 다른 곳에 존재해야 한다고 가정하므로 사용자가 아직 패스키를 생성하지 않았다면 더 큰 혼란을 초래합니다. 조건부 UI(Conditional UI)는 기존 패스키를 표시하여 도움을 줄 수 있지만, 이는 실제로 패스키가 존재하는 경우에만 도움이 됩니다. 최상의 패스키 경험을 위해, 사용자가 기본 식별자를 제공한 후 패스키 로그인을 트리거할지 여부는 백엔드에서 결정해야 합니다.

3.2 자동 패스키 로그인: 식별자 우선 접근 방식#

3.2.1 식별자 우선 접근 방식이란 무엇인가요?#

식별자 우선 접근 방식에서 사용자는 시스템이 패스키 로그인 가능 여부를 판단하기 전에 이메일이나 전화번호와 같은 기본 식별자를 제공하라는 메시지를 받습니다. 식별자가 확인된 후, 시스템은 가용하고 접근할 수 있는 경우 패스키를 포함하여 가장 적절한 로그인 방법을 자동으로 제안합니다. 이 방식은 사용자가 "패스키로 로그인" 옵션을 선택해야 한다는 것을 기억할 필요가 없으므로 더 사용자 친화적이며, 프로세스를 간소화하여 채택률을 향상시킵니다.

Google 식별자 우선 로그인

Google 패스키 로그인

위 스크린샷은 macOS 기기에 패스키가 연결된 계정의 Google 로그인 동작을 보여줍니다. Google 또한 식별자 우선 접근 방식을 따르며 패스키 로그인이 높은 확률로 가능할 것이라고 판단했습니다.

1. 패스키 플랫폼 지원: 기본 플랫폼이 플랫폼 인증기를 지원하므로 로그인이 가능할 수 있습니다.
2. 패스키 접근 가능: 패스키가 macOS 시스템에서 생성되었으므로 이 클라이언트(macOS)에서 접근할 수 있을 가능성이 매우 높습니다.

결과적으로 패스키 로그인이 자동으로 시작되어 사용자에게 가능한 최상의 경험을 안내합니다. 이는 "사용자를 생각하게 하지 마라" 전략을 따릅니다.

3.2.2 패스키 플랫폼 지원 부족 또는 패스키 접근 불가#

시스템은 패스키 로그인이 가능한지 판단합니다. 다음의 경우:

• 패스키가 존재하지 않음: 사용자가 계정에 대해 아직 패스키를 생성하지 않음.
• 패스키에 접근할 수 없음: 사용자가 생성한 패스키가 해당 클라이언트에서 사용 불가능할 가능성이 높음 (예: 사용자가 macOS 패스키만 가지고 있으며 현재 Windows에서 로그인 중).
• 패스키 인증이 지원되지 않음: 현재 클라이언트가 플랫폼 인증기를 지원하지 않으며 QR 코드를 통한 교차 기기 인증(Cross-Device-Authentication)도 지원할 가능성이 매우 낮음.

이러한 경우 성공적인 패스키 로그인이 될 가능성이 낮다고 판단하고 따라서 패스키 로그인을 트리거하지 않고 폴백 옵션이 자동으로 제공됩니다. 이 접근 방식은 사용자가 "패스키로 로그인" 옵션을 선택해야 한다는 것을 기억할 필요가 없기 때문에 훨씬 더 사용자 친화적이며, 프로세스를 간소화하여 채택률을 높이고 혼란스러운 막다른 길이 사용자에게 표시되는 최악의 시나리오를 방지합니다.

위의 예에서 로그인은 비밀번호로 폴백되며, 클라이언트가 Windows 11 기기이기 때문에 macOS 패스키에 접근할 가능성이 낮아 계정의 상태와 보안에 기반하여 추가적인 인증 요소를 계속 요구할 것입니다. 인증 시스템의 보안 요구 사항에 따라 이러한 경우 어떤 인증 방법(예: 마지막으로 성공한 비 패스키 인증 옵션)을 트리거할지 완전히 제어할 수 있습니다.

3.2.3 패스키 세리머니 중단#

사용자가 웹 로그인 중에 인증 화면에 직면할 때, 특히 패스키 기반 인증을 사용하는 것이 처음인 경우 놀라거나 당황할 수 있습니다. 이로 인해 사용자는 실패 때문이 아니라 단지 무슨 일이 일어나고 있는지 확신하지 못하여 인증 과정을 중단할 수 있습니다. 이러한 동작을 계획하고 첫 번째 중단을 오류가 아닌 정상적인 이벤트로 취급하는 것이 중요합니다.

첫 번째 중단 화면은 차분하고 안심시키는 방식으로 무슨 일이 일어나고 있는지 명확하게 설명하고 사용자가 프로세스를 재시도할 것을 권장해야 합니다(위의 Google 예시 참조). 이 화면은 중단을 사용자 경험의 규칙적이고 예상된 일부로 취급하여 불안감을 최소화하도록 설계해야 합니다. 많은 사용자가 인증 화면을 인식하지 못했거나 절차에 익숙하지 않아 단순히 중단할 수 있습니다. 따라서 재시도가 기본 제안이어야 합니다.

그러나 두 번째 중단이 발생하면 상황을 다르게 취급해야 합니다. 두 번째 중단은 플랫폼 인증기 문제, 사용자가 적절한 패스키를 찾을 수 없음, 또는 WebAuthn 세리머니의 기술적 실패 등 실제로 무언가 잘못되었음을 나타낼 수 있습니다. 이 시점에서 시스템은 문제가 발생했음을 설명하고 폴백 옵션을 조금 더 제시하는 다른 화면을 제공해야 합니다.

두 번째 중단 화면은 사용자가 대체 인증 방법으로 전환하도록 권장해야 합니다. 사용자가 추가적인 좌절감 없이 성공적으로 로그인할 수 있도록 해야 합니다. 위의 화면에서 볼 수 있듯이 Google은 여전히 "재시도(Try again)"를 제안하지만 동시에 무언가 잘못되었을 가능성이 있음을 사용자에게 보여줍니다.

3.3 패스키 구현 접근 방식 비교#

다음 표는 가장 중요한 특징을 요약하여 다양한 접근 방식을 비교하는 데 도움이 됩니다.

직접 구축하는 접근 방식(Do-it-yourself)은 대개 수동 패스키 로그인 방식을 따르며 조건부 UI와 패스키에 대한 사용자의 선택(opt-in)에 의존하여 매우 낮은 패스키 로그인 비율과 사용자 좌절을 초래합니다. 식별자 우선 접근 방식은 조건부 UI 위에 잘 고안된 기기 로직(device logic)을 확립해야 하며, 이 부분에서 Corbado가 도움을 드릴 수 있습니다. 사용자 정의 기기 로직과 패스키 인텔리전스(passkey intelligence)를 직접 구축하는 것은 권장되지 않습니다. 이 규칙 세트는 새로운 기기, 새로운 WebAuthn 및 클라우드 동기화 기능(예: GPM 패스키)에 맞게 지속적으로 미세 조정하고 수정해야 하기 때문입니다.

4. 패스키 복구#

패스키 복구는 사용자가 패스키에 대한 접근 권한을 잃었을 때 보안과 사용자 경험을 유지하는 데 중요한 측면입니다. 이는 MFA에 의존하는 시스템에서 특히 중요합니다. MFA의 경우 복구 프로세스는 사용자가 계정에 다시 접근할 수 있도록 허용하면서 보안을 유지하도록 보장해야 합니다. 복구 접근 방식은 시스템에서 사용되는 인증 수준에 맞춰 조정되어야 합니다.

4.1 단일 요소 복구 및 다중 요소 복구#

SFA 시스템에서 보안을 유지하기 위해 복구는 일반적으로 이메일 주소나 휴대폰 번호와 같은 식별자에 대한 제어 권한을 증명하는 것을 포함합니다.

• 이메일 OTP: 사용자의 등록된 이메일 주소로 OTP가 전송됩니다. 확인이 완료되면 사용자는 접근 권한을 되찾고 새 패스키를 생성할 수 있습니다.
• SMS OTP: 이메일 복구와 유사하게, 등록된 휴대폰 번호로 OTP가 전송됩니다. 사용자는 이 OTP를 사용하여 계정에 다시 접근할 수 있습니다.

이러한 방법은 간단하지만 사용자의 연락처 정보를 최신 상태로 유지하는 것에 의존합니다. 따라서 일상적인 로그인 중에 사용자가 정기적으로 이메일과 전화번호를 확인하도록 안내하는 것이 중요합니다.

다중 요소 인증(MFA) 시스템에서는 복구가 더 복잡해집니다. MFA는 다수의 독립적인 요소(예: 패스키, 소셜 로그인, OTP)에 의존하므로 하나의 요소(예: 패스키)를 사용할 수 없다는 이유로 사용자가 접근 권한을 잃어서는 안 됩니다.

• 대체 요소 사용: 패스키를 분실한 경우 사용자는 비밀번호 + SMS OTP 또는 인증기 앱과 같은 두 가지 다른 요소를 사용하여 인증할 수 있습니다. 인증이 완료되면 새 패스키를 생성할 수 있습니다.
• 다른 패스키 사용: 사용자가 패스키가 있는 다른 기기를 가지고 있는 경우, 적절한 힌트(예: iPhone에서 패스키 사용 요청)를 통해 해당 기기를 사용하여 접근 권한을 복구할 수 있습니다.
• 새 패스키 생성: 복구 방법으로 인증한 후 사용자는 MFA 설정이 그대로 유지되도록 새 패스키를 생성하도록 안내받아야 합니다.

SFA 및 MFA 시스템 모두에서 핵심은 복구 프로세스가 강력하고 안전하도록 보장하면서 사용자 불편을 최소화하는 것입니다.

4.2 스마트 MFA 복구: MFA 복구 비용의 디지털화#

민감한 개인 데이터를 다루는 시스템, 규제 산업 또는 공공 부문 서비스의 경우 표준 이메일 OTP 및 휴대폰 번호 OTP만으로는 복구에 항상 충분하거나 사용 가능하지 않을 수 있습니다. 이러한 경우 스마트 MFA 복구 메커니즘은 높은 보안 표준을 유지하면서 사용자에게 원활한 경험을 제공하는 고급 계정 복구 방법을 제공합니다.

가장 효과적인 방법 중 하나는 라이브니스 체크(liveness check)를 통한 셀카 신원 확인입니다. 이 과정에는 사용자가 신분증 사진을 찍는 것이 포함됩니다. 또한 셀카 라이브니스 체크를 통해 실시간으로 셀카를 촬영하고 있는지 확인하여 사용자가 물리적으로 존재하고 촬영된 신분증과 일치하는지 확인하므로 정적인 이미지나 도난당한 신분증을 이용한 사기를 방지합니다. 사용되는 기술에 따라 카메라와의 거리를 변경하거나 고개를 180도 돌리는(예: Apple Face ID) 짧은 동영상을 녹화하여 라이브니스 체크를 수행합니다.

이 방법은 이메일이나 SMS OTP와 같은 기존 복구 방법을 사용할 수 없거나 오래된 경우에 특히 유용할 수 있습니다. 예를 들어, 다음은 Onfido에서 셀카를 찍은 후 라이브니스 체크를 수행하는 예입니다.

예시: Onfido의 라이브니스 체크를 통한 셀카 신원 확인

• 정부 시스템, 규제 산업 또는 대규모 상업 서비스는 신분증에서 사용할 수 있는 정보를 확인하는 데 사용할 수 있는 개인 데이터를 보유하고 있습니다. 생년월일을 사용할 수 없는 경우 신분증을 통해 수집된 정보를 수동 복구 과정의 요소로 사용할 수 있습니다.

또한 다른 스마트 복구 방법에는 다음이 포함될 수 있습니다.

• 교차 기기 복구: 신뢰할 수 있는 보조 기기가 있는 사용자는 QR 코드를 스캔하여 계정을 복구할 수 있습니다.
• 알려진 환경: 과거에 성공적으로 사용했던 기기에 여전히 접근할 수 있는 사용자는 해당 기기를 사용하여 추가적인 확인 요소를 제공할 수 있으므로 동일한 기기, 제공업체 및 위치에서 활동하고 있다는 증거를 제공하여 수동 복구 과정을 도울 수 있습니다. Google이 Gmail 계정 복구(Gmail Account Recovery)에 사용하는 접근 방식입니다.
• 디지털 자격 증명(Digital Credentials) API: 신분증 지갑(ID wallets) 채택이 증가함에 따라 이 API를 통한 직접 검증은 안전하고 사용자 친화적인 계정 복구에서 점점 더 중요한 역할을 할 것으로 예상됩니다.

스마트 MFA 복구 방법은 특히 매우 민감하거나 규제된 정보를 다룰 때 사용자에게 계정 접근을 되찾을 수 있는 안전하고 직관적인 방법을 제공하는 것을 목표로 합니다. 이러한 접근 방식은 이메일이나 전화 복구와 같은 기존 방법을 사용할 수 없는 경우에도 사용자가 여전히 안전하고 효율적으로 접근 권한을 복구할 수 있도록 보장합니다. 스마트 복구는 MFA 복구 비용을 절감하는 데 도움이 됩니다.

4.3 MFA 복구 빈도: 전화번호 vs. 패스키#

휴대폰 번호를 변경하는 것이 Apple에서 Android로 전환하거나 그 반대의 경우보다 훨씬 빈번하기 때문에 클라우드에 동기화되는 패스키의 특성상 36개월이라는 기간 동안 MFA 복구 비용이 훨씬 낮다는 점을 명심하는 것이 중요합니다. 휴대폰 기기나 통신사 계약이 변경되는 경우 패스키가 복원됩니다.

따라서 동기화된 패스키에 대한 접근 권한을 잃는 것은 휴대폰 번호에 대한 접근 권한을 잃는 것보다 빈도가 낮으며, 이는 기존의 소비자 지향 MFA 시스템에서 복구에 따른 가장 큰 불편을 초래합니다.

그럼에도 불구하고 사용자 기반이 증가함에 따라 이러한 사례는 여전히 상당한 수동 지원 비용을 발생시키며 디지털 솔루션으로 처리되어야 합니다. 이에 대해서는 다음 섹션에서 살펴보겠습니다.

5. 제품 관리자 및 개발자를 위한 권장 사항#

인증 시스템에 패스키를 통합할 때 높은 수준의 보안을 유지하면서 원활한 사용자 경험을 보장하기 위해 폴백 옵션과 복구 전략을 신중하게 계획하는 것이 중요합니다. 패스키 로그인 비율을 최대화하려면 다음 권장 사항을 고려하세요.

• 식별자 우선 접근 방식 채택: 이 접근 방식은 더 사용자 친화적이며 로그인 과정에서 마찰을 줄여줍니다. 사용자가 먼저 기본 식별자(예: 이메일 또는 전화번호)를 입력하도록 요청함으로써 시스템은 패스키 로그인이 가능한지 자동으로 판단할 수 있습니다. 이를 통해 사용자가 수동으로 패스키 옵션을 선택하지 않고도 매끄럽고 직관적인 로그인 경험이 보장됩니다.
• 더 나은 사용자 경험을 위해 설명적인 중단 화면 사용: 보안이 최우선이 되어야 하지만 사용자가 패스키를 채택하도록 돕는 프로세스를 설계하는 것도 필수적입니다. 첫 번째 세리머니 중단을 정상적으로 취급하고 재시도에 대한 명확한 지침을 제공하세요.
• 폴백 및 복구 옵션을 안전하게 유지: 폴백 방법(이메일 OTP 및/또는 SMS OTP)이 기본 인증 방법의 보안 수준과 일치하는지 확인하세요. 예를 들어 패스키를 사용하는 MFA 시스템의 경우 동일한 보안 표준을 유지하기 위해 폴백에도 다중 요소가 필요해야 합니다.
• 정기적인 복구 메시지 자동화: 로그인 시 정기적으로 사용자에게 연락처 정보(이메일 주소 또는 전화번호)를 확인하도록 안내하여, 사용자가 패스키를 사용할 때 복구 옵션이 최신 상태로 유지되도록 하세요. 이는 오래된 복구 방법으로 인해 사용자가 계정에서 잠기는 것을 줄여줍니다.
• 보안 강화 및 지원 복구 비용 절감을 위한 스마트 복구 방법 고려: 온라인 신원 확인을 대조하기 위해 개인 데이터에 접근할 수 있는 시스템이나 규제 산업의 경우, 라이브니스 체크가 포함된 셀카 신원 확인과 같은 고급 복구 방법을 고려하세요. 이 방법은 보안 요구 사항에 따라 복구 과정을 직관적이고 사용자 친화적으로 유지하면서 추가적인 보안 계층을 제공할 수 있습니다.

패스키 로그인 비율을 최대화하는 것은 이러한 요소를 얼마나 잘 구현하느냐에 달려 있습니다. 원활한 폴백 및 복구 옵션을 보장하면 사용자는 주 인증 방법으로 패스키를 사용하는 데 확신을 가질 수 있습니다.

6. Corbado가 할 수 있는 일: UI 구성 요소 및 패스키 인텔리전스#

Corbado는 완전히 새로운 인증 시스템이 필요한 신규(greenfield) 프로젝트와 기존 인증 시스템에 패스키를 추가해야 하는 기존 프로젝트에 식별자 우선 접근 방식을 구현하는 데 필요한 모든 것을 제공합니다.

6.1 다양한 사용 사례를 위한 UI 구성 요소#

두 제품 모두 필요에 맞게 조정할 수 있는 UI 구성 요소를 제공합니다.

1. Corbado Complete: 패스키 우선 인증으로 프로젝트 시작
   로그인 프로세스를 간소화하는 원활한 식별자 우선 접근 방식을 포함하는 우리의 완전한 인증 시스템입니다. Corbado Complete는 사용자가 식별자를 제공한 후 패스키 로그인이 가능한지 자동으로 결정하여 안전하고 사용자 친화적인 경험을 가능하게 합니다. 이는 마찰을 줄이고 원활한 로그인 경험을 보장하여 패스키 채택을 최대화하는 데 중요합니다.
2. Corbado Connect: 앱 마이그레이션 없이 패스키 추가
   이미 확립된 인증 프로세스가 있고 확장 기능으로 패스키를 추가하려는 기업을 위해 Corbado Connect는 단일 요소 및 다중 요소 전략에 대한 애드온 솔루션을 제공합니다. 이 접근 방식은 패스키를 안전하고 편리한 옵션으로 원활하게 통합하여 기존 인프라를 보완하며, 사용자가 현재 시스템을 대대적으로 수정하지 않고도 패스키를 통해 인증할 수 있도록 합니다. 예를 들어 Corbado Connect는 Amazon Cognito에 원활하게 포함될 수 있습니다.

우리는 특히 소비자 지향 기업에 맞게 조정된 방식인 Google 및 대형 기술(big tech) 분야의 다른 저명한 플레이어와 같은 업계 리더와 우리의 방법을 엄격하게 일치시킵니다.

6.2 패스키 인텔리전스를 통한 식별자 우선 접근 방식 활성화#

우리의 목표는 단순히 패스키 채택(즉, 패스키 생성)을 최대화하는 것이 아니라 이러한 패스키가 적극적으로 사용되어 높은 로그인 비율(따라서 보안을 높이고 SMS OTP 비용을 줄임)을 달성하는 것입니다. 당사의 UI 구성 요소는 식별자 우선 접근 방식을 염두에 두고 구축되었으며 당사의 패스키 인텔리전스(Passkey Intelligence)에 직접 연결되어 클라이언트 환경 및 기존 패스키에 기반하여 패스키 가용성 및 접근성을 결정합니다. 논의된 모든 폴백 및 복구 기능을 지원합니다. 다음 화면은 우리의 중단 및 재시도 로직을 보여줍니다.

첫 번째 패스키 중단

두 번째 패스키 중단

패스키 채택과 패스키 사용 모두에 중점을 둠으로써 보안과 사용자 경험 사이의 균형을 유지하고, 사용자가 계속해서 마찰 없이 패스키에 참여할 수 있도록 돕습니다.

7. 결론#

이 가이드에서는 인증 시스템에 패스키를 통합한 이후의 다양한 폴백 및 복구 전략을 살펴보았습니다. 서론에서 제기된 핵심 질문들은 전체에서 다루어졌습니다.

• 어떤 폴백 시나리오가 존재하나요? 패스키 지원 부족이나 특정 기기에서 패스키에 접근할 수 없는 등 여러 가지 폴백 시나리오가 발생할 수 있습니다. 보안을 유지하고 원활한 UX를 제공하려면 패스키 로그인이 불가능할 때 이메일이나 SMS OTP와 같은 폴백 옵션을 사용할 수 있어야 합니다.
• 복구는 어떻게 처리해야 하나요? 복구 프로세스는 인증 시스템의 보안 수준에 맞춰 설계되어야 합니다. SFA 시스템에서는 이메일 또는 SMS OTP로 충분할 수 있지만, MFA 시스템에서는 접근 권한을 복구하고 새 패스키를 생성하기 위해 대체 요소를 사용해야 합니다. 고도로 규제되거나 민감한 환경에서는 라이브니스 체크가 포함된 셀카 신원 확인과 같은 스마트 복구 방법이 추가적인 보안을 제공합니다.

이 가이드에 설명된 모범 사례를 따르면 제품 관리자와 개발자는 사용자에게 안전하면서도 원활한 로그인 경험을 제공하는 강력한 패스키 기반 인증 시스템을 설계할 수 있습니다. 보안이 사용자 경험을 희생시킬 필요는 없습니다. 세심한 설계와 계획을 통해 두 가지 모두 달성할 수 있습니다.

Corbado 소개

Corbado는 대규모로 consumer authentication을 운영하는 CIAM 팀을 위한 Passkey Intelligence Platform입니다. IDP 로그와 일반 analytics 도구가 보여주지 못하는 것을 볼 수 있게 해드립니다: 어떤 디바이스, OS 버전, 브라우저, credential manager가 passkey를 지원하는지, 왜 등록이 로그인으로 이어지지 않는지, WebAuthn 플로우가 어디서 실패하는지, OS나 브라우저 업데이트가 언제 조용히 로그인을 망가뜨리는지 — Okta, Auth0, Ping, Cognito 또는 자체 IDP를 교체하지 않고도 전부 파악할 수 있습니다. 두 가지 제품: Corbado Observe는 passkey 및 다른 모든 로그인 방식에 대한 observability를 더합니다. Corbado Connect는 analytics가 내장된 managed passkey를 제공합니다 (기존 IDP와 함께). VicRoads는 Corbado로 500만+ 사용자에게 passkey를 운영하고 있습니다 (passkey 활성화율 +80%). Passkey 전문가와 상담하기 →

자주 묻는 질문(FAQ)#

식별자 우선 접근 방식(Identifier-First Approach)은 현재 기기에서 패스키에 접근할 수 없을 때 패스키 로그인을 어떻게 처리하나요?#

패스키에 접근할 수 없을 가능성이 높은 경우(예: Windows 기기에서 macOS 패스키에 접근 시), 시스템은 패스키 프롬프트를 자동으로 건너뛰고 대신 비밀번호나 OTP와 같은 폴백 옵션을 제시합니다. 이는 '사용자를 생각하게 하지 마라' 전략에 따라 성공 가능성이 높을 때만 패스키 로그인을 트리거하여 혼란스러운 막다른 상황을 방지합니다.

사용자가 패스키 인증 세리머니를 중간에 중단하면 어떻게 해야 하나요?#

첫 번째 중단은 정상적인 이벤트로 취급해야 하며, 사용자가 인증 화면에 익숙하지 않아 단순히 중단하는 경우가 많으므로 차분한 화면으로 재시도를 권장해야 합니다. 두 번째 중단이 발생하면 플랫폼 인증기나 패스키 가용성에 진짜 문제가 있음을 나타낼 수 있으므로, 시스템은 폴백 인증 옵션을 표시해야 합니다.

사용자가 패스키에 대한 접근 권한을 잃었을 때 MFA 시스템에는 어떤 복구 옵션이 있나요?#

MFA 시스템에서 사용자는 비밀번호와 SMS OTP와 같은 두 가지 대체 요소를 사용하여 인증하거나, 신뢰할 수 있는 다른 기기의 패스키를 사용한 다음 새 패스키를 생성하여 복구할 수 있습니다. 기존의 복구 방법을 사용할 수 없는 규제 산업의 경우, 라이브니스 체크가 포함된 셀카 신원 확인과 같은 스마트한 방법이 추가적인 보안 복구 경로를 제공합니다.

수동 '패스키로 로그인(Sign in with passkey)' 버튼 접근 방식이 식별자 우선 접근 방식에 비해 채택률이 낮은 이유는 무엇인가요?#

수동 접근 방식은 사용자 스스로 패스키 옵션을 기억하고 선택해야 하는 전적인 책임을 지게 하므로 일반적으로 패스키 로그인 비율이 훨씬 낮아집니다. 또한 플랫폼 인증기에서 패스키를 찾을 수 없을 때 불명확한 오류 메시지가 표시되어 사용자가 좌절감을 느끼고 로그인 시도를 포기할 수 있습니다.