Passkeys & iframe: Cách Tạo & Đăng nhập bằng Passkey?

Chú thích
✅ = được hỗ trợ ❌ = không được hỗ trợ

Tuần này qua tuần khác, ngày càng có nhiều tổ chức công bố việc triển khai passkey của họ (ví dụ gần đây là Visa, Mastercard hay Vercel). Khi các nhà phát triển và quản lý sản phẩm từ các công ty khác học hỏi theo những tấm gương này, ngày càng có nhiều trường hợp sử dụng triển khai passkey được thảo luận.

Một trường hợp mà chúng tôi thường xuyên được hỏi là cách passkey hoạt động trong iframe, vì iframe được sử dụng rộng rãi trong phát triển web hiện đại để nhúng nội dung từ các nguồn khác nhau một cách liền mạch. Trong bối cảnh của passkey và WebAuthn, iframe đi kèm với những thách thức riêng, đặc biệt là liên quan đến bảo mật và tương tác người dùng.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Bài viết blog này cung cấp một hướng dẫn toàn diện về việc sử dụng passkey và WebAuthn trong iframe. Chúng ta sẽ

• Khám phá các khả năng hiện tại
• Thảo luận về hỗ trợ iframe liên nguồn gốc
• Nêu bật những lợi ích của việc tích hợp iframe và
• Cung cấp hướng dẫn triển khai từng bước

Sau khi đọc xong bài viết này, chúng ta sẽ hiểu rõ cách tận dụng passkey trong iframe.

iframe, hay inline frame, là các phần tử HTML cho phép nhà phát triển nhúng một tài liệu HTML khác vào trong tài liệu hiện tại. Khả năng này được sử dụng rộng rãi để tích hợp nội dung từ các nguồn bên ngoài, chẳng hạn như video, bản đồ và các trang web khác, vào một trang web.

Hãy cùng xem qua các loại iframe khác nhau.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

iframe cơ bản là loại được sử dụng phổ biến nhất. Nó chỉ đơn giản là nhúng nội dung từ một URL khác vào trang hiện tại.

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

iframe cơ bản này thường được sử dụng để bao gồm nội dung tĩnh, như một bài báo, trong một trang web.

iframe đáp ứng được thiết kế để điều chỉnh kích thước của chúng dựa trên kích thước màn hình hoặc vùng chứa mà chúng được đặt vào. Điều này đảm bảo rằng nội dung được nhúng trông đẹp trên mọi thiết bị, bao gồm máy tính để bàn, máy tính bảng và điện thoại di động.

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

Các truy vấn media CSS cũng có thể được sử dụng để làm cho iframe điều chỉnh động dựa trên kích thước của khung nhìn.

Get a free passkey assessment in 15 minutes.

Book free consultation

Một iframe bảo mật hoặc được sandbox hạn chế các hành động có thể được thực hiện trong iframe. Điều này hữu ích để nhúng nội dung từ các nguồn không đáng tin cậy hoặc để tăng cường bảo mật.

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

Thuộc tính sandbox có thể bao gồm nhiều hạn chế khác nhau, chẳng hạn như:

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

Thuộc tính sandbox cho phép các tập lệnh chạy nhưng hạn chế các hành động có khả năng nguy hiểm, như gửi biểu mẫu hoặc sử dụng plugin.

Become part of our Passkeys Community for updates & support.

Join

iframe liên nguồn gốc nhúng nội dung từ một tên miền khác. Chúng thường được sử dụng để tích hợp các dịch vụ của bên thứ ba, chẳng hạn như cổng thanh toán hoặc các widget mạng xã hội. Do các hạn chế về bảo mật, các iframe này có quyền truy cập hạn chế vào nội dung của trang nhúng và ngược lại.

Liên nguồn gốc có nghĩa là nội dung đang được tải đến từ một nguồn gốc khác, trong đó nguồn gốc được định nghĩa bởi sự kết hợp của scheme (giao thức), host (tên miền) và số cổng. Ví dụ, https://example.com và http://example.com được coi là các nguồn gốc khác nhau vì chúng sử dụng các scheme khác nhau (HTTP so với HTTPS).

