Trang này được dịch bởi Cloud Translation API.

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.

Mã này được chỉ định trong mã nhận dạng bên tin cậy (mã RP). Mã này có thể là www.example.com hoặc example.com cho khoá truy cập được tạo cho miền 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:

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 nhiều miền dành riêng cho quốc gia (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 mà một thương hiệu sử dụng (ví dụ: acme.com và acmerewards.com).
Ứng dụng di động: Ứng dụng di động thường không có miền riêng, khiến việc quản lý thông tin đăng nhập trở nên khó khăn.

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

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 giúp người dùng có thể 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 liên quan đến nguồn gốc, bạn cần phân phát một tệp JSON đặc biệt tại một URL cụ thể https://{RP ID}/.well-known/webauthn. Nếu example.com muốn cho phép các nguồn gốc bổ sung sử dụng mã nhận dạng này làm mã nhận dạng RP, thì mã nhận dạng này sẽ phân phát tệp sau tại https://example.com/.well-known/webauthn:

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

Lần tiếp theo, nếu bất kỳ trang web nào trong số này thực hiện lệnh gọi để tạo khoá truy cập (navigator.credentials.create) hoặc xác thực (navigator.credentials.get) sử dụng example.com làm mã nhận dạng RP, thì trình duyệt sẽ nhận thấy mã nhận dạng RP không khớp với nguồn yêu cầu. Nếu trình duyệt hỗ trợ Yêu cầu gốc có liên quan, trước tiên, trình duyệt sẽ tì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 nguồn gốc đưa ra yêu cầu có nằm trong danh sách cho phép trong tệp đó 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: Được 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ách thiết lập Yêu cầu liên quan đến nguồn gốc

Bản minh hoạ sau đây sử dụng ví dụ về hai trang web, 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ạ

https://ror-2.glitch.me triển khai Yêu cầu 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 (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 khoá truy cập hoặc yêu cầu 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ã nhận dạng RP là yếu tố 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 xác thực được tạo trên bất kỳ trang web nào trong số này sẽ có mã nhận dạng RP là ror-1.

Chrome tự động điền trên cả hai trang web. — Nhờ Yêu cầu về nguồn gốc có liên quan, 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 xác thực.

Xem mã:

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

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 một cơ sở dữ liệu tài khoản được chia sẻ trên 2 trang web này.

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

Trước tiên, hãy định cấu hình site-1.com để cho phép site-2.com sử dụng mã này làm mã nhận dạng RP. Để 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 khoá có tên là nguồn gốc, giá trị là một mảng gồm một hoặc nhiều chuỗi chứa nguồn gốc web.

Hạn chế 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 eTLD + 1 nhãn. Ví dụ: nhãn eTLD + 1 của example.co.uk và example.de đều là example. Nhưng nhãn eTLD + 1 của example-rewards.com là example-rewards. Trong Chrome, số lượng nhãn tối đa là 5.

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.

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 express res.json, đã đặt đúng content-type ('application/json');

Bước 4: Chỉ định mã nhận dạng 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 RP trong quá trình tạo thông tin xác thực options được truyền đến lệnh gọi giao diện người dùng navigator.credentials.create 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 khi bạn chạy quy trình xác minh thông tin xác thực trước khi lưu vào cơ sở dữ liệu.
Sau khi xác thực:
- Đặt site-1.com làm mã nhận dạng RP trong options xác thực đượ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.

Khắc phục sự cố

Thông báo lỗi bật lên trong Chrome. — Thông báo lỗi trong Chrome khi tạo thông tin xác thực. 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`.

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 liên quan đến nguồn gốc cho phép người dùng sử dụng lại khoá truy cập trên nhiều trang web. Để cho phép người dùng sử dụng lại khoá truy cập trên một trang web và một ứ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 bài viết 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 liên quan đến nguồn gốc cho phép người dùng sử dụng lại khoá truy cập trên các trang web. Các giải pháp chia sẻ mật khẩu trên các trang web sẽ khác nhau tuỳ theo trình quản lý mật khẩu. Đố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 nằm ngoài phạm vi của bạn với tư cách là nhà phát triển trang web, nhưng xin lưu ý rằng về lâu dài, mã nhận dạng RP không được là một khái niệm mà người dùng nhìn thấy 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 đ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. 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.