네이티브 앱 패스키: 네이티브 구현과 웹뷰 구현 비교

인증은 파수꾼처럼 사용자 데이터를 보호하고 네이티브 앱 내에서 안전한 상호작용을 보장하는 역할을 합니다. 패스키의 등장은 이 분야에 혁명을 일으켰으며, 강력하고 사용자 친화적인 인증 메커니즘을 제공합니다. 네이티브 앱에 패스키를 통합하는 방법에는 크게 네이티브 구현과 웹뷰(WebView)를 통한 구현 두 가지가 있습니다. 먼저 두 방법이 어떻게 다른지 비교해 보겠습니다.

네이티브 구현은 종종 앱 내에서 최고의 사용자 경험을 제공하는 것으로 여겨집니다. 이는 iOS나 Android와 같은 운영 체제 환경에 정확하게 맞춰진 부드럽고 통합적이며 일관된 사용자 상호작용이 특징입니다. 100% 네이티브 구현을 위해서는 100% 비밀번호 없이 진정한 패스키 네이티브가 되어야 합니다. 이 접근 방식은 네이티브 앱과 웹 콘텐츠(웹뷰를 통해 표시됨) 간의 전환에서 발생할 수 있는 잠재적인 마찰에서 벗어날 수 있게 해줍니다.

네이티브 앱을 개발할 때 항상 완전한 네이티브 방식으로 가는 것이 가능한 것은 아닙니다. OAuth2를 활용하는 비밀번호 기반 인증을 계속 지원해야 하는 시나리오에서는 완전한 네이티브 통합이 불가능할 수 있으며, 이 경우 웹뷰 구현이 유일한 대안이 됩니다. 웹뷰는 다리 역할을 하여 웹 콘텐츠를 앱 내에 직접 내장하고, 웹 페이지를 탐색하는 동안 브라우저와 유사한 UX를 제공합니다. 이는 여러분이 직접 OAuth2 제공자이거나, 기본 인증 솔루션이 OAuth2 기반이거나, 로그인 솔루션이 Google이나 GitHub와 같은 제3자를 통한 소셜 로그인을 사용하는 경우에 특히 중요합니다. 이러한 경우, 웹 콘텐츠와 상호작용하고 다양한 사용자 인증 흐름을 관리해야 하므로 웹뷰 사용이 불가피해지며, 특히 네이티브 앱 연결이 필요한 경우 더욱 그렇습니다.

본질적으로, 네이티브 구현은 비할 데 없이 부드러운 사용자 경험을 제공하지만, 특히 비밀번호 기반 또는 OAuth2 기반 인증 솔루션과 결합될 경우 항상 실행 가능한 옵션은 아닐 수 있습니다. 반면에 웹뷰 구현은 웹 콘텐츠를 통합하고 앱 내에서 사용자 인증을 관리할 수 있는 유연하지만 약간 덜 매끄러운 경로를 제공하여, 다양한 인증 흐름과 제3자 로그인의 복잡성을 해결할 수 있도록 보장합니다.

이 글의 다음 섹션에서는 웹뷰를 통한 구현에 초점을 맞춥니다. 네이티브 패스키 통합에 대해 더 자세히 알아보려면 여기를 참조하세요.

네이티브 앱에서 인증의 미로를 탐색하면서 개발자와 제품 관리자는 중요한 결정에 직면합니다: 패스키 인증을 네이티브로 구현할 것인가, 아니면 웹뷰를 통해 구현할 것인가. 후자를 결정했다면, iOS와 Android 플랫폼 모두 각각 고유한 속성과 잠재적 사용 사례를 가진 두 가지 종류의 웹뷰를 제공합니다.

• WKWebView
• SFSafariViewController
• SFAuthenticationSession / ASWebAuthenticationSession (OAuth / OpenID Connect 기반 인증 흐름에 특화됨)

• WebView
• Chrome Custom Tabs (CCT)

다음 섹션에서는 이러한 웹뷰 유형에 대해 더 깊이 파고들어, 궁극적으로 네이티브 앱에서 패스키 인증을 위해 어떤 웹뷰를 사용해야 할지에 대한 정보에 입각한 결정을 내릴 수 있도록 안내합니다(순수 네이티브 구현이 대안이 아닌 경우).