Tương tự, các tên miền phụ được coi là các nguồn gốc riêng biệt so với tên miền mẹ của chúng. Ví dụ, https://example.com và https://sub.example.com là liên nguồn gốc, mặc dù chúng có cùng tên miền cơ sở. Sự tách biệt này đảm bảo rằng các tập lệnh và dữ liệu từ một tên miền phụ không thể tương tác trực tiếp với những thứ từ một tên miền phụ khác mà không có sự cho phép rõ ràng, giúp tăng cường bảo mật.

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.

Các doanh nghiệp tin tưởng Corbado để bảo vệ người dùng của họ và làm cho việc đăng nhập liền mạch hơn với passkey. Nhận tư vấn passkey miễn phí của bạn ngay bây giờ.

Nhận tư vấn miễn phí

Dưới đây là các ví dụ để minh họa các khái niệm về liên nguồn gốc và cùng nguồn gốc:

Ví dụ liên nguồn gốc:

Nhúng nội dung từ https://payment.example.com vào một trang web được lưu trữ trên https://www.mystore.com. Đây là liên nguồn gốc vì chúng có các tên miền khác nhau.

Ví dụ cùng nguồn gốc:

Nhúng nội dung từ https://www.example.com/shop vào một trang web được lưu trữ trên https://www.example.com/blog. Đây là cùng nguồn gốc vì chúng có cùng scheme, host và cổng.

iframe liên nguồn gốc khác với iframe cơ bản ở chỗ nguồn đến từ một tên miền khác, trong khi iframe cùng trang có nguồn từ cùng một tên miền nơi nó được nhúng.

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

Sử dụng passkey trong iframe giới thiệu các khả năng và ràng buộc mới mà các nhà phát triển cần hiểu, chủ yếu xoay quanh việc thiết lập các quyền chính xác và đảm bảo các tương tác người dùng an toàn trong bối cảnh được nhúng.

Trước đây, Web Authentication API bị vô hiệu hóa mặc định trong các iframe liên nguồn gốc, chủ yếu do lo ngại về bảo mật. Hạn chế này có nghĩa là các nhà phát triển phải chuyển hướng người dùng hoặc sử dụng cửa sổ bật lên để xác thực, dẫn đến trải nghiệm người dùng kém liền mạch hơn.

Trong passkey / WebAuthn, có hai hoạt động cốt lõi (còn gọi là nghi thức):

1. Đăng ký / tạo một passkey
2. Xác thực / đăng nhập bằng passkey

Hai hoạt động này đã và đang không được hỗ trợ như nhau trong các iframe liên nguồn gốc:

Ban đầu, việc đăng nhập qua iframe liên nguồn gốc đã được thực hiện nhưng việc tạo mới liên nguồn gốc thì chưa vì không có ai có trường hợp sử dụng.

Những tiến bộ gần đây (ví dụ trong Chrome 123) đã giới thiệu hỗ trợ cho việc tạo passkey trong iframe liên nguồn gốc dưới các điều kiện cụ thể. Tuy nhiên, tính đến tháng 5 năm 2024, không phải tất cả các trình duyệt đều hỗ trợ đầy đủ việc tạo passkey qua iframe liên nguồn gốc, mặc dù việc đăng nhập là có thể với hầu hết các trình duyệt.

Hơn nữa, hỗ trợ iframe liên nguồn gốc (cho các hoạt động đăng ký và xác thực) đã được tích hợp vào đặc tả WebAuthn Cấp 3 đang được tiến hành. Một số trình duyệt vẫn cần bắt kịp với đặc tả (ví dụ: Safari). Thật không may, Apple vẫn chưa công bố liệu họ có cho phép đăng ký passkey liên nguồn gốc trong Safari hay không và khi nào. Điều này sẽ gỡ bỏ hạn chế kỹ thuật quan trọng nhất đối với việc sử dụng passkey trong iframe liên nguồn gốc.

Trong các phần tiếp theo của bài viết blog, chúng ta giả định việc sử dụng các iframe liên nguồn gốc.

Want to find out how many people use passkeys?

View Adoption Data

Các bảng sau đây cung cấp một cái nhìn tổng quan về sự hỗ trợ của trình duyệt/tiêu chuẩn cho xác thực iframe và đăng nhập iframe qua passkey trong bối cảnh iframe liên nguồn gốc:

