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
Maud Nalpas

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.comexample.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.comacmerewards.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í.

Bản minh hoạ sau đây sử dụng ví dụ về 2 trang web là 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 đó, 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-1ror-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-1ror-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-1ror-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.
Nhờ các Yêu cầu 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 đă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ủa mình 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.

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.ukexample.de đều là example. Tuy nhiên, 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 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ự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 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.

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ẽ xảy ra nếu không tìm thấy tệp.well-known/webauthn " của bạn 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 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ứng dụng di động, hãy sử dụng các kỹ thuật sau:

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.