패스키와 iframe: iframe에서 패스키를 생성하고 로그인하는 방법은?

범례
✅ = 지원됨 ❌ = 지원되지 않음

매주 점점 더 많은 기업들이 패스키 도입을 발표하고 있습니다(예: 최근의 Visa, Mastercard 또는 Vercel). 다른 회사의 개발자들과 제품 관리자들이 이러한 선례를 따르면서, 패스키 구현에 대한 더 많은 사용 사례가 논의되고 있습니다.

저희가 꾸준히 받는 질문 중 하나는 iframe에서 패스키가 어떻게 작동하는지에 대한 것입니다. iframe은 다양한 소스의 콘텐츠를 원활하게 삽입하기 위해 현대 웹 개발에서 널리 사용됩니다. 패스키와 WebAuthn의 맥락에서 iframe은 특히 보안 및 사용자 상호작용과 관련하여 고유한 과제를 안고 있습니다.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

이 블로그 게시물은 iframe에서 패스키와 WebAuthn을 사용하는 방법에 대한 포괄적인 가이드를 제공합니다. 우리는 다음을 다룰 것입니다.

• 현재 기능 탐색
• 교차 출처 iframe 지원 논의
• iframe 통합의 이점 강조
• 단계별 구현 가이드 제공

이 게시물을 다 읽고 나면 iframe 내에서 패스키를 활용하는 방법에 대해 명확하게 이해하게 될 것입니다.

iframe, 즉 인라인 프레임은 개발자가 현재 문서 내에 다른 HTML 문서를 삽입할 수 있게 해주는 HTML 요소입니다. 이 기능은 비디오, 지도, 기타 웹 페이지와 같은 외부 소스의 콘텐츠를 웹사이트에 통합하는 데 널리 사용됩니다.

다양한 종류의 iframe을 살펴보겠습니다.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

기본 iframe은 가장 일반적으로 사용되는 유형입니다. 현재 페이지 내에 다른 URL의 콘텐츠를 간단히 삽입합니다.

<iframe src="https://example.com"></iframe>

이 기본 iframe은 웹 페이지 내에 기사와 같은 정적 콘텐츠를 포함하는 데 자주 사용됩니다.

반응형 iframe은 화면 크기나 배치된 컨테이너에 따라 크기를 조절하도록 설계되었습니다. 이를 통해 삽입된 콘텐츠가 데스크톱, 태블릿, 휴대폰 등 모든 기기에서 잘 보이도록 보장합니다.

<iframe src="https://example.com" style="width: 100%; height: 500px;"></iframe>

CSS 미디어 쿼리를 사용하여 뷰포트 크기에 따라 iframe이 동적으로 조정되도록 할 수도 있습니다.

Get a free passkey assessment in 15 minutes.

Book free consultation

보안 또는 샌드박스 iframe은 iframe 내에서 수행할 수 있는 작업을 제한합니다. 이는 신뢰할 수 없는 소스의 콘텐츠를 삽입하거나 보안을 강화하는 데 유용합니다.

<iframe src="https://example.com" sandbox></iframe>

sandbox 속성에는 다음과 같은 다양한 제한 사항을 포함할 수 있습니다.

<iframe src="https://example.com" sandbox="allow-scripts allow-same-origin"></iframe>

sandbox 속성은 스크립트 실행은 허용하지만 양식 제출이나 플러그인 사용과 같은 잠재적으로 위험한 작업은 제한합니다.

Become part of our Passkeys Community for updates & support.

Join

교차 출처 iframe은 다른 도메인의 콘텐츠를 삽입합니다. 이는 결제 게이트웨이나 소셜 미디어 위젯과 같은 제3자 서비스를 통합하는 데 일반적으로 사용됩니다. 보안 제한으로 인해 이러한 iframe은 삽입하는 페이지의 콘텐츠에 대한 접근이 제한되며 그 반대도 마찬가지입니다.

교차 출처(cross-origin)란 로드되는 콘텐츠가 다른 출처(origin)에서 온다는 것을 의미하며, 여기서 출처는 스킴(프로토콜), 호스트(도메인), 포트 번호의 조합으로 정의됩니다. 예를 들어, https://example.com과 http://example.com은 다른 스킴(HTTP 대 HTTPS)을 사용하기 때문에 다른 출처로 간주됩니다.