Tính đến tháng 5 năm 2024, việc tạo một passkey trong một iframe liên nguồn gốc vẫn chưa thể thực hiện được trên tất cả các trình duyệt. Bảng sau đây cung cấp một cái nhìn tổng quan về sự hỗ trợ của trình duyệt / tiêu chuẩn cho việc đăng ký / tạo passkey trong iframe liên nguồn gốc:

Nếu bạn quan tâm đến thông tin nền tảng hơn về sự phát triển và hỗ trợ này, chúng tôi khuyên bạn nên xem vấn đề GitHub này và Pull Request này.

Có hai trường hợp sử dụng chính để hỗ trợ passkey trong iframe liên nguồn gốc.

Việc kích hoạt passkey trong iframe liên nguồn gốc là rất quan trọng đối với các kịch bản danh tính liên kết, nơi có nhiều tên miền liên quan nhưng nên sử dụng cùng một tài khoản người dùng.

Hãy xem xét kịch bản sau. Bạn là một công ty đa quốc gia như KAYAK và có các tên miền khác nhau cho các khu vực khác nhau:

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

Tuy nhiên, bạn có một hệ thống quản lý danh tính trung tâm cho phép người dùng đăng nhập bằng cùng một tài khoản và thông tin xác thực trên tất cả các tên miền này. Tiêu chuẩn WebAuthn sẽ đặt ra một thách thức cho các kịch bản này, vì passkey chỉ có thể được liên kết với một tên miền duy nhất (Relying Party ID), ví dụ: www.kayak.com.

Để vượt qua thách thức này, bạn sẽ sử dụng một iframe từ nguồn www.kayak.com trên tất cả các tên miền khác của mình. Vì vậy, bạn nhúng một iframe có nguồn www.kayak.com trên www.kayak.us và trên www.kayak.de (iframe liên nguồn gốc). Nếu không, việc sử dụng các passkey được liên kết với “www.kayak.com” của bạn trên các tên miền khác này sẽ không thể thực hiện được do tính năng chống lừa đảo (phishing-resistance) của passkey.

Ngoài lề: Tính năng mới của WebAuthn là Related Origin Requests (RoR) cũng có thể được sử dụng thay thế. Tính năng này cho phép các “nguồn gốc liên quan” truy cập passkey mà không cần iframe, nhưng chưa được hỗ trợ trên tất cả các trình duyệt.

Đối với các luồng thanh toán liền mạch, việc sử dụng passkey trong iframe liên nguồn gốc cũng đóng một vai trò quan trọng. Hãy xem xét kịch bản sau: Một khách hàng muốn mua giày mới trên trang web của một nhà bán lẻ (ví dụ: www.amazon.com). Trang web của nhà bán lẻ này cho phép khách hàng thanh toán qua tài khoản ngân hàng (ví dụ: tại www.revolut.com) và do đó yêu cầu người dùng đăng nhập vào trang web của ngân hàng (đây là một quy trình được đơn giản hóa). Người dùng đăng nhập vào trang web của ngân hàng bằng một passkey được liên kết với Relying Party ID của ngân hàng, ví dụ: “revolut.com”.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Để tránh chuyển hướng người dùng từ trang web của nhà bán lẻ (www.amazon.com) đến trang web của ngân hàng (www.revolut.com) trong quá trình thanh toán và để người dùng đăng nhập vào tài khoản ngân hàng ở đó, có thể sử dụng một iframe liên nguồn gốc. Bằng cách này, người dùng vẫn ở trên www.amazon.com và sử dụng passkey trong iframe liên nguồn gốc để xác thực mà họ đã tạo cho www.revolut.com.

Do đó, việc tích hợp passkey qua iframe liên nguồn gốc trong các luồng thanh toán đảm bảo các giao dịch an toàn và hợp lý hóa trên các người tiêu dùng, nhà bán lẻ và ngân hàng:

Trong bối cảnh thanh toán và passkey, chúng tôi cũng khuyên bạn nên xem bài viết blog của chúng tôi về Xác nhận thanh toán an toàn (SPC) và liên kết động với passkey. Hãy chắc chắn cũng xem xét các hạn chế đối với bối cảnh bên thứ ba trong Ứng dụng gốc bên dưới.

