Quản lý khoá truy cập trên nhiều miền và ứng dụng bằng RP ID

Eiji Kitamura

Trong WebAuthn và khoá truy cập, mã nhận dạng bên tin cậy (RP ID) chỉ định phạm vi của thông tin đăng nhập theo tên miền. Khi bạn tạo khoá truy cập, trình duyệt sẽ liên kết khoá đó với một RP ID cụ thể. Sau đó, trình duyệt sẽ ngăn việc sử dụng khoá truy cập đó trên một miền không khớp hoặc nằm ngoài phạm vi của mã nhận dạng đó. Việc xác định RP ID một cách chính xác sẽ đảm bảo trải nghiệm liền mạch với khoá truy cập trên các miền phụ, nguồn gốc trên nhiều trang web và ứng dụng di động của bên thứ nhất.

Thông tin cơ bản về mã nhận dạng bên bị hạn chế

Mã nhận dạng Bên tin cậy (RP ID) là một chuỗi duy nhất giúp xác định dịch vụ hoặc trang web của bạn. Mã nhận dạng RP phải là một chuỗi miền. Đó có thể là tên máy chủ lưu trữ hiện tại chính xác hoặc một miền mẹ rộng hơn, miễn là đó là eTLD+1 trở lên. Bạn không thể sử dụng địa chỉ IP và Hậu tố công khai (eTLD) làm mã nhận dạng RP.

Ví dụ: nếu lưu trữ máy chủ tại https://www.example.com, bạn có thể dùng example.com hoặc www.example.com làm RP ID, tuỳ thuộc vào nhu cầu cụ thể. Bảng sau đây cho thấy ví dụ về các mã nhận dạng tài nguyên có thể chấp nhận được, tuỳ thuộc vào máy chủ lưu trữ nguồn của bạn:

Trình duyệt sẽ liên kết khoá truy cập với RP ID bằng phương pháp mã hoá khi bạn tạo khoá truy cập. Để sử dụng thông tin đăng nhập, nguồn gốc của yêu cầu xác thực phải khớp với RP ID đó.

Khi bạn sử dụng eTLD+1 làm mã nhận dạng RP, khoá truy cập sẽ hoạt động trên các miền con có liên quan. Ví dụ: mã nhận dạng RP example.com hoạt động cho https://login.example.com và https://shop.example.com. Một RP ID cụ thể hơn như login.example.com hoạt động trên nguồn gốc chính xác của nó nhưng không hoạt động trên https://shop.example.com.

Mã nhận dạng bên bị hạn chế trong các bối cảnh trên nhiều trang web

Nếu dịch vụ của bạn trải rộng trên nhiều eTLD+1 (ví dụ: example.com và example.co.jp), thì đó là cấu hình trên nhiều trang web. Mã nhận dạng bên bị hạn chế tiêu chuẩn không hỗ trợ chế độ thiết lập trên nhiều trang web.

Để chia sẻ khoá truy cập giữa các trang web riêng biệt, hãy sử dụng Yêu cầu về nguồn gốc có liên quan (ROR). ROR cho phép bạn chia sẻ khoá truy cập giữa các trang web riêng biệt vì ứng dụng (trình duyệt) nhận ra các nguồn gốc khác nhau là một phần của cùng một dịch vụ logic.

Yêu cầu đối với ROR:

• Chọn một mã RP: Bạn phải chọn một mã RP và sử dụng mã đó trên tất cả các trang web.
• Lưu trữ tệp cấu hình: Miền mã nhận dạng RP chính phải lưu trữ một tệp cấu hình tại /.well-known/webauthn liệt kê các nguồn được uỷ quyền.
• Duy trì tính nhất quán: Ngay cả khi người dùng đang sử dụng https://www.example.co.jp, rpId trong lệnh gọi WebAuthn phải là lệnh gọi chính (ví dụ: example.com) cả khi tạo và xác thực.