마찬가지로, 하위 도메인은 상위 도메인과 별개의 출처로 취급됩니다. 예를 들어, https://example.com과 https://sub.example.com은 동일한 기본 도메인을 공유하더라도 교차 출처입니다. 이러한 분리는 한 하위 도메인의 스크립트와 데이터가 명시적인 허가 없이 다른 하위 도메인의 것과 직접 상호작용할 수 없도록 하여 보안을 강화합니다.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

기업들은 Corbado를 신뢰하여 사용자를 보호하고 패스키로 로그인을 더욱 원활하게 만듭니다. 지금 무료 패스키 상담을 받아보세요.

무료 상담 받기

다음은 교차 출처와 동일 출처의 개념을 설명하는 예시입니다.

교차 출처 예시:

**https://payment.example.com**의 콘텐츠를 **https://www.mystore.com**에서 호스팅되는 웹페이지에 삽입하는 경우. 이들은 도메인이 다르기 때문에 교차 출처입니다.

동일 출처 예시:

**https://www.example.com/shop**의 콘텐츠를 **https://www.example.com/blog**에서 호스팅되는 웹페이지에 삽입하는 경우. 이들은 동일한 스킴, 호스트, 포트를 공유하기 때문에 동일 출처입니다.

교차 출처 iframe은 소스가 다른 도메인에서 온다는 점에서 기본 iframe과 다릅니다. 반면 동일 사이트 iframe은 삽입된 곳과 동일한 도메인의 소스를 가집니다.

<iframe src="https://anotherdomain.com"></iframe>

iframe에서 패스키를 사용하는 것은 개발자가 이해해야 할 새로운 기능과 제약 사항을 가져옵니다. 이는 주로 올바른 권한을 설정하고 삽입된 컨텍스트 내에서 안전한 사용자 상호작용을 보장하는 것과 관련이 있습니다.

역사적으로 Web Authentication API는 주로 보안 문제로 인해 교차 출처 iframe에서 기본적으로 비활성화되었습니다. 이 제한으로 인해 개발자들은 인증을 위해 사용자를 리디렉션하거나 팝업 창을 사용해야 했고, 이는 덜 원활한 사용자 경험으로 이어졌습니다.

패스키 / WebAuthn에는 두 가지 핵심 작업(세레모니라고도 함)이 있습니다.

1. 패스키 등록 / 생성
2. 패스키로 인증 / 로그인

이 두 작업은 교차 출처 iframe에서 동등하게 지원되지 않았고 지금도 그렇습니다.

처음에는 교차 출처 iframe을 통한 로그인은 가능해졌지만, 사용 사례가 없었기 때문에 교차 출처 생성은 아직 불가능했습니다.

최근의 발전(예: Chrome 123)으로 특정 조건 하에서 교차 출처 iframe 패스키 생성이 지원되기 시작했습니다. 그러나 2024년 5월 현재, 모든 브라우저가 교차 출처 iframe을 통한 패스키 생성을 완전히 지원하는 것은 아니지만, 대부분의 브라우저에서 로그인은 가능합니다.

또한, 교차 출처 iframe 지원(등록 및 인증 작업용)은 이미 진행 중인 WebAuthn Level 3 사양에 통합되어 있습니다. 일부 브라우저(예: Safari)는 아직 이 사양을 따라잡아야 합니다. 안타깝게도 Apple은 Safari 내에서 패스키의 교차 출처 등록을 허용할지, 그리고 언제 허용할지에 대해 아직 발표하지 않았습니다. 이것이 허용된다면 교차 출처 iframe에서 패스키를 사용하는 데 있어 가장 큰 기술적 제한이 해소될 것입니다.

블로그 게시물의 다음 부분에서는 교차 출처 iframe을 사용한다고 가정합니다.

Want to find out how many people use passkeys?

View Adoption Data

다음 표는 교차 출처 iframe 컨텍스트에서 iframe 인증 및 패스키를 통한 iframe 로그인에 대한 브라우저/표준 지원 개요를 제공합니다.