Ngoài ra, để có cái nhìn sâu hơn về các luồng thanh toán liên nguồn gốc sử dụng passkey, hãy xem Passkey cho nhà cung cấp thanh toán: Cách xây dựng SDK của bên thứ 3.

Nói chung, việc tích hợp passkey trong iframe mang lại một số lợi ích, chủ yếu bằng cách cải thiện UX và bảo mật. Dưới đây là phân tích chi tiết về những lợi thế này:

Nâng cao trải nghiệm người dùng

1. Không có cửa sổ bật lên hoặc chuyển hướng: Người dùng có thể xác thực trực tiếp trong nội dung được nhúng mà không cần chuyển hướng hoặc cửa sổ bật lên, mang lại trải nghiệm mượt mà và ít gián đoạn hơn.
2. UX nhất quán trên các trang web: Việc nhúng các luồng xác thực trong iframe đảm bảo một trải nghiệm người dùng nhất quán trên các phần khác nhau của một trang web hoặc trên các trang web khác nhau sử dụng cùng một dịch vụ xác thực.

Cải thiện bảo mật

1. Giao dịch an toàn: Đối với các kịch bản như thanh toán, passkey trong iframe tăng cường bảo mật của các giao dịch bằng cách đảm bảo rằng việc xác thực diễn ra trong một bối cảnh được nhúng, an toàn.
2. Sử dụng tài khoản người dùng trên các trang web khác nhau: Trong các thiết lập danh tính liên kết, passkey trong iframe liên nguồn gốc cho phép xác minh danh tính an toàn và hiệu quả trên nhiều tên miền.

Việc triển khai passkey trong iframe bao gồm một số bước chính để đảm bảo tính bảo mật và chức năng. Chúng tôi cung cấp một hướng dẫn chi tiết cho các nhà phát triển. Vui lòng xem thêm ví dụ triển khai tại https://cross-origin-iframe.vercel.app/.

Tiêu đề HTTP Permissions-Policy giúp cho phép hoặc từ chối việc sử dụng các tính năng trình duyệt nhất định trong một tài liệu hoặc trong một phần tử iframe. Để kích hoạt đăng nhập bằng passkey trong iframe, bạn phải đặt publickey-credentials-get và publickey-credentials-create chính sách quyền (permission policies). Các chính sách này cho phép nội dung được nhúng gọi phương thức WebAuthn API cần thiết để xác thực (navigator.credentials.get({publicKey})) và tạo một passkey (navigator.credentials.create({publicKey})).

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

Permissions Policy HTTP trước đây được gọi là Feature Policy. Dưới Feature Policy, bạn có thể cấp một tính năng cho một iframe liên nguồn gốc bằng cách thêm nguồn gốc vào danh sách nguồn gốc của tiêu đề hoặc bao gồm một thuộc tính allow trong thẻ iframe. Với Permissions Policy, việc thêm một khung liên nguồn gốc vào danh sách nguồn gốc yêu cầu thẻ iframe cho nguồn gốc đó phải bao gồm thuộc tính allow. Nếu phản hồi thiếu một tiêu đề Permissions Policy, danh sách nguồn gốc mặc định là * (tất cả các nguồn gốc). Việc bao gồm thuộc tính allow trong iframe cấp quyền truy cập vào tính năng.

Để đảm bảo rằng các iframe liên nguồn gốc không được chỉ định trong danh sách nguồn gốc bị chặn truy cập vào tính năng, ngay cả khi thuộc tính allow có mặt, các nhà phát triển có thể đặt rõ ràng tiêu đề Permissions Policy trong phản hồi.

Trong Chrome 88+, Feature Policy vẫn có thể được sử dụng nhưng hoạt động như một bí danh cho Permissions Policy. Ngoài sự khác biệt về cú pháp, logic vẫn giữ nguyên. Khi cả hai tiêu đề Permissions Policy và Feature Policy được sử dụng đồng thời, tiêu đề Permissions Policy sẽ được ưu tiên và sẽ ghi đè giá trị được đặt bởi tiêu đề Feature Policy. Vui lòng xem thêm bài viết blog này của nhóm Chrome để biết thêm chi tiết triển khai.