Ví dụ về ROR cho mã nhận dạng bên bị hạn chế example.com: https://example.com/.well-known/webauthn

{
  "origins": [
    "https://www.example.co.jp",
    "https://shop.example"
  ]
}

Để biết thêm thông tin về các chi tiết triển khai Related Origin Requests, hãy xem bài viết Cho phép sử dụng lại khoá truy cập trên các trang web của bạn bằng Related Origin Requests

Mã bên bị hạn chế trên ứng dụng di động

Các ứng dụng di động có thể sử dụng khoá truy cập bằng cách liên kết với một miền trên web. Bạn phải lưu trữ một tệp xác minh trên máy chủ của mình để thiết lập mối quan hệ này.

Android: Digital Asset Links

Credential Manager (Trình quản lý thông tin xác thực) của Android yêu cầu một tệp Digital Asset Link (DAL) trên miền mã nhận dạng RP để liên kết với ứng dụng.

• Lưu trữ: Lưu trữ tệp tại https://<RP ID>/.well-known/assetlinks.json.
• Xác minh: Xác minh origin trong clientDataJSON. Đối với Android, đây là một chuỗi như android:apk-key-hash:<hash>.

Ví dụ về DAL cho RP ID example.com (được lưu trữ tại https://example.com/.well-known/assetlinks.json)

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.google.credentialmanager.sample",
      "sha256_cert_fingerprints": [
        "4F:20:47:1F:D9:9A:BA:96:47:8D:59:27:C2:C8:A6:EA:8E:D2:8D:14:C0:B6:A2:39:99:9F:A3:4D:47:3D:FA:11"
      ]
    }
  }
]

Để biết thêm thông tin, hãy xem phần Định cấu hình Digital Asset Links giữa ứng dụng và trang web

iOS: Miền được liên kết

Các nền tảng của Apple yêu cầu một tệp apple-app-site-association (AASA) trên miền RP ID để liên kết với ứng dụng.

• Tệp AASA: Máy chủ lưu trữ https://<RP_ID>/.well-known/apple-app-site-association.
• Quyền: Thêm webcredentials:<app info> vào quyền dùng ứng dụng.

Ví dụ về AASA cho mã nhận dạng bên bị hạn chế example.com: https://example.com/.well-known/apple-app-site-association:

{
  "webcredentials":
    {
      "apps": ["EXAMPLE123.com.example.passkey"]
    }
}

Để biết thêm thông tin, hãy xem bài viết Kết nối với một dịch vụ bằng khoá truy cập trong Tài liệu dành cho nhà phát triển của Apple.

Tóm tắt

RP ID xác định nơi người dùng truy cập vào khoá truy cập của họ. Hãy lưu ý những điểm sau khi triển khai:

• Hệ thống phân cấp và miền con: Mã nhận dạng RP phải là một chuỗi miền (eTLD+1 trở lên). Việc sử dụng một miền rộng hơn như example.com cho phép khoá truy cập hoạt động trên tất cả các miền con (ví dụ: login.example.com và shop.example.com).
• Giải pháp trên nhiều trang web: Sử dụng Yêu cầu về nguồn gốc có liên quan (ROR) cho các dịch vụ trải rộng trên nhiều eTLD+1. Việc này yêu cầu một mã nhận dạng RP và một tệp cấu hình tại /.well-known/webauthn.
• Tích hợp với thiết bị di động: Thiết lập mối quan hệ đã xác minh giữa trang web và ứng dụng di động bằng cách sử dụng tệp Digital Asset Links (DAL) tại /.well-known/assetlinks.json cho Android và tệp apple-app-site-association (AASA) tại /.well-known/apple-app-site-association cho iOS.

Tìm hiểu thêm

• Luôn nắm bắt thông tin mới nhất về các thông báo dành cho nhà phát triển Chrome
• Bắt đầu từ đây để tìm hiểu về các giải pháp nhận dạng có trên Chrome