2024년 5월 현재, 교차 출처 iframe에서의 패스키 생성은 아직 모든 브라우저에서 가능하지 않습니다. 다음 표는 교차 출처 iframe에서 패스키 등록/생성에 대한 브라우저/표준 지원 개요를 제공합니다.

이러한 개발 및 지원에 대한 더 자세한 배경 정보에 관심이 있다면, 이 GitHub 이슈와 이 Pull Request를 살펴보는 것을 추천합니다.

교차 출처 iframe에서 패스키를 지원하는 데에는 두 가지 주요 사용 사례가 있습니다.

교차 출처 iframe에서 패스키를 활성화하는 것은 여러 도메인이 관련되어 있지만 동일한 사용자 계정을 사용해야 하는 연합 ID 시나리오에 매우 중요합니다.

다음과 같은 시나리오를 생각해 봅시다. 당신이 KAYAK과 같은 다국적 기업이고 지역별로 다른 도메인을 가지고 있다고 가정해 보겠습니다.

• www.kayak.com
• www.kayak.us
• www.kayak.de

하지만 사용자가 이 모든 도메인에서 동일한 계정과 자격 증명으로 로그인할 수 있도록 하는 중앙 집중식 ID 관리 시스템이 있습니다. WebAuthn 표준은 패스키가 하나의 도메인(Relying Party ID), 예를 들어 www.kayak.com에만 바인딩될 수 있기 때문에 이러한 시나리오에 어려움을 줄 수 있습니다.

이 문제를 극복하기 위해, 다른 모든 도메인에서 www.kayak.com 출처의 iframe을 사용할 수 있습니다. 즉, www.kayak.us와 www.kayak.de에 www.kayak.com 출처의 iframe을 삽입하는 것입니다(교차 출처 iframe). 그렇지 않으면, 패스키의 피싱 저항성 때문에 이 다른 도메인들에서 "www.kayak.com"에 바인딩된 패스키를 사용할 수 없게 됩니다.

참고로, 새로운 WebAuthn 기능인 Related Origin Requests (RoR)도 대안으로 사용될 수 있습니다. 이 기능은 "관련된 출처"가 iframe 없이 패스키에 접근할 수 있게 해주지만, 아직 모든 브라우저에서 지원되지는 않습니다.

원활한 결제 흐름에서도 교차 출처 iframe에서의 패스키 사용은 중요한 역할을 합니다. 다음 시나리오를 고려해 보세요: 고객이 판매자의 웹사이트(예: www.amazon.com)에서 새 신발을 구매하려고 합니다. 이 판매자의 웹사이트는 고객이 은행 계좌(예: www.revolut.com)를 통해 결제할 수 있도록 하며, 이를 위해 사용자가 은행 웹사이트에 로그인하도록 요구합니다(이는 단순화된 과정입니다). 사용자는 은행의 Relying Party ID(예: "revolut.com")에 바인딩된 패스키로 은행 웹사이트에 로그인합니다.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

결제 과정에서 사용자를 판매자의 웹사이트(www.amazon.com)에서 은행 웹사이트(www.revolut.com)로 리디렉션하고 거기서 은행 계정에 로그인하게 하는 것을 피하기 위해 교차 출처 iframe을 사용할 수 있습니다. 이를 통해 사용자는 www.amazon.com에 머무르면서 www.revolut.com을 위해 생성한 패스키를 교차 출처 iframe에서 인증에 사용합니다.

따라서 결제 흐름에 교차 출처 iframe을 통해 패스키를 통합하면 소비자와 판매자, 은행 간에 안전하고 간소화된 거래를 보장할 수 있습니다.

결제와 패스키의 맥락에서, 보안 결제 확인(SPC) 및 패스키를 사용한 동적 연결에 대한 저희 블로그 게시물도 살펴보는 것을 추천합니다. 또한 아래의 네이티브 앱에서의 제3자 컨텍스트 제한 사항도 꼭 확인하세요.

또한, 패스키를 사용한 교차 출처 결제 흐름에 대한 더 심층적인 정보를 원하시면, 저희의 결제 제공업체 패스키: 제3자 SDK 구축 방법을 참조하세요.

일반적으로 iframe 내에 패스키를 통합하면 주로 UX와 보안을 개선하여 여러 이점을 제공합니다. 이러한 장점들을 자세히 살펴보겠습니다.

