Thông tin cập nhật của FedCM: Ngắt kết nối API và 2 bản cập nhật

Eiji Kitamura

Từ Chrome 122, Ngắt kết nối API dành cho Thông tin đăng nhập liên kết API Quản lý (FedCM) đã được cung cấp. Chiến lược phát hành đĩa đơn Ngắt kết nối API cho phép các bên phụ thuộc ngắt kết nối người dùng của họ khỏi của nhà cung cấp danh tính mà không cần dựa vào cookie của bên thứ ba. Ngoài ra, có là một số thông tin cập nhật về cách xử lý cùng một trang web của FedCM.

Huỷ kết nối API

Khi người dùng tạo tài khoản trên một bên đáng tin cậy (RP—trang web sử dụng nhà cung cấp danh tính để xác thực) thông qua liên kết nhận dạng, thông tin nhận dạng nhà cung cấp (IdP) – dịch vụ cung cấp thông tin xác thực và thông tin tài khoản cho các bên khác) thường ghi lại kết nối trên máy chủ của công ty. Thông tin được lưu trữ kết nối cho phép IdP theo dõi các bên bị hạn chế mà người dùng đã đăng nhập và tối ưu hoá trải nghiệm của họ. Ví dụ: để có trải nghiệm tốt hơn khi người dùng quay lại RP sau đó, tài khoản người dùng có IdP sẽ được coi là một tài khoản trả lại, cho phép các tính năng như tự động xác thực lại và các nút được cá nhân hoá hiển thị tài khoản được sử dụng.

Đôi khi, các IdP cung cấp một API để ngắt kết nối tài khoản đó khỏi một bên bị hạn chế. Tuy nhiên, một quy trình ngắt kết nối đã được xác thực và cần có cookie của IdP. Trong một thế giới không có cookie của bên thứ ba, nên khi người dùng truy cập vào bên bị hạn chế, sẽ không có trình duyệt nào API dành cho RP để ngắt kết nối khỏi IdP. Vì có thể có nhiều IdP (nhà cung cấp danh tính) các tài khoản thuộc cùng một IdP (nhà cung cấp danh tính) được liên kết với một bên bị hạn chế cụ thể, quy trình huỷ kết nối cần biết tài khoản nào đang bị ngắt kết nối.

Ngắt kết nối API cũng cho phép người dùng ngắt kết nối tài khoản IdP khỏi RP trên trình duyệt như trên máy chủ IdP bằng cách báo hiệu cho điểm cuối được chỉ định. Người dùng cần đã được liên kết danh tính bằng Thông tin đăng nhập liên kết API Quản lý (FedCM). Sau khi bị ngắt kết nối, người dùng được coi là người dùng mới người dùng vào lần tiếp theo họ cố đăng nhập vào RP bằng IdP.

Ngắt kết nối IdP khỏi RP

Nếu trước đó, một người dùng đã đăng nhập vào bên bị hạn chế bằng IdP (nhà cung cấp danh tính) thông qua FedCM, mối quan hệ được trình duyệt ghi nhớ cục bộ dưới dạng danh sách tài khoản. RP có thể bắt đầu ngắt kết nối bằng cách gọi lệnh Hàm IdentityCredential.disconnect(). Hàm này có thể được gọi từ một khung RP cấp cao nhất. RP cần truyền configURL, clientId mà nó sử dụng trong IdP (nhà cung cấp danh tính) và một accountHint để ngắt kết nối với IdP. Tài khoản gợi ý có thể là một chuỗi tuỳ ý, miễn là điểm cuối ngắt kết nối có thể xác định tài khoản, ví dụ: địa chỉ email hoặc mã nhận dạng người dùng mà không nhất thiết khớp với mã tài khoản mà điểm cuối của danh sách tài khoản đã cung cấp:

// Disconnect an IdP account "account456" from the RP "https://idp.com/". This is invoked on the RP domain.
IdentityCredential.disconnect({
  configURL: "https://idp.com/config.json",
  clientId: "rp123",
  accountHint: "account456"
});

IdentityCredential.disconnect() trả về Promise. Lời hứa này có thể mang đến ngoại lệ vì những lý do sau:

  • Người dùng chưa đăng nhập vào bên bị hạn chế bằng IdP (nhà cung cấp danh tính) qua FedCM.
  • API được gọi từ bên trong iframe mà không có chính sách về quyền FedCM.
  • configURL không hợp lệ hoặc thiếu điểm cuối ngắt kết nối.
  • Không kiểm tra được Chính sách bảo mật nội dung (CSP).
  • Có một yêu cầu ngắt kết nối đang chờ xử lý.
  • Người dùng đã tắt FedCM trong phần cài đặt của trình duyệt.

Khi điểm cuối ngắt kết nối của IdP trả về một thì RP và IdP sẽ bị ngắt kết nối trên của bạn và lời hứa sẽ được giải quyết. Tài khoản người dùng bị ngắt kết nối được chỉ định trong phản hồi từ ngắt kết nối điểm cuối.

Thiết lập tệp cấu hình IdP (nhà cung cấp danh tính)

Để hỗ trợ API Ngắt kết nối, IdP phải hỗ trợ việc ngắt kết nối điểm cuối và cung cấp thuộc tính disconnect_endpoint cũng như đường dẫn của thuộc tính đó trong IdP config.