iOS 웹뷰는 WKWebView 또는 SFSafariViewController입니다(OAuth / OIDC로 작업하는 경우 SFAuthenticationSession / ASWebAuthenticationSession).

iOS에서 다양한 웹뷰 동작을 테스트하려면 WebView - WKWebView and UIWebView rendering 앱을 추천합니다.

WKWebView는 iOS 개발자를 위한 강력하고 다재다능한 웹뷰 옵션입니다. iOS 8과 함께 도입되었으며, 개발자가 앱 내에 웹 콘텐츠를 직접 내장할 수 있게 하여 다양한 커스터마이징 및 구성 옵션을 제공합니다. WKWebView는 Safari와 동일한 웹 렌더링 엔진을 사용하여 성능이 뛰어나며, 웹 콘텐츠와 상호작용하고, 탐색, 사용자 상호작용 등을 관리하기 위한 풍부한 API 세트를 제공하는 것으로 유명합니다.

SFSafariViewController는 개발자가 앱 내에서 직접 Safari의 기능을 활용할 수 있게 해주는 웹뷰입니다. 사용자의 Safari 설정(저장된 비밀번호, 패스키, 쿠키 등)을 활용하여 원활한 사용자 경험을 제공하며, 실제로 Safari 애플리케이션으로 실행되기 때문에 일관된 웹 브라우징을 보장합니다. SFSafariViewController는 WKWebView만큼 커스터마이징이 가능하지는 않지만, 향상된 보안 기능과 사용 편의성을 제공하여 앱 내에서 간단한 웹 콘텐츠를 표시하는 데 선호되는 선택입니다.

SFAuthenticationSession 및 ASWebAuthenticationSession은 OAuth / OpenID Connect 기반 인증 흐름에 특화된 웹뷰입니다. 사용자 인증을 위한 안전하고 격리된 공간을 제공하여 사용자 자격 증명을 보호하고 개인 정보가 앱과 부주의하게 공유되지 않도록 보장합니다. 이러한 세션은 Safari와 쿠키 및 웹사이트 데이터를 공유하여 특히 인증 과정에서 일관되고 원활한 사용자 경험을 제공합니다.

장점:

• 전용 인증: OAuth / OpenID Connect 기반 인증 흐름을 위해 특별히 설계되어 간소화된 인증 프로세스를 보장합니다.
• 개인정보 보호: 앱과 쿠키 또는 웹사이트 데이터를 공유하지 않아 사용자 데이터 개인정보를 보호합니다.
• SSO 지원: 싱글 사인온(SSO)을 지원하여 편리한 사용자 경험을 제공합니다.

단점:

• 제한된 사용 사례: 주로 OAuth / OpenID Connect 인증에 초점을 맞추고 있어 모든 사용 사례에 적합하지 않을 수 있습니다.

주요 작업이 사용자 인증, 특히 SSO를 구현하거나 OAuth 제공자와 상호작용하는 경우 SFSafariViewController 대신 SFAuthenticationSession / ASWebAuthenticationSession을 사용해야 합니다.

안드로이드 웹뷰는 WebView 또는 **Chrome Custom Tabs (CCT)**입니다. 안드로이드에서 다양한 웹뷰 동작을 테스트하려면 WebView vs Chrome Custom Tabs 앱을 추천합니다.

안드로이드의 웹뷰는 개발자가 앱 UI의 일부로 웹 콘텐츠를 표시할 수 있게 해주는 포괄적인 구성 요소입니다. 다재다능하며 다양한 커스터마이징 옵션을 제공하고 개발자에게 다양한 요구에 맞게 웹뷰를 구성할 수 있는 유연성을 제공합니다. 웹뷰는 웹 콘텐츠와 상호작용하고, 사용자 상호작용을 관리하며, 심지어 자바스크립트 대화 상자, 클라이언트 인증서 및 권한 요청을 처리하기 위한 풍부한 API 세트를 제공합니다.

Chrome Custom Tabs (CCT)는 웹 콘텐츠를 앱에 직접 통합하는 원활하고 안전하며 효율적인 방법을 제공합니다. Chrome의 기능과 보안 기능을 활용하여 CCT는 일관되고 고성능인 사용자 경험을 제공합니다.