향상된 사용자 경험

1. 팝업이나 리디렉션 없음: 사용자는 리디렉션이나 팝업 없이 삽입된 콘텐츠 내에서 직접 인증할 수 있어 더 부드럽고 방해받지 않는 경험을 할 수 있습니다.
2. 사이트 간 일관된 UX: iframe 내에 인증 흐름을 삽입하면 웹사이트의 다른 섹션이나 동일한 인증 서비스를 사용하는 다른 웹사이트에서 일관된 사용자 경험을 보장합니다.

향상된 보안

1. 안전한 거래: 결제와 같은 시나리오에서 iframe 내 패스키는 안전한 삽입된 컨텍스트 내에서 인증이 이루어지도록 하여 거래의 보안을 강화합니다.
2. 다른 웹사이트에서 사용자 계정 사용: 연합 ID 설정에서 교차 출처 iframe의 패스키는 여러 도메인에 걸쳐 안전하고 효율적인 신원 확인을 가능하게 합니다.

iframe에 패스키를 구현하려면 보안과 기능을 보장하기 위한 몇 가지 핵심 단계가 포함됩니다. 개발자를 위한 상세 가이드를 제공합니다. https://cross-origin-iframe.vercel.app/에서 예제 구현도 참조하세요.

HTTP Permissions-Policy 헤더는 문서나 iframe 요소 내에서 특정 브라우저 기능의 사용을 허용하거나 거부하는 데 도움이 됩니다. iframe에서 패스키 로그인을 활성화하려면 publickey-credentials-get 및 publickey-credentials-create 권한 정책을 설정해야 합니다. 이 정책들은 삽입된 콘텐츠가 인증(navigator.credentials.get({publicKey})) 및 패스키 생성(navigator.credentials.create({publicKey}))에 필요한 WebAuthn API 메서드를 호출할 수 있도록 허용합니다.

<iframe src="https://passkeys.eu" allow="publickey-credentials-get; publickey-credentials-create"></iframe>

HTTP Permissions Policy는 이전에 Feature Policy라고 불렸습니다. Feature Policy 하에서는 헤더 출처 목록에 출처를 추가하거나 iframe 태그에 allow 속성을 포함하여 교차 출처 iframe에 기능을 부여할 수 있었습니다. Permissions Policy에서는 교차 출처 프레임을 출처 목록에 추가하려면 해당 출처의 iframe 태그에 allow 속성이 포함되어야 합니다. 응답에 Permissions Policy 헤더가 없으면 출처 목록은 기본적으로 *(모든 출처)가 됩니다. iframe에 allow 속성을 포함하면 해당 기능에 대한 접근이 허용됩니다.

출처 목록에 지정되지 않은 교차 출처 iframe이 allow 속성이 있더라도 기능에 접근하지 못하도록 하려면, 개발자는 응답에 Permissions Policy 헤더를 명시적으로 설정할 수 있습니다.

Chrome 88 이상에서는 Feature Policy를 계속 사용할 수 있지만 Permissions Policy의 별칭으로 작동합니다. 구문 차이 외에 로직은 동일합니다. Permissions Policy와 Feature Policy 헤더가 동시에 사용될 경우, Permissions Policy 헤더가 우선 적용되어 Feature Policy 헤더에 의해 설정된 값을 덮어씁니다. 더 자세한 구현 내용은 Chrome 팀의 이 블로그 게시물을 참조하세요.

