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

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á đó được tạo.

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

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

  • Các trang web có nhiều miền: Người dùng không thể dùng cùng một khoá truy cập để đăng nhập trên các miền dành riêng cho từng quốc gia (ví dụ: example.comexample.co.uk) do cùng một công ty quản lý.
  • Miền có thương hiệu: Người dùng không thể dùng cùng một thông tin đăng nhập trên nhiều miền do một thương hiệu sử dụng (ví dụ: acme.comacmerewards.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ác giải pháp thay thế dựa trên liên kết danh tính và các giải pháp khác dựa trên iframe, nhưng chúng gây bất tiện trong một số trường hợp. Yêu cầu nguồn gốc liên quan cung cấp một giải pháp.

Giải pháp

Với Yêu cầu nguồn gốc liên quan, một trang web có thể chỉ định các nguồn gốc được phép sử dụng mã nhận dạng 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 vận hành.

Để sử dụng Yêu cầu nguồn gốc liên quan, 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 nguồn gốc này làm mã nhận dạng RP, thì nguồn gốc đó phải 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 tới, 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, trình duyệt sẽ nhận thấy một mã nhận dạng RP không khớp với nguồn gốc yêu cầu. Nếu trình duyệt hỗ trợ Yêu cầu nguồn gốc liên quan , thì 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 thực hiện yêu cầu có nằm trong allowlist hay không. Nếu có, trình duyệt sẽ tiến hành các bước tạo khoá truy cập hoặc xác thực.

Nếu trình duyệt không hỗ trợ Yêu cầu nguồn gốc liên quan, thì trình duyệt sẽ gửi một SecurityError.

Hỗ trợ trình duyệt

Yêu cầu nguồn gốc liên quan được hỗ trợ trên Chrome và Safari. Tính đến tháng 1 năm 2026, Firefox vẫn đang cân nhắc tính năng này. Bạn có thể theo dõi trạng thái của tính năng này trong vấn đề về vị trí tiêu chuẩn của Mozilla.

Bản minh hoạ sau đây sử dụng 2 trang web: https://ror-1.glitch.mehttps://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 đó, bản minh hoạ này sử dụng Yêu cầu nguồn gố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 liên quan để sử dụng ror-1.glitch.me làm mã nhận dạng RP, vì vậy, cả ror-1ror-2 đều sử dụng ror-1.glitch.me làm mã nhận dạng RP 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 một cơ sở dữ liệu khoá truy cập dùng chung trên các trang web này.

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

  • Bạn có thể tạo khoá truy cập thành công và xác thực bằng khoá truy cập đó trên ror-2, mặc dù mã nhận dạng RP của khoá truy cập đó là ror-1 (và không phải là 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-1ror-2. Vì ror-2 chỉ định ror-1 là mã nhận dạng RP, nên việc thực hiện 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 thực hiện 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-1ror-2.
  • Thông tin đăng nhập đượ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 sẽ tự động điền thông tin trên cả hai trang web.
Nhờ Yêu cầu nguồn gốc liên quan, người dùng có thể sử dụng cùng một thông tin đăng nhập 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ã:

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ó thể đăng nhập bằng cùng một khoá truy cập trên site-1site-2, hãy triển khai 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 sao cho trang web này cho phép site-2.com sử dụng trang web đó làm mã nhận dạng RP. Để 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 khoá có tên là nguồn gốc 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.

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ụ: nhãn eTLD + 1 của example.co.ukexample.de đều là example. Nhưng nhãn eTLD + 1 của example-rewards.comexample-rewards. Trong Chrome, số lượng nhãn tối đa là 5.

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

Sau đó, hãy 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, vốn đã đặt chính xác content-type ('application/json');

Bước 4: Chỉ định mã nhận dạng RP 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 đăng nhập:
    • Đặt site-1.com làm mã nhận dạng RP trong quá trình tạo thông tin đăng nhập 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 đăng nhập trước khi lưu vào cơ sở dữ liệu.
  • Khi xác thực:
    • Đặt site-1.com làm mã nhận dạng RP trong quá 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 được xác minh trên máy chủ khi bạn chạy quy trình xác minh thông tin đăng nhập trước khi xác thực người dùng.

Khắc phục sự cố

Cửa sổ bật lên thông báo lỗi trong Chrome.
Thông báo lỗi trong Chrome khi tạo thông tin đăng nhập. Lỗi này sẽ được gửi nếu không tìm thấy tệp `.well-known/webauthn` tại `https://{RP ID}/.well-known/webauthn`.
Cửa sổ bật lên thông báo lỗi trong Chrome.
Thông báo lỗi trong Chrome khi tạo thông tin đăng nhập. Lỗi này sẽ được gửi nếu tìm thấy tệp `.well-known/webauthn`, nhưng không liệt kê nguồn gốc mà bạn đang cố gắng tạo thông tin đăng nhập.

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 gốc liên quan 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 trang webứng dụng di động, hãy sử dụng các kỹ thuật sau:

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

Yêu cầu nguồn gố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 giải pháp để chia sẻ mật khẩu trên các trang web khác nhau giữa các 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 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 đăng nhập và tác nhân người dùng

Điều 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 hãy 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 đăng nhập mà người dùng đang sử dụng. Thay vào đó, 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 đăng nhập của họ đã được sử dụng. Việc thay đổi này sẽ mất thời gian để triển khai. Một 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.