WebAuthn Related Origins: Hướng dẫn sử dụng Passkey trên nhiều tên miền

Passkey là tiêu chuẩn mới cho việc xác thực an toàn và thân thiện với người dùng. Được xây dựng trên các tiêu chuẩn FIDO/WebAuthn, chúng tận dụng mật mã khóa công khai để cung cấp khả năng chống lại lừa đảo giả mạo (phishing) và nhồi thông tin xác thực (credential stuffing), giúp cải thiện đáng kể tình hình bảo mật đồng thời đơn giản hóa trải nghiệm đăng nhập cho người dùng. Đối với các tổ chức, điều này mang lại những lợi ích kinh doanh hữu hình: giảm chi phí vận hành từ việc đặt lại mật khẩu và SMS OTP, giảm thiểu rủi ro tài chính từ gian lận chiếm đoạt tài khoản và tăng doanh thu nhờ tỷ lệ chuyển đổi cao hơn.

Tuy nhiên, một trong những điểm mạnh nhất về bảo mật của WebAuthn - bản chất nghiêm ngặt, gắn liền với nguồn gốc (origin-bound) - lại tạo ra một thách thức thực tế đáng kể cho các thương hiệu toàn cầu và các công ty có sự hiện diện kỹ thuật số đa dạng. Theo thiết kế, một passkey được tạo cho một tên miền web cụ thể sẽ bị khóa bằng mật mã vào tên miền đó, một nguyên tắc cơ bản giúp ngăn chặn các cuộc tấn công lừa đảo. Mặc dù đây là một tính năng bảo mật mạnh mẽ, nó lại dẫn đến trải nghiệm người dùng rời rạc và khó hiểu khi một thương hiệu duy nhất hoạt động trên nhiều tên miền.

Một ví dụ nổi bật cho thách thức này là việc đổi thương hiệu từ Twitter thành X. Một người dùng đã tạo passkey trên twitter.com sẽ thấy nó không thể sử dụng được trên x.com, buộc công ty phải triển khai các biện pháp chuyển hướng phức tạp hoặc yêu cầu người dùng đăng ký lại, tạo ra sự phiền toái cản trở trực tiếp việc áp dụng. Đây không phải là một vấn đề cá biệt. Các doanh nghiệp lớn như Amazon hoạt động trên nhiều tên miền cấp cao nhất theo mã quốc gia (ccTLD) như amazon.com, amazon.de và amazon.co.uk, tất cả đều chia sẻ một hệ thống tài khoản người dùng chung. Trong thế giới trước passkey, các trình quản lý mật khẩu đã xử lý sự phức tạp này một cách khéo léo, nhưng hành vi mặc định của WebAuthn sẽ yêu cầu một passkey riêng cho mỗi tên miền, gây khó chịu cho người dùng và làm suy yếu lời hứa về một lần đăng nhập liền mạch.

Để giải quyết rào cản quan trọng này, W3C đã giới thiệu một tính năng mới trong tiêu chuẩn WebAuthn: Related Origin Requests (ROR). Cơ chế mạnh mẽ này cung cấp một cách thức chuẩn hóa, an toàn để một nhóm các tên miền đáng tin cậy chia sẻ một passkey duy nhất, tạo ra trải nghiệm xác thực thống nhất và liền mạch trên toàn bộ hệ sinh thái kỹ thuật số của một thương hiệu. Bài viết chuyên sâu này khám phá nền tảng kỹ thuật của ROR, cung cấp hướng dẫn thực tế để triển khai và phân tích các tác động chiến lược của nó đối với kiến trúc xác thực hiện đại.

Sự ra đời của ROR đánh dấu một bước trưởng thành quan trọng của tiêu chuẩn WebAuthn. Các thông số kỹ thuật ban đầu ưu tiên việc thiết lập các nguyên tắc mật mã và bảo mật cốt lõi, với việc liên kết chặt chẽ thông tin xác thực với một Relying Party ID (rpID) là nền tảng trong thiết kế chống lừa đảo của nó. Khi các đợt triển khai quy mô lớn tại các doanh nghiệp như Amazon và Google trở thành hiện thực, sự phiền toái thực tế do tính cứng nhắc này gây ra đã trở nên rõ ràng. Sự phiền toái này là một trở ngại trực tiếp để đạt được tỷ lệ chấp nhận cao từ người dùng, vốn là thước đo thành công cuối cùng cho bất kỳ dự án passkey nào. Việc phát triển ROR là một phản ứng trực tiếp đối với phản hồi từ các doanh nghiệp, thể hiện một sự tiến hóa thực tế của tiêu chuẩn. Nó thừa nhận rằng để một giao thức bảo mật đạt được thành công rộng rãi, khả năng sử dụng của nó phải có thể mở rộng để phù hợp với thực tế kinh doanh phức tạp và chiến lược thương hiệu của các tổ chức triển khai nó.