iframe의 소스 URL에서 오는 HTTP 응답 헤더에 관련 ´Permissions-Policy`가 포함되어 있는지 확인하세요. 이는 교차 출처 지원에 매우 중요합니다.

Permissions-Policy: publickey-credentials-get=*, publickey-credentials-create=*

더 세분화된 제어를 위해, iframe 콘텐츠를 삽입할 수 있는 특정 출처를 지정할 수 있습니다.

Permissions-Policy: publickey-credentials-get=("https://passkeys.eu"), publickey-credentials-create=("https://passkeys.eu")

iframe 콘텐츠가 패스키 인증을 트리거하기 위해 사용자 작업이 필요하도록 하세요. 이는 iframe 내에서 클릭이나 양식 제출에 대한 이벤트 리스너를 사용하여 수행할 수 있습니다. 이 과정을 일시적 활성화(transient activation)라고도 합니다.

document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](/glossary/publickeycredentialrequestoptions) = { /* Configuration options */ };
 
            const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions});
            // Handle the created credential
        } catch (err) {
            console.error('Error authenticating via passkey:', err);
        }
    });

이 맥락에서, Safari 사용자 제스처 요구 사항에 대한 저희 블로그 게시물도 참조하세요.

다음은 https://cross-origin-iframe.vercel.com에서 호스팅되는 index.html 파일의 전체 샘플 코드 스니펫입니다. 이 파일은 https://passkeys.eu를 통해 패스키를 위한 교차 출처 iframe을 사용합니다.

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta
            http-equiv="Permissions-Policy"
            content="publickey-credentials-get=*; publickey-credentials-create=*"
        />
        <meta
            http-equiv="Content-Security-Policy"
            content="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self'; frame-src https://passkeys.eu;"
        />
 
        <title>Cross-Origin iframe with Passkeys Demo</title>
        <style>
            body {
                font-family: Arial, sans-serif;
                padding: 20px;
                display: flex;
                flex-direction: column;
                justify-content: center;
                align-items: center;
                height: 100vh;
                margin: 0;
            }
 
            h1 {
                width: 100%;
                text-align: center;
            }
 
            .iframe-container {
                width: 80%;
                max-width: 800px;
                height: 80%;
                max-height: 600px;
                border: 1px solid #ccc;
                box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
                margin-top: 20px;
            }
 
            iframe {
                width: 100%;
                height: 100%;
                border: none;
            }
 
            @media (max-width: 768px) {
                h1 {
                    width: 95%;
                }
 
                .iframe-container {
                    width: 95%;
                }
            }
        </style>
    </head>
    <body>
        <h1>Cross-Origin iframe with Passkeys Demo</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

iframe에 패스키를 구현하는 것은 개발자가 원활하고 안전한 사용자 경험을 보장하기 위해 해결해야 할 일련의 과제를 동반할 수 있습니다. 일반적인 문제점과 이를 극복하는 방법을 자세히 살펴보겠습니다.

문제: 권한 정책을 잘못 구성하면 iframe이 WebAuthn API에 접근하지 못할 수 있습니다.

“NotAllowedError - The 'publickey-credentials-create' feature is not enabled in this document. Permissions Policy may be used to delegate Web Authentication capabilities to cross-origin child frames.”

권한 정책을 올바르게 추가하지 않으면 브라우저에서 다음과 같은 오류가 발생합니다.

해결책:

• allow 속성과 HTTP 헤더가 설정되었는지 다시 확인: allow 속성과 HTTP 헤더가 올바르게 설정되었는지 확인하세요. publickey-credentials-get 및 publickey-credentials-create 권한이 iframe 요소와 서버의 HTTP 응답 헤더 모두에 포함되어 있는지 다시 확인하세요.
• 웹 서버 헤더 대신 메타 헤더 사용: 웹 서버에서 헤더를 설정하는 대신 <meta/> 헤더를 사용하여 권한 정책을 정의하세요.
• Permissions-Policy에서 쉼표 대신 세미콜론 사용: 이전에 Permissions-Policy는 Feature-Policy라고 불렸습니다. Feature-Policy의 단일 요소는 세미콜론(Permissions-Policy의 표준) 대신 쉼표로 구분되었습니다. iframe Permissions-Policy는 여전히 Feature-Policy의 구문을 따르므로 쉼표를 사용합니다. 그러나 sandbox / allow 속성은 여전히 세미콜론으로 구분됩니다(위 코드 스니펫 참조).

팁: Permission-Policy 헤더가 올바르게 설정되었는지 제대로 테스트하려면 브라우저의 개발자 도구를 열고 Application(여기서는 Chrome 개발자 도구)에 접근한 다음 Frames로 이동하여 iframe의 출처(여기서는 passkeys.eu/)를 검색하는 것이 좋습니다. Permissions-Policy가 올바르게 설정되었다면, publickey-credential-create와 publickey-credential-get이 허용된 기능(Allowed Features) 목록에 표시되어야 합니다.

문제: 교차 출처 iframe 패스키 생성 또는 패스키 로그인이 작동하지 않고 브라우저 콘솔에 다음 오류가 표시됩니다.

"NotAllowedError - The origin of the document is not the same as its ancestors."

이 오류는 Safari 브라우저를 사용하고 iframe 내에서 패스키를 생성하려고 할 때 나타납니다. Safari는 교차 출처 iframe 패스키 생성을 지원하지 않기 때문입니다(위 참조).

해결책: Safari는 아직 교차 출처 iframe 내에서의 패스키 생성을 지원하지 않으므로 여기서는 실제로 할 수 있는 일이 없습니다.

Blocked a frame with origin "https://passkeys.eu" from accessing a frame with origin "https://cross-origin-iframe.vercel.app". Protocols, domains, and ports must match.

이 오류는 패스키와 직접적으로 관련이 있기보다는 Safari의 교차 출처 iframe과 일반적으로 관련이 있습니다. Safari / WebKit의 제3자 쿠키 차단 이니셔티브의 일환으로, 제3자 컨텍스트에서 LocalStorage에 접근하거나 JavaScript 로직의 일부가 깨질 수 있습니다.

해결책: 여기서는 iframe 내에서 제3자 쿠키를 사용하지 않도록 해야 합니다. 이것이 오류를 유발하기 때문입니다.

문제: iframe 브라우저 호환성 문제는 다른 브라우저가 WebAuthn, iframe 권한 및 보안 속성에 대한 지원 수준이 달라 일관되지 않은 동작을 유발할 때 발생합니다.

해결책: 이러한 iframe 브라우저 호환성 문제를 완화하려면 여러 브라우저에서 구현을 테스트하여 호환성을 확인하고 브라우저별 문제를 식별해야 합니다.

단계:

1. BrowserStack 또는 Sauce Labs와 같은 도구를 사용하여 교차 브라우저 테스트를 수행합니다.
2. 브라우저별 수정 또는 대체 방안을 구현하여 불일치를 해결합니다.

문제: 네이티브 앱 내에서 패스키가 필요한 iframe을 사용할 때, **자사(first-party)**와 제3자(third-party) 컨텍스트를 명확히 구분해야 합니다.

• 자사 컨텍스트: 패스키가 앱을 운영하는 회사와 동일한 도메인에 연결됩니다. 예를 들어, 자체 도메인에 의존하여 사용자 인증을 하는 전자상거래 앱입니다.
• 제3자 컨텍스트: 다른 도메인(예: 결제 제공업체 또는 ID 제공업체)이 패스키 생성 또는 로그인 흐름을 처리합니다.

iOS의 WKWebView나 Android WebView와 같은 **임베디드 WebView(EWV)**에서는 호출하는 앱이 웹 세션을 광범위하게 제어할 수 있습니다(예: 요청 가로채기). 이 설정은 일반적으로 패스키의 도메인(Relying Party ID)이 앱의 도메인(자사)과 일치하는 경우에만 패스키를 지원합니다. 그러나 결제 제공업체의 교차 출처 흐름과 같은 제3자 시나리오에서는 임베디드 WebView가 일반적으로 필요한 패스키 자격 증명에 접근할 수 없습니다. 판매자의 앱과 결제 제공업체의 서비스가 다른 출처이기 때문입니다. 패스키에 필요한 "바인딩"(도메인, 자격 증명, 출처 간)이 임베디드 컨텍스트에서 일치하지 않습니다.

이러한 제한으로 인해 많은 앱이 시스템 WebView 접근 방식(예: iOS의 ASWebAuthenticationSession 또는 Android의 Custom Tabs)을 채택하게 됩니다. 시스템 WebView는 제3자 사이트(예: 결제 제공업체)를 안전한 브라우저와 유사한 환경에 격리하여 브라우저 자체가 지원하는 경우 교차 출처 패스키를 올바르게 허용합니다. 그럼에도 불구하고, Safari의 기존 iframe 제한은 ASWebAuthenticationSession에도 적용되므로, Safari가 제3자 iframe에서 특정 패스키 작업을 허용하지 않으면 시스템 WebView에서도 마찬가지일 것이라는 점을 기억해야 합니다. 현재로서는 "네이티브" 해결책이 없습니다. 외부 결제 제공업체를 포함하는 복잡한 흐름의 경우, 가장 좋은 방법은 임베디드 WebView 대신 시스템 WebView를 여는 것입니다.

해결책: 결제 제공업체(및 도메인 간 패스키에 의존하는 다른 제3자)의 경우, 사용자가 임베디드 WebView에서 나와 시스템 WebView로 이동하도록 통합을 신중하게 계획해야 합니다. 순수하게 임베디드된 흐름보다 덜 원활한 경험이지만, 제3자 서비스에서 패스키 기능이 작동하도록 보장하는 유일한 방법인 경우가 많습니다.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

네이티브 앱 및 WebView 내에서 제3자 패스키를 처리하는 방법에 대한 자세한 내용은 결제 제공업체 패스키: 제3자 패스키 결제 SDK를 확인하세요.

위에서 논의된 주제들은 다양한 시나리오에 적용되지만, 특히 결제 제공업체에게 중요합니다. 결제 제공업체의 경우, 다중 도메인 흐름(예: 판매자 사이트와 결제 게이트웨이)이 교차 출처 iframe 내에 사용자 인증을 삽입해야 하기 때문입니다. 이러한 설정에서는:

• 사용자는 리디렉션 팝업 없이 마찰 없는 페이지 내 결제를 원합니다.
• 결제 제공업체는 판매자의 사이트에 삽입되어 있더라도 자체 도메인(예: pay.provider.com)에서 패스키 등록 또는 로그인을 처리해야 합니다.
• Safari 제약 조건 및 임베디드 WebView 제한으로 인해 iframe에서 제3자 패스키 생성이 차단되는 경우가 많습니다.

이러한 문제를 해결하고 Apple Pay와 유사한 안전하고 원활한 경험을 구축하기 위해 결제 제공업체는 종종 하이브리드 접근 방식을 채택합니다. 즉, iframe 기반 통합과 Safari(또는 구형 브라우저)를 위한 리디렉션 대체 방안을 결합하는 것입니다. 경우에 따라 임베디드 WebView가 패스키를 전혀 허용하지 않으면 시스템 브라우저 흐름(예: iOS의 ASWebAuthenticationSession)이 필수가 됩니다.

이러한 결제 관련 시나리오에 대한 심층 분석—iframe 대 리디렉션 비교, 네이티브 앱 고려 사항 및 높은 패스키 채택률을 위한 모범 사례 포함—을 원하시면 저희의 전용 기사를 참조하세요:

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

특히 다음을 참조하세요:

• 전략 A: 교차 출처 iframe 삽입은 여기서 소개된 Permissions-Policy 설정을 참조하여 인라인으로 패스키 생성 및 로그인을 처리하는 방법을 설명합니다.
• 전략 B: 리디렉션 기반 접근 방식은 대부분의 교차 출처 함정을 우회하는 더 간단한 통합을 보여주지만, 판매자의 도메인을 떠나는 단점이 있습니다.
• 시스템 WebView는 임베디드 WebView가 제3자 패스키 흐름을 자주 중단시키기 때문에 네이티브 앱에 필수적입니다.

이 보완 가이드는 거래를 보호하고, Safari의 교차 출처 제한을 극복하며, 제3자 컨텍스트에서 패스키 사용을 최적화하기 위한 심층적인 전략을 제공합니다. 이 기사의 기술적 단계와 결제 중심의 방법을 결합하면, iframe 내에서 직접 마찰 없고 피싱에 강한 결제 흐름을 제공하여 온라인 결제의 보안과 UX를 한 단계 끌어올릴 수 있습니다.

iframe 내에 패스키를 통합하면 보안과 사용자 경험을 모두 향상시켜 사용자 인증을 크게 개선합니다. 이를 통해 리디렉션이나 팝업 없이 원활한 인증이 가능해져 다양한 섹션과 사이트에서 일관된 UX를 보장합니다.

Shopify가 로그인 구성 요소 내에 패스키를 통합한 것과 같은 실제 구현 사례는 이 접근 방식의 실용적인 이점과 유연성을 보여줍니다.