CCT는 Chrome 브라우저의 구성 요소로, 안드로이드 프레임워크와 통합되도록 설계되어 앱이 가볍고 전용 프로세스에서 웹 콘텐츠를 열 수 있도록 합니다. 특히, 기존 브라우저보다 빠르게 열리며, 예열 호출을 통해 미리 로드될 때 잠재적으로 웹뷰보다 성능이 뛰어납니다. 자바스크립트를 실행하지만 자체 프로세스에서 작동하여 앱이 악성 코드를 실행하는 것을 방지합니다. 또한 CCT의 UI는 작업 표시줄을 제공하여 URL과 보안 페이지용 SSL 확인 잠금 아이콘을 표시함으로써 사용자가 로드되는 페이지의 신뢰성과 보안을 확신할 수 있도록 합니다.

일반적으로 iOS WKWebView와 안드로이드 웹뷰, 그리고 SFSafariViewController와 **Chrome Custom Tabs (CCT)**는 유사하다고 말할 수 있습니다.

고객들은 네이티브 앱에서 패스키를 어떻게 구현해야 하는지 지속적으로 문의합니다. 대체로 이러한 고객들은 다음과 같은 여러 그룹으로 나눌 수 있습니다.

그룹 A:

네이티브 앱을 처음부터 구축하고 바로 비밀번호 없는 인증을 사용할 수 있는 고객(기존 비밀번호 없음).

그룹 B:

기존 사용자와 기존 인증 솔루션을 보유한 고객. 종종 인증 프로세스에 패스키를 추가해야 하는 기존 웹 앱도 가지고 있습니다. 여기서 많은 회사는 2단계 프로세스를 결정합니다.

1. 기존 웹뷰 인증 흐름에 패스키를 추가합니다(Google과 GitHub가 네이티브 앱에서 구현한 방식).
2. 그 위에 네이티브 구현을 통해 패스키를 추가합니다. 이 네이티브 패스키 구현은 기존 웹뷰(예: 소셜 로그인 및 비밀번호용) 이전에 사용자가 패스키로 로그인할 수 있는지 확인합니다(KAYAK이 네이티브 앱에서 구현한 방식).

자신의 그룹 결정하기

사용자에게 네이티브 앱에서 최상의 패스키 구현을 제공하려면, 현재 기술 설정과 패스키를 어떻게 추진하고 싶은지에 따라 자신이 속한 그룹을 결정해야 합니다(이 질문은 그룹 B의 회사에 해당됩니다).

그룹 A를 위한 권장 사항: 네이티브 구현

완전히 새로운 앱을 구축하는 경우(그룹 A), 네이티브 패스키 구현으로 시작하여 즉시 완전히 비밀번호 없는 방식으로 전환하는 것을 권장합니다(따라서 어떤 종류의 웹뷰도 사용되지 않음). iOS 및 안드로이드용 네이티브 SDK 및 API를 사용하십시오(예: passkeys Flutter 패키지를 통해). 또한 신뢰 당사자 ID에 대한 이 글도 읽어보십시오.

그룹 B를 위한 권장 사항: 먼저 웹뷰, 그 다음 네이티브 구현

어떤 이유로든 오늘 네이티브로 패스키를 구현할 수 없는 경우(그룹 B), 웹뷰 구현으로 시작한 다음 향후 네이티브 패스키 구현으로 이동할 수 있습니다(이는 iOS 앱용 apple-app-site-association 및 안드로이드 앱용 assetlinks.json과 같은 연결 파일을 생성하여 작동합니다). 웹뷰 구현을 선택하는 이유는 다음과 같을 수 있습니다.

• 이미 OAuth2 기반 인증을 제공하고 있으며 사용자에게 계속 제공하고 싶습니다(OAuth2는 네이티브로 작동하지 않음, 표준 참조).
• 다른 인증 방법(예: 비밀번호, 소셜 로그인, OAuth2)을 제공하는 동일한 창/화면에서 패스키 인증을 제공하고 싶습니다.

이것이 Google이나 GitHub가 현재 네이티브 앱에서 패스키 인증을 구현한 방식입니다. 패스키 인증을 위해 웹뷰를 올바르게 설정하는 방법에 대한 아래 권장 사항을 참조하십시오. 그러나 KAYAK처럼 네이티브 패스키 구현을 고려하고 바로 2단계부터 시작하는 것을 권장합니다.

