WebAuthn Signal API: Cập nhật & Xóa Passkey phía Client

Hệ sinh thái passkey đang không ngừng phát triển. Để tạo điều kiện cho sự thay đổi, tiêu chuẩn WebAuthn nền tảng cũng phát triển nhanh chóng. Các tính năng mới thường bắt đầu bằng một bản giải thích kỹ thuật trên GitHub và sau đó phát triển thành một pull request vào tiêu chuẩn khi đã được thảo luận đầy đủ. Gần đây, pull request này đã được thêm vào bản nháp tiêu chuẩn với tên gọi WebAuthn Signal API. Trong bài viết này, chúng ta sẽ tìm hiểu về:

• Tại sao WebAuthn Signal API lại cần thiết: WebAuthn Signal API hỗ trợ những trường hợp sử dụng nào?
• WebAuthn Signal API hoạt động như thế nào: WebAuthn Signal API hoạt động chính xác ra sao? Các khuyến nghị cho các bên tin cậy là gì?

Tại thời điểm cập nhật bài viết này vào tháng 1 năm 2025, WebAuthn Signal API được bật mặc định từ Chrome 132 và trước đây được biết đến với tên gọi Reporting API trước khi được đổi tên để tránh xung đột với một API khác cùng tên.

WebAuthn Signal API giải quyết các trường hợp sử dụng cụ thể liên quan đến việc quản lý passkey ở phía client. Cụ thể, nó giúp đồng bộ hóa thông tin giữa bên tin cậy (RP) và các trình xác thực là một phần của hệ điều hành phía client. Các trường hợp sử dụng quan trọng sau đây tồn tại:

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Khi một passkey được tạo, nó bao gồm một số thông tin: user.id, user.name, và user.displayName. Bản thân passkey được xác định thông qua Credential ID duy nhất.

• user.id: là một định danh duy nhất đại diện cho tài khoản mà passkey được liên kết. user.id này rất quan trọng vì nó được sử dụng để khớp passkey với tài khoản của người dùng.
• user.name và user.displayName: đây là các metadata chỉ dùng cho mục đích hiển thị trong giao diện người dùng.

Hình minh họa sau đây cho thấy một cấu trúc cơ sở dữ liệu đơn giản, điển hình giải thích thông tin nào thường được lưu trữ trong trường nào:

Điều quan trọng cần hiểu là trong khi user.name (thường là địa chỉ email) và user.displayName (một tên thân thiện, dễ đọc hơn) giúp người dùng nhận dạng tài khoản của họ trong giao diện lựa chọn, sự liên kết thực sự giữa một passkey và một tài khoản được duy trì thông qua user.id và Credential ID:

• Một tài khoản có thể có nhiều passkey, nhưng mỗi passkey được xác định và khớp với tài khoản một cách duy nhất bằng user.id
• Mỗi passkey tự nó có một Credential ID duy nhất được tạo bởi trình xác thực

Một vấn đề phát sinh khi user.name, có thể là một địa chỉ email, thay đổi. Hiện tại, không có cơ chế nào để cập nhật thay đổi này trực tiếp trên trình xác thực phía client. user.name có thể thay đổi vì nhiều lý do, chẳng hạn như khi người dùng cập nhật địa chỉ email của họ. Mặc dù có sự thay đổi này trong metadata của tài khoản ở phía máy chủ, user.name cũ sẽ tiếp tục xuất hiện trong giao diện lựa chọn thông tin xác thực, điều này có thể gây nhầm lẫn cho người dùng.

Giải pháp tạm thời cho vấn đề này là tạo một passkey mới với user.name đã cập nhật và cùng user.id, sau đó ghi đè lên passkey hiện có. Tuy nhiên, cách tiếp cận này bất tiện vì nhiều lý do:

1. Thừa thãi: Mỗi user.id chỉ có thể có một passkey cho mỗi ID của bên tin cậy, nghĩa là passkey cũ phải được thay thế bằng một passkey mới, đây là một bước thừa.
2. Trải nghiệm người dùng: Người dùng sẽ không hiểu tại sao họ cần tạo một passkey mới. Đó là lý do tại sao giải pháp tạm thời này không được sử dụng rộng rãi.
3. Phức tạp: Việc quản lý tạo passkey và thay thế chỉ để cập nhật metadata là một sự phức tạp không cần thiết.

