Cho phép sử dụng lại khoá truy cập trên các trang web có Yêu cầu nguồn có liên quan

Maud Nalpas

Giải quyết vấn đề Yêu cầu nguồn có liên quan

Khoá truy cập được liên kết với một trang web cụ thể và chỉ có thể dùng để đăng nhập vào trang web mà khoá truy cập đó được tạo.

Thông tin này được chỉ định trong bên tin cậy Mã nhận dạng (RP ID) mà khoá truy cập được tạo cho miền example.com có thể là www.example.com hoặc example.com.

Mặc dù mã nhận dạng RP ngăn việc sử dụng khoá truy cập làm thông tin xác thực duy nhất để xác thực ở mọi nơi, nhưng mã nhận dạng RP lại gây ra vấn đề cho:

• Các trang web có nhiều miền: Người dùng không thể sử dụng cùng một khoá truy cập để đăng nhập trên các miền khác nhau theo quốc gia cụ thể (ví dụ: example.com và example.co.uk) do cùng một công ty quản lý.
• Miền thương hiệu: Người dùng không thể sử dụng cùng một thông tin xác thực trên các miền khác nhau được một thương hiệu sử dụng (ví dụ: acme.com và acmerewards.com).
• Ứng dụng dành cho thiết bị di động: Các ứng dụng dành cho thiết bị di động thường không có miền riêng, khiến cho quản lý thông tin xác thực.

Có các giải pháp dựa trên liên kết danh tính và các giải pháp khác dựa vào iframe nhưng sẽ gây bất tiện trong một số trường hợp. Ưu đãi trong yêu cầu nguồn có liên quan một giải pháp.

Lưu ý: Mã nhận dạng bên bị hạn chế có thông tin đăng nhập riêng biệt giữa các trang web, nhưng là hành vi lừa đảo thì biện pháp bảo vệ bắt nguồn từ việc xác minh nguồn gốc của trang web trong trường CollectedClientData.

Giải pháp

Với Yêu cầu liên quan đến nguồn gốc, trang web có thể chỉ định các nguồn gốc được phép sử dụng mã nhận dạng yêu cầu nguồn gốc (RP ID).

Điều này cho phép người dùng sử dụng lại cùng một khoá truy cập trên nhiều trang web mà bạn điều hành.

Để sử dụng Yêu cầu nguồn có liên quan, bạn cần phân phát tệp JSON đặc biệt tại URL cụ thể https://{RP ID}/.well-known/webauthn. Nếu example.com muốn cho phép các nguồn gốc khác sử dụng mã này làm mã nhận dạng bên bị hạn chế, thì mã này sẽ phân phát các nội dung sau tệp tại https://example.com/.well-known/webauthn:

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example-rewards.com"
    ]
}

Lần tới, bất kỳ trang web nào trong số này yêu cầu tạo khoá truy cập (navigator.credentials.create) hoặc quy trình xác thực (navigator.credentials.get) sử dụng example.com làm mã nhận dạng bên bị hạn chế, trình duyệt sẽ thấy một mã bên bị hạn chế không khớp với nguồn gốc yêu cầu. Nếu trình duyệt hỗ trợ Nguồn gốc có liên quan Yêu cầu, trước tiên hệ thống sẽ tìm kiếm Tệp webauthn tại https://{RP ID}/.well-known/webauthn. Nếu tệp tồn tại, trình duyệt sẽ kiểm tra xem máy chủ gốc gửi yêu cầu có thuộc danh sách cho phép trong nguồn gốc đó hay không . Nếu có, hệ thống sẽ chuyển sang các bước tạo hoặc xác thực khoá truy cập. Nếu trình duyệt không hỗ trợ Yêu cầu nguồn có liên quan, thì trình duyệt sẽ gửi ra một SecurityError.

Hỗ trợ trình duyệt

• Chrome: Được hỗ trợ kể từ Chrome 128.
• Safari: Hỗ trợ kể từ macOS 15 beta 3 và trên thiết bị di động iOS 18 beta 3.
• Firefox: Đang chờ vị trí.

Cảnh báo: Kể từ tháng 8 năm 2024, Firefox sẽ không hỗ trợ Yêu cầu có liên quan đến nguồn gốc và bạn chưa thể sử dụng getClientCapabilities để phát hiện tính năng bị thiếu và triển khai phương án dự phòng. Nếu bạn triển khai Yêu cầu nguồn có liên quan, người dùng Firefox sẽ không thể tạo khoá truy cập (hoặc đăng nhập bằng khoá truy cập đó) trên các miền có ý định sử dụng một trang web khác làm hệ thống sẽ gửi một mã RP và SecurityError.