Hướng dẫn toàn diện này trả lời năm câu hỏi quan trọng để triển khai WebAuthn Related Origin Requests:

1. Tại sao passkey không hoạt động trên nhiều tên miền? Hiểu mô hình bảo mật gắn liền với nguồn gốc của WebAuthn và những điểm gây phiền toái trong thực tế.
2. Related Origin Requests hoạt động về mặt kỹ thuật như thế nào? Tìm hiểu sâu về luồng xác thực của trình duyệt và cơ chế URI .well-known.
3. Cần những gì để triển khai ROR? Cấu hình từng bước phía máy chủ và máy khách với các ví dụ mã thực tế.
4. Khi nào nên chọn ROR thay vì đăng nhập liên kết (federated login)? Khung quyết định chiến lược so sánh ROR với các phương pháp tiếp cận OIDC/SAML.
5. Làm thế nào để xử lý các vấn đề về khả năng tương thích của trình duyệt và bảo mật? Ma trận hỗ trợ hiện tại và các phương pháp bảo mật tốt nhất.

Để biết thêm chi tiết kỹ thuật, hãy xem tài liệu giải thích chính thức về WebAuthn Related Origin Requests.

Để đánh giá đầy đủ sự tinh tế của giải pháp Related Origin Requests, điều cần thiết là phải hiểu các khái niệm kỹ thuật cơ bản dẫn đến sự tồn tại của nó: Chính sách Cùng Nguồn gốc (Same-Origin Policy) của web và các quy tắc phạm vi Relying Party ID (rpID) của WebAuthn. Các cơ chế này là nền tảng cho an ninh web nhưng lại tạo ra chính sự phiền toái mà ROR được thiết kế để giảm bớt.

"Nguồn gốc" web (web origin) là một khái niệm bảo mật quan trọng được định nghĩa bởi sự kết hợp duy nhất của giao thức (ví dụ: https), tên miền (ví dụ: app.example.com) và cổng (ví dụ: 443) mà từ đó nội dung được phục vụ. Chính sách Cùng Nguồn gốc là một cơ chế bảo mật được các trình duyệt thực thi nhằm hạn chế cách một kịch bản được tải từ một nguồn gốc có thể tương tác với một tài nguyên từ nguồn gốc khác. Đây là một yếu tố quan trọng của an ninh web, giúp cô lập hiệu quả các tài liệu có khả năng độc hại và ngăn chặn một trang web lừa đảo, ví dụ, đọc dữ liệu nhạy cảm từ phiên webmail đã được xác thực của người dùng trong một tab khác.

Trong hệ sinh thái WebAuthn, "Relying Party" (RP) là trang web hoặc ứng dụng mà người dùng đang cố gắng xác thực. Mỗi passkey đều được liên kết mật mã với một Relying Party ID (rpID) tại thời điểm nó được tạo. rpID là một tên miền xác định phạm vi và ranh giới cho thông tin xác thực đó.

Theo mặc định, rpID là tên miền hiệu lực của nguồn gốc nơi passkey đang được tạo. Các quy tắc phạm vi của WebAuthn cho phép một nguồn gốc đặt rpID bằng với tên miền của chính nó hoặc một hậu tố tên miền có thể đăng ký. Ví dụ, một kịch bản đang chạy trên https://www.accounts.example.co.uk có thể tạo một passkey với rpID là:

• www.accounts.example.co.uk (tên miền đầy đủ)
• accounts.example.co.uk
• example.co.uk

Sự linh hoạt này cho phép một passkey được tạo trên một tên miền phụ có thể được sử dụng trên các tên miền phụ khác của cùng một tên miền cha, đây là một mô hình phổ biến và cần thiết. Tuy nhiên, các quy tắc nghiêm cấm việc đặt một rpID không phải là một hậu tố. Cùng một kịch bản trên www.accounts.example.co.uk sẽ không thể tạo một passkey với rpID là example.com, vì .com là một tên miền cấp cao khác.

Sự liên kết chặt chẽ này phục vụ một mục đích quan trọng: tách biệt thông tin xác thực theo phạm vi tên miền. Một passkey được tạo cho mybank.com không thể được thực thi trên phishing-site.com vì trang web độc hại không thể nhận dạng rpID hợp pháp của mybank.com. Trình duyệt thậm chí sẽ không hiển thị passkey đó như một tùy chọn.