Địa chỉ email, số điện thoại và các định danh khác có thể thay đổi thường xuyên. Nếu không có phương pháp đơn giản để cập nhật trực tiếp user.name và user.displayName trên trình xác thực, người dùng có thể gặp phải vấn đề dai dẳng là họ nhìn thấy và phải chọn một passkey được liên kết với địa chỉ email cũ của họ. Tình huống này làm suy yếu trải nghiệm liền mạch mà passkey hướng tới. WebAuthn Signal API nhằm giải quyết vấn đề này bằng cách cho phép các bên tin cậy báo cáo các cập nhật cho metadata của passkey mà không yêu cầu tạo mới. Trước khi chúng ta giải thích cách triển khai Signal API, chúng ta sẽ khám phá trường hợp sử dụng quan trọng thứ hai mà nó giải quyết.

Become part of our Passkeys Community for updates & support.

Join

Một trường hợp sử dụng quan trọng khác là xóa passkey trên trình xác thực phía client. Theo thời gian, người dùng có thể thu hồi thông tin xác thực thông qua danh sách quản lý passkey hoặc xóa tài khoản của họ, và việc đảm bảo các thông tin xác thực này được xóa khỏi trình xác thực phía client trở nên cần thiết để chúng không xuất hiện trong các giao diện lựa chọn thông tin xác thực trong tương lai (Conditional UI / tự động điền passkey).

Nhu cầu về chức năng này phát sinh trong một số tình huống:

1. Passkey bị xóa thông qua cài đặt tài khoản: Khi một thông tin xác thực không còn hợp lệ, chẳng hạn như sau khi người dùng đã xóa nó một cách rõ ràng thông qua cài đặt tài khoản:

Từ góc độ người dùng, thật khó hiểu khi việc xóa trong cài đặt tài khoản của họ, trong một hộp thoại như trên, lại không dẫn đến việc passkey bị xóa trên client này.

2. Xóa tài khoản: Khi người dùng xóa tài khoản của họ, tất cả các passkey liên quan cũng nên được xóa. 3. Chính sách bảo mật: Các bên tin cậy có thể có các chính sách bảo mật yêu cầu thu hồi thông tin xác thực sau một thời gian không hoạt động hoặc do các vấn đề bảo mật được phát hiện.

Nếu không có phương pháp trực tiếp để xóa passkey ở phía client, những thông tin xác thực lỗi thời hoặc không hợp lệ này tiếp tục làm lộn xộn giao diện lựa chọn, dẫn đến sự nhầm lẫn. Người dùng có thể thấy và cố gắng sử dụng các passkey không còn hợp lệ, dẫn đến các lần xác thực thất bại và trải nghiệm người dùng kém.

Việc triển khai WebAuthn Signal API bao gồm một số bước và cân nhắc để đảm bảo chức năng được tích hợp một cách chính xác và an toàn. Signal API cho phép các bên tin cậy (RP) cập nhật hoặc xóa thông tin xác thực passkey trên trình xác thực phía client. Phần này nêu ra các cân nhắc và các bước chính để triển khai.

Khi triển khai WebAuthn Signal API, điều quan trọng là phải ghi nhớ những cân nhắc sau:

• Bảo vệ quyền riêng tư: WebAuthn Signal API được thiết kế để bảo vệ quyền riêng tư của người dùng vì đây là một trong những nền tảng của WebAuthn. Điều này có nghĩa là không có phản hồi nào được cung cấp cho RP về việc liệu thay đổi được yêu cầu có được xử lý hay không. API hoạt động âm thầm để ngăn chặn bất kỳ sự rò rỉ thông tin tiềm tàng nào về trạng thái của thông tin xác thực.

• Tính sẵn có của Trình xác thực: Hiệu quả của WebAuthn Signal API phụ thuộc vào tính sẵn có của trình xác thực. Điều này bao gồm cả tính sẵn có vật lý (ví dụ: sự hiện diện của khóa bảo mật) và hỗ trợ phần mềm (ví dụ: khả năng tương thích của trình duyệt và hệ điều hành). Trình duyệt chỉ có thể thực hiện các hành động nếu trình xác thực có thể truy cập được và hỗ trợ các hoạt động cần thiết mà không cần xác thực sinh trắc học.

• Hạn chế về Miền: API đảm bảo rằng chỉ bên tin cậy được liên kết với một miền cụ thể mới có thể yêu cầu thay đổi đối với thông tin xác thực liên quan đến miền đó. Đây là một biện pháp bảo mật để ngăn chặn các sửa đổi trái phép của bên thứ ba.