Đảm bảo các tiêu đề phản hồi HTTP từ URL nguồn của iframe bao gồm ´Permissions-Policy` có liên quan. Điều này rất quan trọng để hỗ trợ liên nguồn gốc.

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

Để kiểm soát chi tiết hơn, bạn có thể chỉ định các nguồn gốc cụ thể được phép nhúng nội dung iframe.

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

Đảm bảo rằng nội dung iframe yêu cầu một hành động của người dùng để kích hoạt xác thực bằng passkey. Điều này có thể được thực hiện bằng cách sử dụng các trình lắng nghe sự kiện cho các lần nhấp chuột hoặc gửi biểu mẫu trong iframe. Quá trình này còn được gọi là kích hoạt tạm thời (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);
        }
    });

Trong bối cảnh này, hãy xem thêm bài viết blog của chúng tôi về các yêu cầu cử chỉ người dùng của Safari.

Sau đây, bạn sẽ tìm thấy một đoạn mã mẫu đầy đủ của một tệp index.html được lưu trữ trên https://cross-origin-iframe.vercel.com sử dụng một iframe liên nguồn gốc cho passkey qua https://passkeys.eu.

<!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>

Việc triển khai passkey trong iframe có thể đi kèm với một loạt thách thức mà các nhà phát triển cần giải quyết để đảm bảo trải nghiệm người dùng mượt mà và an toàn. Dưới đây là cái nhìn chi tiết về các thách thức thường gặp và cách khắc phục chúng.

Vấn đề: Cấu hình sai các chính sách quyền có thể ngăn iframe truy cập các API WebAuthn.

“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.”

Nếu bạn không thêm các chính sách quyền một cách chính xác, trình duyệt sẽ báo lỗi sau:

Giải pháp:

• Kiểm tra kỹ xem thuộc tính Allow và tiêu đề HTTP đã được đặt chưa: Đảm bảo rằng thuộc tính allow và các tiêu đề HTTP được đặt chính xác. Kiểm tra kỹ rằng các quyền publickey-credentials-get và publickey-credentials-create được bao gồm trong cả phần tử iframe và tiêu đề phản hồi HTTP của máy chủ.
• Tiêu đề Meta thay vì tiêu đề máy chủ Web: Sử dụng các tiêu đề <meta/> để xác định các chính sách quyền thay vì đặt các tiêu đề trong máy chủ web của bạn.
• Dấu chấm phẩy thay vì dấu phẩy trong Permissions-Policy: Trước đây, Permissions-Policy được gọi là Feature-Policy. Các phần tử đơn của một Feature-Policy được phân tách bằng dấu phẩy thay vì dấu chấm phẩy (đây là tiêu chuẩn cho Permissions-Policy). Permissions-Policy của iframe vẫn tuân theo cú pháp của Feature-Policy và do đó sử dụng dấu phẩy. Các thuộc tính sandbox / allow vẫn được phân tách bằng dấu chấm phẩy (xem đoạn mã ở trên).

Mẹo: Để kiểm tra đúng cách rằng các tiêu đề Permission-Policy của bạn được đặt chính xác, chúng tôi khuyên bạn nên mở công cụ dành cho nhà phát triển của trình duyệt, truy cập Application (ở đây: trong công cụ dành cho nhà phát triển của Chrome), đi đến Frames và tìm kiếm nguồn gốc của iframe (ở đây: passkeys.eu/). Nếu Permissions-Policy được đặt chính xác, publickey-credential-create và publickey-credential-get sẽ được liệt kê trong số các Tính năng được phép (Allowed Features):

Vấn đề: Việc tạo passkey hoặc đăng nhập bằng passkey trong iframe liên nguồn gốc không hoạt động, và bạn thấy lỗi sau trong bảng điều khiển trình duyệt của mình.

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

Lỗi này xuất hiện khi sử dụng trình duyệt Safari và cố gắng tạo một passkey từ bên trong iframe, vì Safari không hỗ trợ tạo passkey trong iframe liên nguồn gốc (xem ở trên).

Giải pháp: Ở đây, bạn không thể thực sự làm gì vì Safari chưa hỗ trợ việc tạo một passkey từ bên trong một iframe liên nguồn gốc (chưa).

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.

Lỗi này không liên quan trực tiếp đến passkey mà liên quan nhiều hơn đến iframe liên nguồn gốc trong Safari nói chung. Là một phần của sáng kiến của Safari / WebKit để chặn cookie của bên thứ ba hoặc truy cập vào LocalStorage trong bối cảnh bên thứ ba, các phần của logic JavaScript có thể bị hỏng.

Giải pháp: Ở đây, bạn cần đảm bảo rằng bạn không sử dụng cookie của bên thứ ba bên trong iframe của mình, vì điều này gây ra lỗi.

Vấn đề: Các vấn đề về tương thích trình duyệt với iframe phát sinh khi các trình duyệt khác nhau có mức độ hỗ trợ khác nhau cho WebAuthn, quyền iframe và các thuộc tính bảo mật, dẫn đến hành vi không nhất quán.

Giải pháp: Để giảm thiểu các vấn đề về tương thích trình duyệt với iframe này, hãy kiểm tra việc triển khai trên nhiều trình duyệt để đảm bảo khả năng tương thích và xác định bất kỳ vấn đề cụ thể nào của trình duyệt.

Các bước:

1. Tiến hành kiểm tra trên nhiều trình duyệt bằng các công cụ như BrowserStack hoặc Sauce Labs.
2. Giải quyết bất kỳ sự khác biệt nào bằng cách triển khai các bản sửa lỗi hoặc phương án dự phòng cụ thể cho trình duyệt.

Vấn đề: Khi sử dụng iframe yêu cầu passkey bên trong các ứng dụng gốc, một sự phân biệt quan trọng phải được thực hiện giữa bối cảnh bên thứ nhất và bên thứ ba:

• Bối cảnh bên thứ nhất: Passkey được gắn với cùng một tên miền với công ty chạy ứng dụng. Ví dụ, một ứng dụng thương mại điện tử dựa vào tên miền của chính nó để xác thực người dùng.
• Bối cảnh bên thứ ba: Một tên miền khác (ví dụ: nhà cung cấp thanh toán hoặc nhà cung cấp danh tính) xử lý luồng tạo passkey hoặc đăng nhập.

Trong một WebView nhúng (EWV) như WKWebView trên iOS hoặc một Android WebView - ứng dụng gọi có quyền kiểm soát rộng rãi đối với phiên web (ví dụ: chặn các yêu cầu). Thiết lập này thường chỉ hỗ trợ passkey nếu tên miền của passkey (Relying Party ID) khớp với tên miền của ứng dụng (bên thứ nhất). Tuy nhiên, trong một kịch bản bên thứ ba - như luồng liên nguồn gốc của nhà cung cấp thanh toán - một WebView nhúng thường không thể truy cập các thông tin xác thực passkey cần thiết vì ứng dụng của nhà bán lẻ và dịch vụ của nhà cung cấp thanh toán là các nguồn gốc khác nhau. Các “liên kết” cần thiết cho passkey (giữa tên miền, thông tin xác thực và nguồn gốc) sẽ không khớp trong bối cảnh nhúng.

Hạn chế này khiến nhiều ứng dụng áp dụng phương pháp WebView hệ thống (ví dụ: ASWebAuthenticationSession trên iOS hoặc Custom Tabs trên Android). WebView hệ thống cô lập trang web của bên thứ ba (ví dụ: nhà cung cấp thanh toán) trong một môi trường an toàn, giống như trình duyệt, cho phép passkey liên nguồn gốc một cách chính xác—nếu bản thân trình duyệt hỗ trợ nó. Tuy nhiên, hãy nhớ rằng các hạn chế iframe hiện có của Safari cũng áp dụng cho ASWebAuthenticationSession, vì vậy nếu Safari không cho phép các hoạt động passkey nhất định trong iframe của bên thứ ba, điều tương tự cũng sẽ đúng trong WebView hệ thống. Hiện tại không có bản sửa lỗi “gốc”; thực tiễn tốt nhất cho các luồng phức tạp - chẳng hạn như thanh toán liên quan đến các nhà cung cấp thanh toán bên ngoài - là mở một WebView hệ thống thay vì một WebView nhúng.

Giải pháp: Đối với các nhà cung cấp thanh toán (và các bên thứ ba khác dựa vào passkey trên các tên miền), hãy lên kế hoạch cẩn thận cho việc tích hợp để đảm bảo người dùng được đưa ra khỏi một WebView nhúng và vào một WebView hệ thống. Mặc dù đó là một trải nghiệm kém liền mạch hơn so với một luồng nhúng hoàn toàn, nhưng đó thường là cách duy nhất để đảm bảo rằng chức năng passkey sẽ hoạt động với các dịch vụ của bên thứ ba.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Để biết thêm chi tiết về việc xử lý passkey của bên thứ ba trong các ứng dụng gốc và WebView, hãy xem Passkey cho nhà cung cấp thanh toán: SDK thanh toán Passkey của bên thứ ba.

Trong khi các chủ đề được thảo luận ở trên áp dụng cho nhiều kịch bản khác nhau, chúng đặc biệt quan trọng đối với các nhà cung cấp thanh toán, nơi các luồng đa tên miền (ví dụ: trang web của nhà bán lẻ và cổng thanh toán) phải nhúng xác thực người dùng trong iframe liên nguồn gốc. Trong các thiết lập này:

• Người dùng muốn một quy trình thanh toán tại chỗ, không rắc rối mà không có cửa sổ bật lên chuyển hướng.
• Các nhà cung cấp thanh toán phải xử lý việc đăng ký hoặc đăng nhập passkey trên tên miền của riêng họ (ví dụ: pay.provider.com), ngay cả khi chúng được nhúng vào trang web của nhà bán lẻ.
• Các ràng buộc của Safari và các hạn chế của WebView nhúng thường chặn việc tạo passkey của bên thứ ba trong iframe.

Để giải quyết những thách thức này và xây dựng một trải nghiệm an toàn, liền mạch tương tự như Apple Pay, các nhà cung cấp thanh toán thường áp dụng một phương pháp kết hợp - kết hợp tích hợp dựa trên iframe với một phương án dự phòng chuyển hướng cho Safari (hoặc các trình duyệt cũ hơn). Trong một số trường hợp, các luồng trình duyệt hệ thống (ví dụ: ASWebAuthenticationSession trên iOS) trở nên bắt buộc nếu một WebView nhúng hoàn toàn không cho phép passkey.

Để có một cái nhìn sâu sắc về các kịch bản cụ thể cho thanh toán này - bao gồm so sánh iframe và chuyển hướng, các cân nhắc về ứng dụng gốc và các thực tiễn tốt nhất để có tỷ lệ áp dụng passkey cao, hãy xem bài viết chuyên dụng của chúng tôi:

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

Get free Whitepaper

Cụ thể:

• Chiến lược A: Nhúng một iframe liên nguồn gốc giải thích cách xử lý việc tạo và đăng nhập passkey nội tuyến, tham chiếu đến các cài đặt Permissions-Policy được giới thiệu ở đây.
• Chiến lược B: Phương pháp dựa trên chuyển hướng cho thấy một tích hợp đơn giản hơn bỏ qua hầu hết các cạm bẫy liên nguồn gốc, mặc dù phải trả giá bằng việc rời khỏi tên miền của nhà bán lẻ.
• WebView hệ thống là cần thiết cho các ứng dụng gốc, vì WebView nhúng thường xuyên làm hỏng các luồng passkey của bên thứ ba.

Hướng dẫn bổ sung này cung cấp các chiến lược chuyên sâu để bảo mật các giao dịch, vượt qua các hạn chế liên nguồn gốc của Safari và tối ưu hóa việc sử dụng passkey trong bối cảnh của bên thứ 3. Bằng cách kết hợp các bước kỹ thuật trong bài viết này với các phương pháp tập trung vào thanh toán đó, bạn có thể cung cấp một luồng thanh toán liền mạch, chống lừa đảo (phishing) trực tiếp bên trong một iframe, mở ra cấp độ bảo mật và UX tiếp theo cho thanh toán trực tuyến.

Việc tích hợp passkey trong iframe giúp tăng cường đáng kể xác thực người dùng bằng cách cải thiện cả bảo mật và trải nghiệm người dùng. Điều này cho phép xác thực liền mạch mà không cần chuyển hướng hoặc cửa sổ bật lên, đảm bảo UX nhất quán trên các phần và trang web khác nhau.

Các triển khai trong thế giới thực, chẳng hạn như việc tích hợp passkey của Shopify trong thành phần đăng nhập của họ, chứng minh những lợi ích thực tế và tính linh hoạt của phương pháp này.