Cách thiết lập Yêu cầu nguồn có liên quan

Bản minh hoạ sau đây sử dụng ví dụ về 2 trang web là https://ror-1.glitch.me và https://ror-2.glitch.me.
Để cho phép người dùng đăng nhập bằng cùng một khoá truy cập trên cả hai trang web đó, ứng dụng này sử dụng Yêu cầu gốc có liên quan để cho phép ror-2.glitch.me sử dụng ror-1.glitch.me làm mã nhận dạng RP.

Bản minh hoạ

Lưu ý: Mở bản minh hoạ trong một trong các trình duyệt được hỗ trợ.

https://ror-2.glitch.me triển khai Yêu cầu về nguồn gốc có liên quan để dùng ror-1.glitch.me làm mã nhận dạng bên bị hạn chế. Vì vậy, cả ror-1 và ror-2 đều dùng ror-1.glitch.me làm mã nhận dạng bên bị hạn chế khi tạo khoá truy cập hoặc xác thực bằng khoá truy cập đó.
Chúng tôi cũng đã triển khai cơ sở dữ liệu khoá truy cập dùng chung trên các trang web này.

Quan sát trải nghiệm người dùng sau đây:

• Bạn có thể tạo thành công khoá truy cập và xác thực bằng khoá truy cập đó trên ror-2 – mặc dù mã RP của khoá truy cập là ror-1 (chứ không phải ror-2).
• Sau khi tạo khoá truy cập trên ror-1 hoặc ror-2, bạn có thể xác thực bằng khoá truy cập đó trên cả ror-1 và ror-2. Vì ror-2 chỉ định ror-1 làm mã nhận dạng RP, nên việc tạo yêu cầu tạo khoá truy cập hoặc xác thực từ bất kỳ trang web nào trong số này cũng giống như việc tạo yêu cầu trên ror-1. Mã RP là thứ duy nhất liên kết một yêu cầu với một nguồn gốc.
• Sau khi bạn tạo khoá truy cập trên ror-1 hoặc ror-2, Chrome có thể tự động điền khoá truy cập đó trên cả ror-1 và ror-2.
• Thông tin đăng nhập được tạo trên bất kỳ trang web nào trong số này đều sẽ có mã RP là ror-1.

Nhờ Yêu cầu liên quan đến nguồn gốc, người dùng có thể sử dụng cùng một thông tin xác thực khoá truy cập trên ror-1 và ror-2. Chrome cũng sẽ tự động điền thông tin đăng nhập.

Xem mã:

• Xem tệp ./well-known/webauthn được thiết lập trong cơ sở mã ror-1.
• Xem RP_ID_ROR lần xuất hiện trong cơ sở mã ror-2.

Lưu ý: Trong bản minh hoạ này, để đơn giản, không có quy trình kiểm tra mật khẩu nào thực sự diễn ra. Bản minh hoạ này tập trung vào khoá truy cập.

Bước 1: Triển khai cơ sở dữ liệu tài khoản dùng chung

Nếu bạn muốn người dùng của mình có thể đăng nhập bằng cùng một khoá truy cập trên site-1 và site-2, hãy triển khai cơ sở dữ liệu tài khoản được chia sẻ trên 2 trang web.

Bước 2: Thiết lập tệp JSON .well-known/webauthn trong trang web-1

Trước tiên, hãy định cấu hình site-1.com để cho phép site-2.com sử dụng nó làm Mã nhận dạng bên bị hạn chế. Để làm như vậy, hãy tạo tệp JSON webauthn:

{
    "origins": [
        "https://site-2.com"
    ]
}

Đối tượng JSON phải chứa các nguồn gốc có tên khoá có giá trị là một mảng của một hoặc nhiều chuỗi khác chứa nguồn gốc web.

Giới hạn quan trọng: Tối đa 5 nhãn

Mỗi phần tử của danh sách này sẽ được xử lý để trích xuất nhãn eTLD + 1. Ví dụ: eTLD + 1 nhãn của example.co.uk và example.de đều là example. Tuy nhiên, nhãn eTLD + 1 của example-rewards.com là example-rewards. Trong Chrome, số lượng nhãn tối đa là 5.

Cảnh báo: Nếu danh sách của bạn có quá nhiều nhãn (hơn 5), thì (các) phần tử sẽ bị bỏ qua.