• Credential ID làm Khóa: Khi tham chiếu đến passkey, Credential ID là khóa chính được WebAuthn Signal API sử dụng. ID này xác định duy nhất passkey trên trình xác thực phía client. API cho phép RP thay đổi metadata liên quan đến passkey hoặc báo hiệu rằng một số passkey không nên được truy cập nữa, nhưng chỉ thông qua Credential ID. Trong trường hợp một trình xác thực không biết một Credential ID cụ thể, nó sẽ âm thầm bỏ qua.

Những cân nhắc này là cần thiết để hiểu các khía cạnh quan trọng nhất của WebAuthn Signal API hoạt động chính xác.

WebAuthn Signal API cung cấp một cơ chế hợp lý cho các bên tin cậy (RP) để cập nhật metadata liên quan đến passkey trên các trình xác thực phía client. Điều này đặc biệt quan trọng để đảm bảo rằng người dùng thấy thông tin chính xác và cập nhật trong giao diện lựa chọn thông tin xác thực mà không cần phải tạo passkey mới một cách không cần thiết. Đây là cách API cho phép điều này xảy ra:

Cập nhật Metadata với signalCurrentUserDetails(options)

Phương thức signalCurrentUserDetails(options) trong Signal API được thiết kế đặc biệt để cập nhật metadata của passkey. Phương thức này cho phép RP cung cấp các giá trị hiện tại cho user.name và user.displayName.

Đây là cách quy trình hoạt động (xem thêm tiêu chuẩn WebAuthn Cấp 3).

1. Cấu trúc phương thức: Phương thức signalCurrentUserDetails(options) bao gồm rp.id, user.id và các giá trị đã cập nhật cho user.name và user.displayName.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. Cập nhật Metadata cục bộ: Tìm kiếm các thông tin xác thực có sẵn cục bộ (trên trình xác thực) khớp với rpId và userId. Đối với tất cả các thông tin xác thực khớp, trình xác thực sẽ cập nhật name và displayName của thông tin xác thực.

3. Bảo vệ quyền riêng tư: Quá trình này được thiết kế để bảo vệ quyền riêng tư. Signal API không cung cấp phản hồi cho RP về việc liệu các cập nhật có được xử lý thành công hay không, ngăn chặn bất kỳ sự rò rỉ thông tin nào về trạng thái của thông tin xác thực.

4. Tính nhất quán trên các thiết bị: Bằng cách thường xuyên chạy các phương thức signalCurrentUserDetails(options), RP có thể đảm bảo rằng metadata cho passkey vẫn nhất quán trên các thiết bị và nền tảng khác nhau nơi người dùng có thể xác thực. Cách tiếp cận này làm giảm khả năng thông tin lỗi thời hoặc không chính xác được hiển thị trong giao diện lựa chọn thông tin xác thực.

Trong ảnh chụp màn hình ở trên, bạn có thể thấy cách Google Chrome báo hiệu một bản cập nhật như vậy cho người dùng. WebAuthn Signal API là một phần của Chrome 130 và có thể được thử nghiệm với Google Password Manager trên máy tính để bàn nếu cờ tính năng web thử nghiệm được kích hoạt.

WebAuthn Signal API cung cấp các cơ chế cho các bên tin cậy (RP) để báo hiệu việc xóa passkey khỏi các trình xác thực phía client. Điều này rất cần thiết để đảm bảo rằng các thông tin xác thực lỗi thời hoặc không hợp lệ không xuất hiện trong giao diện lựa chọn thông tin xác thực, do đó duy trì trải nghiệm người dùng hợp lý và an toàn. Có hai phương pháp để xóa passkey cục bộ: signalUnknownCredential(options) và signalAllAcceptedCredentials)(options). Phương pháp đầu tiên có thể được sử dụng trong các tình huống người dùng không được xác thực, trong khi phương pháp thứ hai có thể được sử dụng khi người dùng được xác thực. Do đó, phương pháp thứ hai nên được ưu tiên vì lý do riêng tư.

Đây là cách hai phương pháp hoạt động:

1. Cấu trúc phương thức: Phương thức signalUnknownCredential(options) bao gồm rpId (ID của bên tin cậy) và credentialId (định danh duy nhất của thông tin xác thực cần xóa).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