그룹 B에 속하고 네이티브로 패스키를 구현할 수 없는 경우, iOS용으로는 SFAuthenticationSession / ASWebAuthenticationSession을, 안드로이드용으로는 Chrome Custom Tabs를 활용하는 것을 권장합니다(그렇지 않으면 패스키가 어쨌든 작동하지 않을 것입니다).

다음은 이 권장 사항에 대한 이유입니다.

SFAuthenticationSession / ASWebAuthenticationSession은 Safari와 쿠키 및 웹사이트 데이터를 공유하여 인증 과정에서 원활한 사용자 경험을 제공합니다. 안드로이드의 Chrome Custom Tabs도 마찬가지입니다.

사용자는 브라우저에 저장된 비밀번호, 자동 완성 데이터 및 기타 저장된 정보를 활용하여 인증 프로세스를 더 부드럽고 빠르게 만듭니다.

iOS의 SFAuthenticationSession / ASWebAuthenticationSession과 안드로이드의 Chrome Custom Tabs는 사용자 인증을 위한 안전하고 격리된 공간을 제공하여 민감한 사용자 자격 증명이 보호되고 앱이나 다른 웹사이트와 부주의하게 공유되지 않도록 보장합니다.

이들은 Apple과 Google의 엄격한 보안 프로토콜을 준수하여 사용자 데이터가 안전하게 처리되고 개인정보가 유지되도록 합니다.

또한 이 설계 선택은 Safari와 Chrome의 지속적인 보안 업데이트 및 향상 기능의 이점을 누리므로 최신 보안 표준 및 프로토콜을 준수합니다.

iOS의 SFAuthenticationSession / ASWebAuthenticationSession과 안드로이드의 Chrome Custom Tabs는 사용자가 브라우저의 사용자 경험에 익숙하기 때문에 일관되고 친숙한 사용자 인터페이스를 제공합니다. 또한 Safari와 Chrome의 사용자 설정 및 환경설정이 적용됩니다.

앱 콘텐츠와 웹 콘텐츠 간의 부드러운 전환을 제공하여 사용자가 인터페이스 간의 전환으로 인해 불편함을 느끼지 않도록 합니다.

Chrome Custom Tabs는 Chrome의 성능을 활용하여 부드럽고 반응성이 뛰어난 사용자 경험을 보장하며, 이는 특히 인증 과정에서 사용자 불만이나 이탈을 방지하는 데 중요합니다.

CCT의 성능은 종종 안드로이드 웹뷰 옵션보다 우수하며(iOS의 SFAuthenticationSession / ASWebAuthenticationSession도 마찬가지), 웹 콘텐츠 및 인증 흐름이 신속하고 원활하게 처리되도록 보장합니다.

Chrome Custom Tabs, 안드로이드 웹뷰 및 표준 Chrome 브라우저 간의 성능 차이를 느끼려면 Google의 이 비교를 참조하십시오.

SFAuthenticationSession / ASWebAuthenticationSession은 OAuth / OpenID Connect 기반 인증 흐름을 처리하도록 특별히 설계되어 널리 사용되는 이러한 인증 프로토콜에 대해 간소화되고 안전한 프로세스를 보장합니다. 또한 WebAuthn / 패스키 인증에 권장되는 방법입니다.

안드로이드에는 인증 흐름을 위한 전용 클래스가 없지만 Chrome Custom Tabs와 안드로이드 앱 링크를 사용하여 유사한 동작을 구현할 수 있습니다.

또한, TikTok처럼 사용자가 인증되었을 때 패스키를 수집하는 방식으로 패스키를 도입하는 앱이 더 많아질 것으로 예상합니다. 이는 네이티브(TikTok의 구현) 또는 웹뷰 구현을 통해 수행할 수 있습니다. 적절한 접근 방식은 조건부 UI를 네이티브로 트리거하는 것입니다. 작동하지 않으면 웹뷰 구현을 표시합니다.

디지털 인증의 현대적 환경에서 네이티브 앱의 웹뷰를 통한 패스키 구현은 안전하고 사용자 친화적인 관행의 등불로 떠오릅니다. 최적의 웹뷰를 선택하는 과정이 복잡할 수 있지만, 기술적 선택을 사용자 경험 및 보안과 일치시키는 것이 중요합니다.