Bước 3: Phân phát JSON .well-known/webauthn của bạn trong site-1

Sau đó, phân phát tệp JSON của bạn trong site-1.com/.well-known/webauthn.

Thận trọng: Tệp phải được phân phát có loại nội dung application/json và chứa danh sách đối tượng JSON duy nhất nguồn gốc được phép. Định dạng chính xác của tệp là: /.well-known/webauthn (không bao gồm đuôi .json).

Ví dụ: trong express:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

Ở đây, chúng ta đang sử dụng res.json nhanh, đã đặt giá trị chính xác content-type ('application/json');

Bước 4: Chỉ định mã RP mong muốn trong site-2

Trong cơ sở mã site-2, hãy đặt site-1.com làm mã nhận dạng RP ở mọi nơi cần thiết:

• Khi tạo thông tin xác thực:
  • Đặt site-1.com làm mã nhận dạng bên bị hạn chế trong phần tạo thông tin xác thực options được truyền đến navigator.credentials.create lệnh gọi giao diện người dùng và thường được tạo phía máy chủ.
  • Đặt site-1.com làm mã nhận dạng bên bị hạn chế dự kiến khi bạn chạy thông tin đăng nhập trước khi lưu vào cơ sở dữ liệu của bạn.
• Sau khi xác thực:
  • Đặt site-1.com làm mã nhận dạng bên bị hạn chế trong quy trình xác thực options được truyền đến lệnh gọi giao diện người dùng navigator.credentials.get và thường được tạo phía máy chủ.
  • Đặt site-1.com làm mã nhận dạng RP dự kiến cần xác minh trên máy chủ, vì bạn chạy quy trình xác minh thông tin xác thực trước khi xác thực người dùng.

Lưu ý: Còn origin thì sao? Còn name RP thì sao? Trong cơ sở mã site-2 của bạn, origin dự kiến sẽ không thay đổi (https://site-2.com), vì phần tử này chỉ định nơi yêu cầu dự kiến sẽ được gửi đến . Theo tên RP (rp.name), tên này không được sử dụng trong thực tế. Bạn có thể để trống trường này.

Khắc phục sự cố

Thông báo lỗi trong Chrome khi tạo thông tin đăng nhập. Lỗi này sẽ xảy ra nếu không tìm thấy tệp `.well-known/webauthn` tại `https://{RP ID}/.well-known/webauthn`.

Thông báo lỗi trong Chrome khi tạo thông tin xác thực. Lỗi này xảy ra nếu hệ thống tìm thấy tệp.well-known/webauthn` của bạn nhưng không liệt kê nguồn mà bạn đang cố gắng tạo thông tin xác thực.

Lưu ý khác

Chia sẻ khoá truy cập trên các trang web và ứng dụng di động

Yêu cầu nguồn có liên quan cho phép người dùng sử dụng lại khoá truy cập trên nhiều . Để cho phép người dùng sử dụng lại khoá truy cập trên một trang web và ứng dụng di động, hãy sử dụng các kỹ thuật sau:

• Trong Chrome: Digital Asset Links (Đường liên kết đến tài sản kỹ thuật số). Tìm hiểu thêm tại Thêm tính năng hỗ trợ cho Digital Asset Links (Đường liên kết đến tài sản kỹ thuật số).
• Trong Safari: Miền được liên kết.

Chia sẻ mật khẩu trên các trang web

Yêu cầu nguồn gốc có liên quan cho phép người dùng sử dụng lại khoá truy cập trên các trang web. Các trình quản lý mật khẩu có những giải pháp để chia sẻ mật khẩu giữa các trang web. Đối với Trình quản lý mật khẩu của Google, hãy sử dụng Đường liên kết đến tài sản kỹ thuật số. Safari có một hệ thống khác.

Vai trò của trình quản lý thông tin xác thực và tác nhân người dùng

Việc này sẽ nằm ngoài phạm vi nhà phát triển trang web của bạn, nhưng xin lưu ý rằng trong khoảng thời gian thì mã RP không được là khái niệm hiển thị cho người dùng trong tác nhân người dùng hoặc trình quản lý thông tin xác thực mà người dùng của bạn đang sử dụng. Thay vào đó, các tác nhân người dùng và trình quản lý thông tin xác thực phải cho người dùng biết nơi thông tin xác thực của họ đã được sử dụng. Sự thay đổi này sẽ mất thời gian để triển khai. Giải pháp tạm thời là hiển thị cả trang web hiện tại và trang web đăng ký ban đầu.