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 trên 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 bên bị hạn chế (RP) ngăn chặn việc dùng khoá truy cập làm thông tin đăng nhập duy nhất cho xác thực ở mọi nơi, chúng gây ra các vấn đề về:
- 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.
Giải pháp
Bằng Yêu cầu liên quan đến nguồn gốc, một trang web có thể chỉ định những nguồn gốc được phép sử dụng mã RP của trang web đó.
Đ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á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 đó, Gemini sẽ sử dụng Yêu cầu nguồn có liên quan để cho phép ror-2.glitch.me
dùng ror-1.glitch.me
làm mã bên bị hạn chế.
Bản minh hoạ
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ảiror-2
). - Sau khi tạo khoá truy cập trên
ror-1
hoặcror-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ỉ địnhror-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ặcror-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
.
![Chrome sẽ tự động điền trên cả hai trang web.](https://web.developers.google.cn/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=vi)
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.
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ế. Để thực hiện việc nà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 eTLD + 1 nhãn.
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.
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 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
của bạn, hãy đặt site-1.com
làm mã RP ở những nơi cần thiết:
- Sau 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ựcoptions
được truyền đếnnavigator.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.
- Đặt
- 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ựcoptions
được truyền đến lệnh gọi giao diện người dùngnavigator.credentials.get
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 sẽ được xác minh trên máy chủ của bạn khi bạn chạy xác minh thông tin xác thực trước khi xác thực người dùng.
- Đặt
Khắc phục sự cố
![Cửa sổ bật lên thông báo lỗi trong Chrome.](https://web.developers.google.cn/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=vi)
![Cửa sổ bật lên thông báo lỗi trong Chrome.](https://web.developers.google.cn/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=vi)
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: Tài sản kỹ thuật số Đường liên kết. 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 nhiều 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 Digital Asset Links (Đườ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 đó, tác nhân người dùng và thông tin xác thực người quản lý phải cho người dùng biết nơi thông tin đăng nhập 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.