Tuy nhiên, bản thân rpID không phải là biện pháp kiểm soát chống lừa đảo chính. Sự bảo vệ chống lừa đảo của WebAuthn thực sự đến từ việc xác minh nguồn gốc (origin verification) trong đối tượng clientDataJSON. Trong mỗi quy trình WebAuthn, trình duyệt tạo một đối tượng JSON chứa thông tin ngữ cảnh quan trọng, bao gồm nguồn gốc chính xác đã khởi tạo yêu cầu. Toàn bộ đối tượng này sau đó được ký bằng mật mã bởi khóa riêng của bộ xác thực (authenticator). Máy chủ (Relying Party) PHẢI xác minh chữ ký này và, quan trọng hơn, xác thực rằng trường nguồn gốc trong clientDataJSON đã ký khớp với một giá trị đáng tin cậy, được mong đợi. Việc xác minh nguồn gốc này chính là điều ngăn chặn các cuộc tấn công lừa đảo.

Với Related Origin Requests, phạm vi rpID được nới lỏng—cho phép bar.com nhận dạng hợp pháp rpID của foo.com sau khi trình duyệt xác thực tệp .well-known/webauthn—nhưng yêu cầu xác minh nguồn gốc vẫn không thay đổi. clientDataJSON sẽ vẫn báo cáo trung thực nguồn gốc là bar.com. Máy chủ tại foo.com nhận được dữ liệu đã ký này, xác minh nó và thấy rằng yêu cầu đến từ bar.com. Sau đó, máy chủ phải kiểm tra xem bar.com có phải là một nguồn gốc liên quan được mong đợi hay không trước khi chấp nhận xác thực. Điều này thể hiện một phương pháp tiếp cận đa lớp cho phép linh hoạt hơn mà không hy sinh nguyên tắc cốt lõi của việc xác minh nguồn gốc.

Cơ chế Related Origin Requests giới thiệu một cách thức tinh tế và chuẩn hóa để các tên miền công khai tuyên bố mối quan hệ tin cậy nhằm mục đích chia sẻ passkey. Nó tận dụng một mô hình web đã được thiết lập tốt—URI /.well-known/ để tạo ra một "danh sách cho phép" có thể xác minh và máy có thể đọc được mà các trình duyệt có thể tham khảo.

Khái niệm cốt lõi rất đơn giản: một tên miền đóng vai trò là rpID chính, chuẩn cho một tập hợp các trang web liên quan có thể lưu trữ một tệp JSON đặc biệt tại một URL được chuẩn hóa, "well-known": https://{rpID}/.well-known/webauthn. Tệp này hoạt động như một bản kê khai công khai, liệt kê rõ ràng tất cả các nguồn gốc khác được ủy quyền chính thức để tạo và sử dụng passkey dưới rpID chính đó.

Luồng xác thực của trình duyệt được kích hoạt bất cứ khi nào nó gặp phải sự không khớp giữa nguồn gốc hiện tại và rpID được yêu cầu:

1. Một người dùng trên một trang web "liên quan", chẳng hạn như https://example.co.uk, khởi tạo một hoạt động passkey (tạo hoặc xác thực) trong đó mã phía máy khách chỉ định một tên miền khác làm rpID, ví dụ, example.com.
2. Trình duyệt phát hiện sự không khớp này. Theo các quy tắc cũ, điều này sẽ ngay lập tức dẫn đến lỗi SecurityError.
3. Với sự hỗ trợ của ROR, trình duyệt, trước khi thất bại, sẽ thực hiện một yêu cầu HTTPS GET an toàn đến URL well-known của rpID được khai báo: https://example.com/.well-known/webauthn. Yêu cầu này được thực hiện mà không có thông tin xác thực người dùng (như cookie) và không có tiêu đề referrer để bảo vệ quyền riêng tư của người dùng và ngăn chặn theo dõi.
4. Trình duyệt nhận phản hồi JSON từ máy chủ. Nó phân tích tệp và kiểm tra xem nguồn gốc hiện tại (https://example.co.uk) có trong mảng origins bên trong đối tượng JSON hay không.
5. Nếu nguồn gốc được tìm thấy trong danh sách cho phép, hoạt động WebAuthn được phép tiếp tục sử dụng example.com làm rpID hợp lệ. Nếu nguồn gốc không được tìm thấy, hoặc nếu tệp bị thiếu hoặc bị định dạng sai, hoạt động sẽ thất bại như trước đây.

Việc chọn sử dụng URI /.well-known/ là có chủ ý và phù hợp với các tiêu chuẩn web đã được thiết lập để khám phá dịch vụ và xác thực quyền kiểm soát tên miền. Đường dẫn URI này, được định nghĩa bởi RFC 8615, đã được sử dụng bởi nhiều giao thức quan trọng, bao gồm acme-challenge để cấp chứng chỉ SSL Let's Encrypt và assetlinks.json để liên kết các trang web với các ứng dụng Android. Bằng cách áp dụng quy ước này, W3C tận dụng một mô hình vốn đã ngụ ý quyền sở hữu tên miền. Để đặt một tệp tại đường dẫn cụ thể, được chuẩn hóa này, người ta phải có quyền kiểm soát quản trị đối với máy chủ web cho tên miền đó. Điều này cung cấp một bằng chứng kiểm soát đơn giản nhưng hiệu quả, làm cho việc tuyên bố tin cậy có thể xác minh được. Khi chủ sở hữu của example.com cung cấp một tệp liệt kê example.co.uk là một nguồn gốc liên quan, đó là một tuyên bố có thể xác minh. Cách tiếp cận dựa trên web này đơn giản và mạnh mẽ hơn nhiều so với các giải pháp thay thế đã được xem xét và từ chối trong quá trình tiêu chuẩn hóa, chẳng hạn như sử dụng khóa mật mã để ký ủy quyền (RP Keys) hoặc các định danh ngẫu nhiên không dựa trên tên miền (RP UUIDs). ROR đặt nền tảng cho mối quan hệ tin cậy trong mô hình kiểm soát tên miền hiện có và dễ hiểu của web.

Việc triển khai Related Origin Requests đòi hỏi những thay đổi phối hợp cả ở phía máy chủ, để ủy quyền cho các nguồn gốc, và phía máy khách, để gọi rpID được chia sẻ. Phần này cung cấp các chi tiết mã và cấu hình thực tế cần thiết để kích hoạt trải nghiệm passkey thống nhất trên các tên miền của bạn.

Máy chủ lưu trữ rpID chính chịu trách nhiệm xuất bản danh sách cho phép của các nguồn gốc liên quan.

Tệp ủy quyền phải được đặt tại đường dẫn chính xác /.well-known/webauthn so với thư mục gốc của tên miền rpID chính. Điều quan trọng là tệp này phải được phục vụ dưới các điều kiện sau:

• Giao thức: Phải được phục vụ qua HTTPS.
• Content-Type: Tiêu đề phản hồi HTTP Content-Type phải được đặt thành application/json.
• Phần mở rộng tệp: URL không nên bao gồm phần mở rộng .json. Đường dẫn đúng là /webauthn, không phải /webauthn.json.

Tệp phải chứa một đối tượng JSON duy nhất với một khóa, origins, có giá trị là một mảng các chuỗi. Mỗi chuỗi trong mảng là nguồn gốc đầy đủ (giao thức, tên miền và cổng tùy chọn) đang được ủy quyền.

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

Ví dụ: Đối với rpID là example.com, tệp phải được phục vụ tại https://example.com/.well-known/webauthn (lưu ý: không có phần mở rộng .json).

Sau khi máy chủ được cấu hình với tệp .well-known/webauthn, tất cả các tên miền liên quan phải sử dụng cùng một rpID được chia sẻ một cách nhất quán trong các lệnh gọi API WebAuthn của chúng. Sự phối hợp này rất quan trọng để ROR hoạt động chính xác.

Yêu cầu phối hợp chính:

1. Trách nhiệm của Backend: Máy chủ tạo ra thử thách mật mã (cryptographic challenge) và chỉ định rpID được chia sẻ trong cả yêu cầu tạo thông tin xác thực và xác thực.
2. Trách nhiệm của Frontend: Tất cả các ứng dụng máy khách (example.com, example.co.uk, example.de) phải truyền cùng một rpID được chia sẻ đến API navigator.credentials của trình duyệt.
3. Quản lý cấu hình: rpID được chia sẻ phải được coi là một giá trị cấu hình toàn cục quan trọng được áp dụng nhất quán trên tất cả các trang web liên quan.

Một cấu hình sai trên dù chỉ một trang web—nơi nó mặc định sử dụng nguồn gốc của chính nó làm rpID thay vì giá trị được chia sẻ—sẽ phá vỡ trải nghiệm passkey thống nhất cho người dùng trên tên miền đó.

Quan trọng: Máy chủ PHẢI xác minh trường origin trong clientDataJSON cho mọi yêu cầu, đảm bảo nó khớp với một trong những nguồn gốc liên quan đã được ủy quyền. Việc xác minh nguồn gốc này là cơ chế bảo vệ chống lừa đảo chính.

Related Origin Requests (ROR) và các giao thức định danh liên kết (OIDC/SAML) giải quyết các vấn đề khác nhau. ROR không phải là sự thay thế cho Single Sign-On—nó là một sự bổ sung giải quyết một trường hợp sử dụng hẹp cụ thể.

ROR phù hợp cho một ứng dụng logic duy nhất được phân phối trên nhiều tên miền liên quan chia sẻ cùng một cơ sở dữ liệu người dùng:

• Một thương hiệu duy nhất hoạt động trên nhiều TLD mã quốc gia (ví dụ: amazon.com, amazon.de, amazon.co.uk)
• Tất cả các tên miền chia sẻ cùng một hệ thống xác thực backend và cơ sở dữ liệu người dùng
• Bạn muốn tránh các luồng dựa trên chuyển hướng và giữ cho việc xác thực theo ngữ cảnh của từng tên miền
• Các tên miền của bạn nằm trong giới hạn 5 nhãn (5-label limit)
• Người dùng nên trải nghiệm tất cả các tên miền như một dịch vụ gắn kết

ROR cung cấp gì: Cùng một passkey hoạt động trên tất cả các tên miền liên quan, loại bỏ nhu cầu người dùng phải tạo các passkey riêng biệt cho mỗi trang web khu vực.

Sử dụng các giao thức định danh liên kết cho Single Sign-On thực sự trên các ứng dụng riêng biệt:

• Nhiều dịch vụ với cơ sở dữ liệu người dùng hoặc hệ thống định danh riêng biệt
• Các kịch bản doanh nghiệp nơi người dùng cần truy cập vào nhiều ứng dụng khác nhau (Salesforce, Office 365, các công cụ nội bộ)
• Tích hợp ứng dụng của bên thứ ba
• Bạn cần kiểm soát truy cập tập trung, theo dõi kiểm toán và quản trị định danh
• Bạn vượt quá giới hạn 5 nhãn cho các nguồn gốc liên quan

OIDC/SAML cung cấp gì: Xác thực tập trung nơi người dùng đăng nhập một lần tại một Nhà cung cấp Định danh (Identity Provider - IdP) và có quyền truy cập vào nhiều Nhà cung cấp Dịch vụ (Service Providers - SPs) thông qua các token an toàn.

Quan trọng: Passkey có thể được sử dụng với cả hai phương pháp. Bạn có thể triển khai passkey tại một IdP tập trung cho SSO liên kết, hoặc sử dụng ROR cho một ứng dụng duy nhất trên nhiều tên miền. Hãy lựa chọn dựa trên kiến trúc của bạn, không phải phương thức xác thực của bạn.

Trong khi ROR là một giải pháp kỹ thuật mạnh mẽ, việc triển khai nó nên là một quyết định chiến lược có chủ đích. Các kiến trúc sư và quản lý sản phẩm phải cân nhắc lợi ích của nó so với các mô hình thay thế và hiểu rõ những hạn chế của nó để xây dựng một hệ thống xác thực mạnh mẽ và sẵn sàng cho tương lai.

Một hạn chế chính của ROR là "giới hạn nhãn". Một "nhãn" trong bối cảnh này đề cập đến tên miền cấp cao nhất hiệu lực cộng thêm một cấp (eTLD+1), là phần có thể đăng ký của một tên miền. Ví dụ:

• shopping.com, shopping.co.uk, và shopping.ca đều chia sẻ cùng một nhãn duy nhất "shopping"
• myshoppingrewards.com giới thiệu một nhãn mới, riêng biệt: "myshoppingrewards"
• travel.shopping.com vẫn thuộc về nhãn "shopping"

Thông số kỹ thuật WebAuthn Level 3 yêu cầu các trình duyệt triển khai hỗ trợ tối thiểu năm nhãn duy nhất trong danh sách origins. Kể từ năm 2025, không có trình duyệt nào được biết đến hỗ trợ nhiều hơn mức tối thiểu năm nhãn này. Do đó, các tổ chức nên thiết kế các đợt triển khai ROR của mình với giới hạn cứng này—coi năm là mức tối đa hiệu lực.

Giới hạn này là một cơ chế chống lạm dụng có chủ ý được thiết kế để ngăn chặn việc sử dụng sai mục đích. Nó ngăn chặn các thực thể như nhà cung cấp dịch vụ lưu trữ chia sẻ (ví dụ: wordpress.com) tạo ra một passkey phổ quát có thể hoạt động trên hàng nghìn tên miền phụ của khách hàng không liên quan, điều này sẽ làm suy yếu mô hình bảo mật.

Đối với hầu hết các tổ chức, ngay cả các thương hiệu đa quốc gia lớn, giới hạn năm nhãn này là đủ. Ví dụ, các TLD mã quốc gia khác nhau của Amazon (amazon.com, amazon.de, amazon.co.uk, v.v.) đều chia sẻ nhãn "amazon", để lại bốn suất nhãn bổ sung có sẵn cho các thương hiệu khác trong danh mục của họ như "audible" hoặc "zappos".

Sự phức tạp của việc triển khai ROR phụ thuộc nhiều vào việc nó được giới thiệu vào một hệ thống mới hay được trang bị thêm cho một hệ thống hiện có.

• Triển khai mới (Greenfield): Đối với các dự án mới, chiến lược rất đơn giản. Một tên miền duy nhất, chuẩn nên được chọn làm rpID được chia sẻ ngay từ đầu (ví dụ: tên miền .com chính). rpID này sau đó nên được sử dụng nhất quán trong cấu hình của tất cả các trang web và ứng dụng liên quan ngay từ ngày đầu tiên.
• Triển khai hiện có: Việc trang bị thêm ROR cho một hệ thống đã có passkey được triển khai với các rpID khác nhau trên các tên miền của nó phức tạp hơn đáng kể. Việc di chuyển trực tiếp là không thể, vì các passkey hiện có được liên kết vĩnh viễn với rpID ban đầu của chúng. Phương pháp được khuyến nghị trong kịch bản này là triển khai một luồng đăng nhập "ưu tiên định danh" (identifier-first). Người dùng trước tiên được nhắc nhập tên người dùng hoặc email của họ. Backend sau đó thực hiện một tra cứu để xác định rpID nào mà passkey hiện có của họ được liên kết. Cuối cùng, người dùng được chuyển hướng đến nguồn gốc chính xác tương ứng với rpID đó để hoàn thành quy trình xác thực. Sau khi đăng nhập thành công, họ có thể được chuyển hướng trở lại trang web ban đầu của mình. Đây là một công việc kiến trúc đáng kể đòi hỏi phải lập kế hoạch và triển khai cẩn thận.

Hiểu cách các công ty đã thành lập triển khai Related Origin Requests cung cấp những hiểu biết có giá trị cho chiến lược triển khai của riêng bạn. Dưới đây là các ví dụ dựa trên các triển khai thực tế (tính đến tháng 10 năm 2025):

Microsoft sử dụng ROR cho cơ sở hạ tầng xác thực của họ. Cấu hình thực tế tại login.microsoftonline.com bao gồm:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

Cách tiếp cận thận trọng này cho phép chia sẻ passkey giữa các cổng đăng nhập doanh nghiệp và người tiêu dùng của Microsoft trong khi vẫn duy trì một vành đai bảo mật tập trung.

Shopify triển khai ROR để thống nhất việc xác thực trên các tên miền được chọn:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

Cấu hình này cho phép Shopify kết nối nền tảng chính của họ với ứng dụng Shop, thể hiện một cách tiếp cận tập trung vào các nguồn gốc liên quan.

Amazon có một tệp khá lớn:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

Mô hình này sẽ cho phép một thương hiệu cung cấp xác thực passkey thống nhất trên các tên miền khu vực trong khi sử dụng tên miền .com chính làm rpID.

Những ví dụ thực tế này tiết lộ một số mô hình chính:

1. Tên miền chính làm rpID: Tất cả các công ty sử dụng tên miền .com chính của họ làm rpID chuẩn.
2. Phân nhóm logic: Các nguồn gốc được nhóm theo chức năng kinh doanh thay vì kiến trúc kỹ thuật.
3. Phạm vi thận trọng: Hầu hết các triển khai đều nằm dưới giới hạn 5 nhãn, thường sử dụng 3-4 nguồn gốc.
4. Chiến lược tên miền phụ: Nhiều công ty sử dụng các tên miền phụ của tên miền chính để duy trì tính nhất quán của thương hiệu.

Là một tiêu chuẩn web hiện đại, ROR đã được thiết kế với bảo mật là ưu tiên hàng đầu và đang được áp dụng tích cực trên các trình duyệt lớn.

Related Origin Requests không làm ảnh hưởng đến các đảm bảo chống lừa đảo cốt lõi của WebAuthn. Cơ chế này được thiết kế cẩn thận để duy trì một tình hình bảo mật mạnh mẽ:

• Xác minh nguồn gốc: Như đã thảo luận, trình duyệt vẫn bao gồm nguồn gốc thực sự của yêu cầu trong clientDataJSON đã ký. Máy chủ Relying Party PHẢI xác minh nguồn gốc này để đảm bảo yêu cầu đến từ một nguồn mong đợi, ngăn chặn một nguồn gốc liên quan bị xâm phạm mạo danh một nguồn gốc khác.
• Tìm nạp an toàn: Yêu cầu của trình duyệt đến tệp .well-known/webauthn được thực hiện qua HTTPS. Hơn nữa, thông số kỹ thuật yêu cầu rằng việc tìm nạp này phải được thực hiện mà không có thông tin xác thực (ví dụ: cookie) và không có tiêu đề Referer. Điều này ngăn chặn yêu cầu bị sử dụng để rò rỉ thông tin người dùng hoặc cho mục đích theo dõi chéo trang.
• Bảo mật máy chủ: Bản thân tệp .well-known/webauthn trở thành một tài sản bảo mật quan trọng. Một kẻ tấn công giành được quyền kiểm soát máy chủ web lưu trữ rpID chính có thể sửa đổi tệp này để thêm tên miền độc hại của riêng chúng vào danh sách cho phép. Do đó, việc bảo mật cơ sở hạ tầng phục vụ tệp này là vô cùng quan trọng.

Related Origin Requests là một tính năng của thông số kỹ thuật WebAuthn Level 3. Hỗ trợ trên trình duyệt bắt đầu được triển khai vào cuối năm 2024:

Thông tin chính:

• Chrome và Edge: Đã thêm hỗ trợ ROR trong phiên bản 128 (tháng 8 năm 2024)
• Safari: Đã thêm hỗ trợ ROR trong Safari 18, có sẵn trên macOS 15 và iOS 18 (tháng 9 năm 2024)
• Firefox: Hiện không hỗ trợ ROR; cần phát hiện tính năng và triển khai các luồng thay thế

Đối với các ứng dụng cần hỗ trợ các trình duyệt cũ hơn hoặc Firefox, hãy triển khai một chiến lược thay thế:

1. Phát hiện tính năng: Kiểm tra hỗ trợ ROR bằng cách sử dụng PublicKeyCredential.getClientCapabilities()
2. Luồng ưu tiên định danh: Nhắc người dùng nhập tên người dùng/email, tra cứu rpID liên quan của người dùng, sau đó chuyển hướng đến nguồn gốc phù hợp để xác thực.
3. Thoái lui nhẹ nhàng: Cho phép người dùng tạo các passkey riêng biệt cho mỗi tên miền nếu ROR không khả dụng.

Dữ liệu dựa trên ma trận hỗ trợ hiện tại tính đến tháng 10 năm 2025.

Việc triển khai Related Origin Requests đòi hỏi sự phối hợp cẩn thận giữa nhiều đội ngũ kỹ thuật và chuyên môn sâu về các giao thức WebAuthn. Nền tảng áp dụng passkey của Corbado loại bỏ sự phức tạp này bằng cách cung cấp các giải pháp sẵn sàng cho doanh nghiệp để triển khai passkey trên nhiều tên miền.

Corbado xử lý sự phức tạp kỹ thuật của Related Origin Requests thông qua:

• Cấu hình tự động: Nền tảng của chúng tôi tự động tạo và lưu trữ các tệp .well-known/webauthn cần thiết với các tiêu đề bảo mật và định dạng JSON phù hợp.
• Bảng điều khiển đa tên miền: Giao diện quản lý tập trung để cấu hình các nguồn gốc liên quan trên toàn bộ danh mục tên miền của bạn.
• Công cụ xác thực: Các công cụ kiểm tra và xác thực tích hợp để đảm bảo cấu hình ROR của bạn hoạt động chính xác trên tất cả các trình duyệt và nền tảng.

Ngoài việc triển khai kỹ thuật, Corbado cung cấp khuôn khổ bảo mật mà các doanh nghiệp cần:

• Xác minh nguồn gốc: Tự động xác thực các nguồn gốc clientDataJSON để ngăn chặn việc lạm dụng tên miền liên quan.
• Ghi nhật ký kiểm toán: Theo dõi toàn diện việc sử dụng passkey trên tất cả các tên miền liên quan để giám sát tuân thủ và bảo mật.
• Ứng phó sự cố: Cảnh báo thời gian thực và phản ứng tự động đối với các nỗ lực xác thực chéo tên miền đáng ngờ.

Đối với các tổ chức có các đợt triển khai passkey hiện có, Corbado cung cấp:

• Công cụ di chuyển cũ: Phân tích tự động các cấu hình rpID hiện có và đề xuất lộ trình di chuyển.
• Luồng ưu tiên định danh: Các thành phần đăng nhập được xây dựng sẵn để xử lý các kịch bản đa rpID phức tạp trong giai đoạn chuyển tiếp.
• Tích hợp API: Các API RESTful và SDK tích hợp liền mạch với cơ sở hạ tầng xác thực hiện có của bạn.

Sẵn sàng triển khai Related Origin Requests cho tổ chức của bạn? Đội ngũ chuyên gia của Corbado có thể giúp bạn thiết kế và triển khai một trải nghiệm passkey thống nhất trên toàn bộ hệ sinh thái kỹ thuật số của bạn. Liên hệ với đội ngũ giải pháp của chúng tôi để thảo luận về các yêu cầu và thời gian cụ thể của bạn.

Lời hứa của passkey nằm ở khả năng mang lại một tương lai vừa an toàn hơn vừa đơn giản hơn đáng kể cho người dùng. Tuy nhiên, để tương lai này trở thành hiện thực ở quy mô toàn cầu, tiêu chuẩn phải phù hợp với sự phức tạp về kiến trúc của các thương hiệu kỹ thuật số hiện đại. Sự phiền toái do các passkey bị ràng buộc chặt chẽ với tên miền đã là một rào cản đáng kể đối với việc áp dụng cho các tổ chức có sự hiện diện trực tuyến đa dạng.

WebAuthn Related Origin Requests cung cấp giải pháp chuẩn hóa, an toàn và tinh tế cho vấn đề này. Bằng cách cho phép một passkey duy nhất hoạt động liền mạch trên một tập hợp các tên miền liên quan đáng tin cậy, ROR loại bỏ một điểm gây nhầm lẫn và thất vọng lớn cho người dùng.

Hướng dẫn này đã giải quyết năm câu hỏi quan trọng để triển khai WebAuthn Related Origin Requests:

1. Tại sao passkey không hoạt động trên nhiều tên miền? Mô hình bảo mật gắn liền với nguồn gốc của WebAuthn khóa passkey bằng mật mã vào các tên miền cụ thể để ngăn chặn lừa đảo, nhưng điều này tạo ra sự phiền toái khi các thương hiệu hoạt động trên nhiều tên miền như các TLD quốc gia khác nhau.
2. Related Origin Requests hoạt động về mặt kỹ thuật như thế nào? ROR sử dụng một tệp .well-known/webauthn được chuẩn hóa để tạo ra một danh sách cho phép có thể xác minh của các tên miền liên quan, cho phép các trình duyệt xác thực việc sử dụng passkey chéo tên miền thông qua một quy trình tìm nạp HTTPS an toàn.
3. Cần những gì để triển khai ROR? Việc triển khai đòi hỏi cấu hình phía máy chủ của tệp kê khai .well-known/webauthn và sự phối hợp phía máy khách để sử dụng một rpID được chia sẻ một cách nhất quán trên tất cả các nguồn gốc liên quan.
4. Khi nào nên chọn ROR thay vì đăng nhập liên kết? Sử dụng ROR cho các trải nghiệm thương hiệu thống nhất trên các tên miền liên quan với cơ sở dữ liệu người dùng được chia sẻ; sử dụng OIDC/SAML cho SSO thực sự trên các ứng dụng riêng biệt hoặc khi vượt quá giới hạn 5 nhãn.
5. Làm thế nào để xử lý các vấn đề về khả năng tương thích của trình duyệt và bảo mật? ROR được hỗ trợ trong các trình duyệt chính từ Chrome/Firefox 128+, Safari trên macOS 15+ và iOS 18+, với các chiến lược thay thế có sẵn cho các trình duyệt cũ hơn thông qua các luồng ưu tiên định danh.

Đối với các đội ngũ kỹ thuật và các nhà lãnh đạo sản phẩm, những điểm cần thiết là:

• ROR cho phép một trải nghiệm passkey thống nhất cho một ứng dụng logic duy nhất trải rộng trên nhiều tên miền, chẳng hạn như những ứng dụng có các TLD mã quốc gia khác nhau hoặc thương hiệu thay thế.
• Việc triển khai đòi hỏi một nỗ lực phối hợp: một tệp .well-known/webauthn phía máy chủ phải được xuất bản trên tên miền của rpID chính, và tất cả các ứng dụng phía máy khách phải được cấu hình để sử dụng cùng một rpID được chia sẻ đó.
• Quyết định sử dụng ROR là một quyết định chiến lược. Nó là một công cụ tuyệt vời cho các trường hợp sử dụng cụ thể của nó nhưng nên được cân nhắc so với một kiến trúc đăng nhập liên kết truyền thống hơn (OIDC/SAML), đặc biệt là trong các kịch bản liên quan đến Single Sign-On thực sự trên các ứng dụng khác nhau.

Các tính năng như Related Origin Requests rất quan trọng cho sự phát triển không ngừng của phong trào không mật khẩu. Chúng thể hiện cam kết từ các cơ quan tiêu chuẩn trong việc giải quyết các thách thức triển khai trong thế giới thực, đảm bảo rằng lợi ích của passkey—bảo mật vô song và trải nghiệm người dùng dễ dàng—có thể tiếp cận được ngay cả với các tổ chức lớn nhất và phức tạp nhất. Khi tính năng này được hỗ trợ rộng rãi trên các trình duyệt, nó sẽ đóng một vai trò quan trọng trong việc phá vỡ những rào cản cuối cùng để tiến tới một internet không mật khẩu thực sự toàn cầu.