2. Gọi phương thức: RP gọi phương thức này bất cứ khi nào họ phát hiện ra rằng một thông tin xác thực nên được xóa. Điều này có thể xảy ra ngay sau một lần thử xác thực với một thông tin xác thực không hợp lệ, trong quá trình xóa tài khoản, hoặc khi người dùng thu hồi một thông tin xác thực thông qua cài đặt tài khoản.

3. Xử lý phương thức: Khi phương thức signalUnknownCredential(options) được gọi, trình xác thực phía client cố gắng tìm các thông tin xác thực khớp với rpId và credentialID được chỉ định để bỏ qua. Tùy thuộc vào khả năng của trình xác thực, thông tin xác thực sẽ bị xóa hoặc một quy trình cụ thể của trình xác thực sẽ được sử dụng để ẩn thông tin xác thực trong các lần xác thực trong tương lai.

1. Cấu trúc phương thức: Phương thức signalAllAcceptedCredentials(options) bao gồm rpId (ID của bên tin cậy), userId và một danh sách các Credential ID hợp lệ allAcceptedCredentialIds (danh sách các định danh duy nhất của các thông tin xác thực nên được giữ lại).

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. Gọi phương thức: RP gọi phương thức này bất cứ khi nào họ phát hiện ra rằng một thông tin xác thực nên được xóa và báo hiệu một danh sách các thông tin xác thực hợp lệ. Phương pháp này nên được ưu tiên hơn signalUnknownCredential(options) để xóa thông tin xác thực.

3. Xử lý phương thức: Khi phương thức signalAllAcceptedCredentials(options) được gọi, trình xác thực phía client khớp rpId và userId. Trình xác thực sẽ tra cứu tất cả các thông tin xác thực cục bộ khớp với rpId và userId. Kết quả được so sánh với allAcceptedCredentialIds. Nếu có các thông tin xác thực cục bộ không có trong allAcceptedCredentialIds, thì các thông tin xác thực này sẽ bị xóa cục bộ (hoặc bị ẩn tùy thuộc vào trình xác thực).

4. Hiển thị lại thông tin xác thực: Nếu một thông tin xác thực chỉ bị ẩn (tùy thuộc vào trình xác thực) và bây giờ là một phần của allAcceptedCredentialIds, thì thông tin xác thực này sẽ xuất hiện trở lại trong các lần xác thực trong tương lai.

5. Mẹo hữu ích:

   • Khi sử dụng signalAllAcceptedCredentials(options), điều quan trọng cần lưu ý là các trình xác thực có thể không phải lúc nào cũng được kết nối tại thời điểm phương thức này được thực thi. Do đó, các bên tin cậy có thể cân nhắc chạy signalAllAcceptedCredentials(options) định kỳ, chẳng hạn như trong mỗi lần đăng nhập, để đảm bảo rằng tất cả các thông tin xác thực đều được cập nhật.
   • Các bên tin cậy phải thận trọng khi chỉ định danh sách các ID thông tin xác thực (allAcceptedCredentialIds). Các thông tin xác thực không được bao gồm trong danh sách này có thể bị ẩn hoặc xóa bởi trình xác thực, có khả năng không thể khôi phục. Để ngăn các thông tin xác thực hợp lệ bị bỏ sót nhầm, điều quan trọng là phải đảm bảo danh sách đầy đủ. Nếu một ID thông tin xác thực hợp lệ vô tình bị bỏ sót, nó nên được thêm lại vào signalAllAcceptedCredentials(options) càng sớm càng tốt để làm cho nó hiển thị trở lại, giả sử trình xác thực hỗ trợ điều này.
   • Bất cứ khi nào có thể, các trình xác thực nên ưu tiên tạm thời ẩn thông tin xác thực thay vì xóa vĩnh viễn. Cách tiếp cận này có thể giúp tạo điều kiện phục hồi nếu một ID thông tin xác thực hợp lệ vô tình bị bên tin cậy bỏ sót, cho phép nó được khôi phục mà không bị mất vĩnh viễn.

Trong ảnh chụp màn hình ở trên, bạn có thể thấy cách Google Chrome báo hiệu việc xóa. WebAuthn Signal API là một phần của Chrome 132 và có thể được thử nghiệm với Google Password Manager trên máy tính để bàn.

Để triển khai hiệu quả WebAuthn Signal API và đảm bảo đồng bộ hóa liền mạch metadata của passkey trên các trình xác thực phía client, hãy xem xét các khuyến nghị sau:

• Theo dõi các bản cập nhật và việc triển khai thực tế của WebAuthn Signal API: Luôn cập nhật thông tin về các phát triển và cập nhật mới nhất liên quan đến Signal API. WebAuthn Signal API được bật với Google Chrome 132, sau đó là các trình duyệt khác (ví dụ: Safari cũng đã công bố hỗ trợ). Thường xuyên kiểm tra tiến trình và các bản cập nhật về WebAuthn Signal API để đảm bảo việc triển khai của bạn phù hợp với các tiêu chuẩn và thực tiễn mới nhất. Chúng tôi sẽ cập nhật bài viết này trong tương lai, hiện tại nó dựa trên thông tin có sẵn từ ngày 14 tháng 1 năm 2025.
• Bắt đầu với cách tiếp cận signalAllAcceptedCredentials(options) sau mỗi lần đăng nhập thành công: Cách tiếp cận này đảm bảo rằng tất cả metadata và Credential ID được cập nhật trong một phương thức duy nhất, đơn giản hóa quy trình và duy trì tính nhất quán trên các thiết bị và nền tảng, đồng thời vô hiệu hóa các thông tin xác thực đã bị xóa hoặc lỗi thời.
• Nhắn tin thời gian thực với signalUnknownCredential(options) cho các triển khai quy mô lớn: Cân nhắc sử dụng nhắn tin thời gian thực với phương thức signalUnknownCredential(options) trong các triển khai quy mô lớn hoặc khi có nhu cầu cập nhật ngay lập tức. Phương pháp này có thể nâng cao hiệu quả và độ chính xác của việc quản lý thông tin xác thực, đảm bảo rằng các thông tin xác thực không hợp lệ hoặc lỗi thời được xóa kịp thời khỏi giao diện lựa chọn.

Bằng cách làm theo các khuyến nghị này, bạn có thể triển khai WebAuthn Signal API một cách hiệu quả khi nó được hỗ trợ, đảm bảo rằng metadata của passkey luôn được cập nhật và nhất quán trên tất cả các trình xác thực phía client, từ đó cung cấp trải nghiệm người dùng mượt mà và an toàn cho passkey.

Tiêu chuẩn WebAuthn đang liên tục phát triển, trở nên phong phú hơn về tính năng hàng tháng. Sự ra đời của WebAuthn Signal API là một bước tiến quan trọng trong việc quản lý metadata và việc xóa passkey trên các trình xác thực phía client. API này giải quyết các trường hợp sử dụng quan trọng là giữ cho thông tin được đồng bộ giữa các bên tin cậy (RP) và trình xác thực, và đảm bảo rằng các passkey không hợp lệ hoặc lỗi thời được xóa, từ đó cải thiện trải nghiệm người dùng.

• Tại sao Signal API lại cần thiết? Signal API rất cần thiết để cập nhật metadata của passkey và xóa passkey trên các trình xác thực phía client. Nó giải quyết các vấn đề liên quan đến thông tin user.name và user.displayName lỗi thời, có thể gây nhầm lẫn khi thông tin xác thực được trình bày trong giao diện lựa chọn. Ngoài ra, nó giúp duy trì một giao diện lựa chọn thông tin xác thực sạch sẽ và an toàn bằng cách xóa các passkey đã bị thu hồi hoặc xóa.
• Signal API hoạt động như thế nào? Signal API hoạt động bằng cách cho phép RP gọi các phương thức về trạng thái hiện tại của thông tin xác thực, bao gồm các cập nhật cho metadata và báo hiệu việc xóa passkey. Các báo cáo này được xử lý bởi trình xác thực phía client, đảm bảo rằng thông tin được trình bày cho người dùng là chính xác và cập nhật. API được thiết kế để bảo vệ quyền riêng tư và hoạt động mà không cung cấp phản hồi cho RP về sự thành công của các cập nhật.

Khi tiêu chuẩn WebAuthn phát triển, nó được hưởng lợi từ sự đa dạng về lợi ích của những người tham gia, những người thúc đẩy các phần khác nhau của tiêu chuẩn tiến lên. Việc theo dõi những phát triển này là rất quan trọng để luôn cập nhật những cải tiến mới nhất và đảm bảo rằng các triển khai vẫn phù hợp với các thực tiễn và tiêu chuẩn tốt nhất mới nhất. Cộng đồng WebAuthn tiếp tục thúc đẩy sự đổi mới, làm cho việc xác thực trở nên an toàn và thân thiện với người dùng hơn.