{
  "accounts_endpoint": "/accounts",
  "id_assertion_endpoint": "/assertion",
  ...
  "disconnect_endpoint: "/disconnect"
}

Ngắt kết nối tài khoản trên điểm cuối ngắt kết nối

Khi gọi IdentityCredential.disconnect(), trình duyệt sẽ gửi một nguồn gốc khác Yêu cầu POST có cookie và loại nội dung application/x-www-form-urlencoded đến điểm cuối ngắt kết nối này bằng các thông tin sau:

Thuộc tính Mô tả
account_hint Gợi ý cho tài khoản IdP.
client_id Giá trị nhận dạng ứng dụng khách của bên bị hạn chế. 
POST /disconnect HTTP/1.1
Host: idp.example
Origin: rp.example
Content-Type: application/x-www-form-urlencoded
Cookie: 0x123
Sec-Fetch-Dest: webidentity

account_hint=account456&client_id=rp123

Sau khi nhận yêu cầu, máy chủ IdP cần:

  1. Phản hồi yêu cầu bằng CORS (Tài nguyên trên nhiều nguồn gốc) Chia sẻ).
  2. Xác minh rằng yêu cầu có chứa tiêu đề HTTP Sec-Fetch-Dest: webidentity.
  3. So khớp tiêu đề Origin với nguồn gốc RP do client_id xác định. Từ chối nếu chúng không khớp.
  4. Tìm tài khoản khớp với account_hint.
  5. Huỷ kết nối tài khoản người dùng khỏi danh sách tài khoản được kết nối của bên bị hạn chế.
  6. Phản hồi trình duyệt bằng account_id của người dùng đã xác định trong tệp JSON .

Ví dụ về tải trọng JSON phản hồi sẽ có dạng như sau:

{
  "account_id": "account456"
}

Nếu IdP muốn trình duyệt ngắt kết nối tất cả tài khoản đã liên kết với RP, truyền một chuỗi không khớp với bất kỳ mã tài khoản nào, ví dụ: "*".

Giờ đây, quá trình kiểm tra /.well-known/web-identity sẽ bị bỏ qua khi RP và IdP ở cùng một trang web

Khi phát triển một hệ thống FedCM, việc kiểm thử hoặc thử nghiệm các miền máy chủ RP có thể là miền con của máy chủ IdP chính thức. Ví dụ: máy chủ nhà cung cấp danh tính (IdP) chính thức nằm tại idp.example, đồng thời cả máy chủ RP thử nghiệm lẫn máy chủ IdP thử nghiệm đang ở staging.idp.example. Tuy nhiên, vì tệp phổ biến phải được đặt eTLD+1 của máy chủ IdP phải ở gốc idp.example/.well-known/web-identity và đó là máy chủ sản xuất. Từ nhà phát triển không nhất thiết phải đặt tệp vào phiên bản chính thức môi trường trong khi phát triển, điều này khiến họ không thể thử nghiệm FedCM.

Kể từ Chrome 122, nếu miền RP và miền IdP giống nhau, thì Chrome bỏ qua việc kiểm tra tệp phổ biến. Bằng cách này, nhà phát triển sẽ có thể thử nghiệm một tình huống như vậy.

Các nguồn phụ hiện có thể đặt trạng thái đăng nhập trên cùng một trang web

Trước đây, Chrome chỉ cho phép cài đặt thông tin đăng nhập trạng thái (cho ví dụ: sử dụng tiêu đề Set-Login: logged-in) khi yêu cầu là cùng nguồn gốc với tất cả các đối tượng cấp trên. Điều này ngăn việc đăng nhập thông qua cùng một trang web fetch() yêu cầu đặt trạng thái đăng nhập.

Ví dụ: hãy nghĩ về một trang web cho phép người dùng nhập tên người dùng và mật khẩu trên idp.example, nhưng thông tin đăng nhập được đăng lên login.idp.example cùng với fetch(). Ghi lại trạng thái đăng nhập vào trình duyệt theo Trạng thái đăng nhập Không thực hiện được API vì 2 miền này có nhiều nguồn gốc và cùng một trang web.

Với thay đổi này, chúng tôi đã nới lỏng yêu cầu API Trạng thái đăng nhập cùng một trang web với tất cả các đối tượng cấp trên và làm cho ví dụ trên có thể thiết lập Trạng thái đăng nhập của login.idp.example bằng cách sử dụng tiêu đề HTTP (Set-Login: logged-in).

Tóm tắt

Bằng cách sử dụng API Ngắt kết nối, FedCM hiện có thể ngắt kết nối RP khỏi IdP (nhà cung cấp danh tính) mà không cần dựa vào cookie của bên thứ ba. Để thực hiện việc này, hãy gọi IdentityCredential.disconnect() trên bên bị hạn chế. Với chức năng này, trình duyệt gửi yêu cầu đến điểm cuối ngắt kết nối của IdP để IdP có thể chấm dứt kết nối trên máy chủ rồi trên trình duyệt.

Chúng tôi đã thông báo rằng bước kiểm tra /.well-known/web-identity sẽ bị bỏ qua khi RP và IdP là cùng một trang web, nhằm mục đích kiểm thử. Ngoài ra, đặt thông tin đăng nhập trạng thái thông qua tiêu đề phản hồi HTTP từ tài nguyên phụ của IdP cùng trang web hiện là nhất có thể.