Tài liệu Cheat Sheet về Passkey cho Lập trình viên

Tải xuống toàn bộ Tài liệu Passkeys Cheat Sheet miễn phí và nhận tất cả thông tin chi tiết.

• ✅ Hơn 4.000 lượt tải xuống
• ✅ Được yêu cầu bởi các nhóm lập trình viên tại Ally, Kmart, Octopus Energy & Stanford CS
• ✅ Không có nội dung tiếp thị - chỉ có thông tin kỹ thuật chuyên sâu

Hướng dẫn Toàn diện về Passkey cho Lập trình viên

Tải xuống Tài liệu Passkeys Cheat Sheet

Nhận tài liệu tham khảo dành riêng cho lập trình viên về mọi khía cạnh của passkey, bao gồm khả năng hỗ trợ nền tảng, hành vi trình duyệt, các phương pháp hay nhất về UX và mẹo tích hợp.

Tải xuống miễn phí Passkeys Cheat Sheet

Email công việc *

Tên *

Công ty *

Chức danh *

Tải xuống miễn phí

Quá trình xác thực bằng passkey dựa trên hai quy trình, còn được gọi là ceremonies, bao gồm đăng ký (hay còn gọi là attestation phase) và đăng nhập (hay còn gọi là assertion phase).
Mỗi giai đoạn đều yêu cầu một random challenge được tạo bởi máy chủ, sau đó được ký bởi authenticator và gửi lại máy chủ WebAuthn để xác minh người dùng.

Thử nghiệm các luồng passkey trong Passkeys Debugger.

Thử miễn phí

Ceremony đăng ký sử dụng hai đối tượng trung tâm: PublicKeyCredentialCreationOptions và attestation.

Ceremony đăng nhập sử dụng hai đối tượng trung tâm: PublicKeyCredentialRequestOptions và assertion.

Xem có bao nhiêu người thực sự dùng passkeys.

Xem dữ liệu adoption

Đối với việc đăng ký và đăng nhập bằng passkey, có bốn đối tượng chính:

• PublicKeyCredentialCreationOptions
• PublicKeyCredentialRequestOptions
• attestation
• assertion

Phần này cũng giải thích đối tượng authenticatorSelection - được sử dụng trong PublicKeyCredentialCreationOptions.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

PublicKeyCredentialCreationOptions là đối tượng trung tâm của giai đoạn attestation (Đăng ký). Nó được tạo ra và trả về từ máy chủ WebAuthn.

{
    "PublicKeyCredentialCreationOptions": {
        "rp": {
            "id": "passkeys.eu",
            "name": "Corbado Passkeys Demo"
        },
        "user": {
            "displayName": "john.doe",
            "id": "dXNyLZ….DU10Tc",
            "name": "john@doe.com"
        },
        "challenge": "888fix4Bus...pHHr3Y",
        "pubKeyCredParams": [
            {
                "alg": -7,
                "type": "public-key"
            },
            {
                "alg": -257,
                "type": "public-key"
            }
        ],
        "excludeCredentials": [],
        "authenticatorSelection": {
            "authenticatorAttachment": "platform",
            "residentKey": "required",
            "userVerification": "required"
        },
        "attestation": "none",
        "extensions": {}
    }
}

Đối tượng này chứa các thuộc tính sau:

• rp: Xác định Relying Party (= máy chủ đang tìm cách xác thực người dùng), xem phần 4.2 Relying Party ID (rpID).
• user: Chứa dữ liệu về tài khoản người dùng đang yêu cầu attestation. ID là một chuỗi byte do Relying Party chọn, chuỗi này không được chứa thông tin cá nhân. Tên người dùng hoặc địa chỉ email được lưu trữ thay thế trong thuộc tính name hoặc displayName. Đọc thêm về điều này trong phần 4.1 Database Schema.
• challenge: Một BufferSource được mã hóa base64URL ngẫu nhiên cần được ký bởi authenticator.
• pubKeyCredParams: Các thuộc tính cụ thể của thông tin xác thực cần tạo, thường là (các) thuật toán được hỗ trợ.
• timeout: Thời gian tùy chọn tính bằng mili giây để client chờ quá trình gọi hoàn tất.
• excludeCredentials: Danh sách các thông tin xác thực tùy chọn nhằm giới hạn việc tạo nhiều passkey trên cùng một thiết bị.
• authenticatorSelection: Tùy chọn để chọn authenticator được sử dụng cho phương thức, ví dụ: liệu residentKey có bắt buộc hay không. Xem 2.5 authenticatorSelection.
• attestation: Có thể được sử dụng để yêu cầu đối tượng attestation được chuyển tiếp tới Relying Party theo một hình thức cụ thể. Các giá trị có thể là none (mặc định), indirect, direct và enterprise.
• extensions: Các yêu cầu tùy chọn để xử lý bổ sung, chẳng hạn như các giá trị trả về cụ thể. ví dụ:
  • credProbs yêu cầu thông tin về việc liệu thông tin xác thực được tạo có phải là discoverable hay không
  • prf cho phép Relying Party sử dụng đầu ra từ hàm giả ngẫu nhiên (PRF) được liên kết với một thông tin xác thực

Đăng ký Passkeys Substack để nhận tin mới nhất.

Đăng ký

PublicKeyCredentialRequestOptions là đối tượng trung tâm của giai đoạn assertion (Đăng nhập). Nó được tạo ra và trả về từ máy chủ WebAuthn.

{
    "publicKeyCredentialRequestOptions": {
        "challenge": "pT7HMA-…dFPHk",
        "timeout": 500,
        "rpId": "passkeys.eu",
        "userVerification": "preferred",
        "allowCredentials": [],
        "extensions": []
    }
}

Đối tượng này chứa các thuộc tính sau:

• challenge, timeout, extensions: xem bên trên.
• rpId: Định danh của Relying Party cho yêu cầu assertion, xem phần 4.2 Relying Party ID (rpID).
• allowCredentials: Danh sách thông tin xác thực tùy chọn được cho phép để xác thực, biểu thị ưu tiên của bên gọi theo thứ tự giảm dần. Danh sách này sẽ được điền bằng các PublicKeyCredentialDescriptors.
• userVerification: Giá trị tùy chọn để chỉ định các yêu cầu xác minh người dùng trong quá trình thực hiện thao tác. Các giá trị có thể là preferred (mặc định), required hoặc discouraged.

Trong suốt Attestation / Đăng ký Ceremony, Authenticator trả về Registration Response này. Bạn có thể tự thử điều này trong Passkeys Debugger.

{
    "authenticatorAttachment": "platform",
    "id": "JKZbixUfKN_aZtimefYT-OjH5dw",
    "rawId": "JKZbixUfKN_aZtimefYT-OjH5dw",
    "response": {
        "attestationObject": {
            "fmt": "none",
            "attStmt": {},
            "authData": {
                "rpIdHash": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkM",
                "flags": {
                    "userPresent": true,
                    "userVerified": true,
                    "backupEligible": true,
                    "backupStatus": true,
                    "attestedData": true,
                    "extensionData": false
                },
                "counter": 0,
                "aaguid": {
                    "raw": "fbfc3007-154e-4ecc-8c0b-6e020557d7bd",
                    "name": "iCloud Keychain"
                },
                "credentialID": "JKZbixUfKN_aZtimefYT-OjH5dw",
                "credentialPublicKey": "pQECAyYgASFYIPWLalDzyxIDmAADvfK8iNM5To50kh7TyPH-teEz8RMdIlgg3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA",
                "parsedCredentialPublicKey": {
                    "keyType": "EC2 (2)",
                    "algorithm": "ES256 (-7)",
                    "curve": 1,
                    "x": "9YtqUPPLEgOYAAO98ryI0zlOjnSSHtPI8f614TPxEx0",
                    "y": "3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA"
                }
            }
        },
        "clientDataJSON": {
            "type": "webauthn.create",
            "challenge": "k2p6f-upzP_hc6NZvmMAxiI0VSTeQIeXXVRGW62LTj0",
            "origin": "https://www.passkeys-debugger.io",
            "crossOrigin": false
        },
        "transports": ["hybrid", "internal"],
        "authenticatorData": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkNdAAAAAPv8MAcVTk7MjAtuAgVX170AFCSmW4sVHyjf2mbYpnn2E_jox-XcpQECAyYgASFYIPWLalDzyxIDmAADvfK8iNM5To50kh7TyPH-teEz8RMdIlgg3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA",
        "publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9YtqUPPLEgOYAAO98ryI0zlOjnSSHtPI8f614TPxEx3cPts8hZAnzP5YWffN1hnMnD1zuaE92Z-VCoP29Xt58A",
        "publicKeyAlgorithm": -7
    },
    "type": "public-key",
    "clientExtensionResults": {}
}

Attestation chứa một số thành phần quan trọng như attestationObject, algorithm và các flag transport.

Được lấy từ đặc tả Webauthn của W3C

attestationObject là một đối tượng được mã hóa CBOR, chứa thông tin về các thông tin xác thực mới được tạo, khóa công khai và dữ liệu liên quan khác:

• fmt thường được đánh giá là "none" đối với passkey
• attStmt trống đối với passkey và được điền cho các authenticator khác, ví dụ: hardware security key
• authData là một bộ đệm các giá trị chứa dữ liệu sau:

Đọc thêm về extensions.

Passkey được tạo bằng các thuật toán COSE, cho biết thuật toán được sử dụng trong thuộc tính algorithm của parsedCredentialPublicKey trong đối tượng attestation.
Dưới đây là tổng quan về các thuật toán COSE phù hợp nhất:

Thuộc tính transports chỉ ra các cơ chế mà qua đó một authenticator có thể giao tiếp với một client. Một số kết hợp giá trị mẫu phổ biến là:

• "transports": ["internal","hybrid"]: Passkey có thể được sử dụng từ platform authenticator (ví dụ: Face ID, Touch ID, Windows Hello) hoặc qua xác thực liên thiết bị (cross-device authentication) (sử dụng mã QR & Bluetooth).
• "transports": ["internal"]: Passkey chỉ có thể được sử dụng từ platform authenticator (ví dụ: Face ID, Touch ID, Windows Hello)
• Không có thuộc tính "transports" nào được đặt: hành vi mặc định không đưa ra bất kỳ chỉ báo nào

Trong suốt Assertion / Đăng nhập Ceremony, Authenticator trả về Login Response này. Bạn có thể tự thử điều này trong Passkeys Debugger.

{
    "id": "JKZbixUfKN_aZtimefYT-OjH5dw",
    "rawId": "JKZbixUfKN_aZtimefYT-OjH5dw",
    "type": "public-key",
    "authenticatorAttachment": "platform",
    "response": {
        "authenticatorData": {
            "rpIdHash": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkM",
            "flags": {
                "userPresent": true,
                "userVerified": true,
                "backupEligible": true,
                "backupStatus": true,
                "attestedData": false,
                "extensionData": false
            },
            "counter": 0
        },
        "clientDataJSON": {
            "type": "webauthn.get",
            "challenge": "GCVkITWbe2l2dttsn_DgJYvH9QPHPDo0ygWgcgI6B7U",
            "origin": "https://www.passkeys-debugger.io",
            "crossOrigin": false,
            "other_keys_can_be_added_here": "do not compare clientDataJSON against a template. See https://goo.gl/yabPex"
        },
        "signature": "MEQCIA-orC8N2KKWOxyY17BWP8lB-Be5to9btXRnJZf2SLhXAiBGxJe5Eu5LwOTbsyzAYmIXHOhlC3pN7s7Q1fRLvEW57g",
        "userHandle": "_FKz1uwqmR_3yGq6hJntzoIFwFC_d1u_53YRELh0KlE"
    }
}

assertion chứa một số thành phần quan trọng như flags, signature và userHandle.

Dưới đây là tổng quan về các flag quan trọng nhất và sự kết hợp của chúng:

Signature (chữ ký) được sử dụng để xác minh rằng người dùng đang cố gắng đăng nhập thực sự sở hữu khóa riêng (private key). Chữ ký được tạo bằng cách nối authenticatorData và clientDataHash (nghĩa là phiên bản SHA-256 của ClientDataJSON) rồi ký kết quả thu được bằng private key (trong authenticator). Để xác minh với khóa công khai (public key), chúng ta cũng nối authenticatorData và clientDataHash. Nếu kết quả xác minh trả về true, quá trình xác thực thành công.

userHandle chính là user_id thực tế. Đọc thêm về user_id trong phần 4.1 Database Schema.

Đối tượng authenticatorSelection cho phép máy chủ chỉ định các thiết lập cho authenticator và việc tạo thông tin xác thực với các giá trị sau:

• Platform: Authenticator được gắn vào nền tảng của client và do đó không thể tháo rời.
• Cross-platform: Authenticator không bị ràng buộc với nền tảng của client và có thể được sử dụng trên nhiều thiết bị.

• Required: Authenticator phải tạo một resident key (nếu không thể, quá trình thao tác sẽ thất bại).
• Preferred: Authenticator nên cố gắng tạo một resident key (nếu không thể, nó sẽ tạo một non-resident key).
• Discouraged: Authenticator phải tạo một non-resident key (nếu không thể, quá trình thao tác sẽ thất bại).

• Required: Thao tác yêu cầu phải xác minh người dùng.
• Preferred: Thao tác nên xác minh người dùng, nhưng có thể tiến hành mà không cần xác minh (tùy chọn tiêu chuẩn).
• Discouraged: Thao tác không nên xác minh người dùng.

Conditional UI (tự động điền passkey) hiển thị các passkey khả dụng trong một menu thả xuống (dropdown) để người dùng lựa chọn, khi người dùng đã đăng ký một resident key với relying party. Tính năng này giúp cải thiện khả năng sử dụng của passkey, nhưng đòi hỏi nỗ lực phát triển bổ sung và không khả dụng cho tất cả các kết hợp OS / trình duyệt.

Giống như đăng nhập thông thường, Conditional UI cũng sử dụng các đối tượng PublicKeyCredentialRequestOptions và assertion.

Conditional UI (hiện tại) chưa khả dụng trên tất cả các kết hợp giữa hệ điều hành và trình duyệt. Dưới đây là thông tin tổng quan về mức độ hỗ trợ hiện tại của trình duyệt (tháng 3 năm 2024):

Để có thông tin tổng quan cập nhật nhất, hãy xem trang web này.

Một đoạn mã code cơ bản và tối giản đầy đủ cho phương thức Conditional UI trông giống như sau:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // truy xuất request options (bao gồm challenge) từ máy chủ WebAuthn
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Conditional UI chỉ hoạt động với resident keys / discoverable credentials
Khuyến nghị là nên cung cấp một điểm cuối máy chủ (server endpoint) khác biệt để bắt đầu quy trình đăng nhập Conditional UI.
Client cần đáp ứng nhiều yêu cầu:

• Trình duyệt cần hỗ trợ Conditional UI (xem 3.2 Khả năng Tương thích của Thiết bị).
• JavaScript phải được kích hoạt và trang web phải cung cấp trường input HTML.
• Các tham số timeout nên được bỏ qua

Để tránh xảy ra lỗi, máy chủ trước tiên nên kiểm tra tính khả dụng của client thông qua hàm sau: Trong lưu lượng thực tế, các vấn đề về phát hiện và vòng đời thường xuất hiện dưới dạng NotAllowedError hoặc AbortError. Sử dụng hướng dẫn này về lỗi WebAuthn để phân loại lỗi dự kiến so với lỗi không mong muốn, bao gồm các lỗi passkey của native credential Manager.

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Check if conditional mediation is available.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Call WebAuthn authentication start endpoint
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
    ...
    */
    }
}

Trường input (đầu vào) nên nhận một mã thông báo (token) autofill HTML, nhằm báo hiệu cho client điền các passkey vào yêu cầu đang diễn ra. Ngoài passkey, các token autofill này có thể được ghép nối với các token hiện có, chẳng hạn như tên người dùng và mật khẩu:

• autocomplete="username webauthn": Ngoài việc hiển thị các passkey, thuộc tính này cũng đề xuất tự động điền tên người dùng.
• autocomplete="current-password webauthn": Ngoài việc hiển thị các passkey, thuộc tính này còn nhắc thêm tính năng tự động điền mật khẩu.

<label for="name">Tên người dùng:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Mật khẩu:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

Không có một database schema (lược đồ cơ sở dữ liệu) nào là bắt buộc hoặc được chuẩn hóa cho các máy chủ WebAuthn. Tuy nhiên, ví dụ về database schema này có thể được sử dụng để lưu trữ các thông tin cần thiết và cung cấp tất cả các chức năng của một máy chủ WebAuthn:

Các thuộc tính in đậm là bắt buộc cho một quá trình triển khai khả thi tối thiểu (minimal viable implementation), trong khi các thuộc tính khác chỉ cần thiết cho các tính năng tùy chọn nhưng hữu ích.

• Credential ID: Đây là một ID duy nhất do authenticator tạo ra trong quá trình đăng ký passkey. Nó nên được sử dụng để tra cứu tài khoản người dùng thực sự được liên kết với passkey đó. Ngoài ra, sau đó userHandle (từ user_id) nên được đem so sánh để xác thực tài khoản được sử dụng để đăng nhập. Không sử dụng thuộc tính user.name cho mục đích so sánh vì thuộc tính này có thể thay đổi theo thời gian.
• User ID (user_id): ID duy nhất do Relying Party chỉ định để biểu thị cho một tài khoản người dùng trong hệ thống của họ. ID này được trả về dưới dạng userHandle trong đối tượng assertion.

• User DisplayName (user.displayName): Tên có định dạng thân thiện và dễ đọc đối với người dùng, thường là họ tên đầy đủ của người dùng. Tên này được hiển thị cho người dùng, nhưng không được sử dụng trong quá trình xác thực.

• User Name (user.name): Tên hiển thị duy nhất và dễ đọc, thường là địa chỉ e-mail hoặc tên đăng nhập. Nó có thể được hiển thị cho người dùng nhưng không được sử dụng trong quá trình xác thực.

Relying Party ID (rpID) là một miền (domain) được lưu trữ trong passkey, nhằm đảm bảo rằng passkey chỉ hoạt động đối với tên miền đúng (URL trình duyệt, xem bài viết này để biết đối với ứng dụng native). Trong quá trình xác thực, rpID được đối chiếu với URL trình duyệt và chỉ được cho phép trong hai trường hợp sau:

1. URL khớp chính xác với rpId HOẶC
2. URL là một miền phụ (subdomain) khớp với rpId và miền gốc (parent domain) không nằm trong Public Suffix List

Dưới đây là một số ví dụ về các tổ hợp (không) được cho phép:

Dưới đây là danh sách các công cụ & website hữu ích cho việc triển khai passkey.

• Passkeys Debugger: Công cụ để gỡ lỗi (debugging) các WebAuthn Response dưới dạng JSON và kiểm thử các thao tác WebAuthn với nhiều tùy chọn khác nhau.
• Passkeys Glossary: Giải thích về các thuật ngữ & khái niệm liên quan đến passkey
• WebAuthn Specification: Đây là tài liệu đặc tả chính thức của WebAuthn.
• Chrome Device Log: Công cụ để hiển thị nhật ký về các thao tác WebAuthn trên thiết bị của bạn (chỉ có sẵn trên Chrome qua chrome://device-log)

Để có các chiến lược tối ưu hóa passkey UX vượt ra ngoài việc triển khai mặt kỹ thuật, hãy xem hướng dẫn của chúng tôi về các phương pháp tốt nhất khi tạo passkey và các phương pháp tốt nhất khi đăng nhập bằng passkey.

Nếu bạn muốn triển khai passkey vào bất kỳ ứng dụng nào chỉ với vài dòng code, bạn cũng có thể sử dụng Corbado Complete (cho các ứng dụng mới) hoặc Corbado Connect (cho các ứng dụng hiện có)

Về Corbado

Corbado là Authentication Intelligence Platform dành cho các đội CIAM vận hành xác thực consumer ở quy mô lớn. Chúng tôi giúp bạn nhìn thấy điều mà log IDP và các công cụ analytics thông thường không thấy: những thiết bị, phiên bản OS, trình duyệt và trình quản lý credential nào hỗ trợ passkey, tại sao quá trình đăng ký không chuyển thành đăng nhập, luồng WebAuthn fail ở đâu, và khi nào một bản cập nhật OS hay trình duyệt làm hỏng đăng nhập một cách âm thầm — tất cả mà không cần thay thế Okta, Auth0, Ping, Cognito hay IDP nội bộ của bạn. Hai sản phẩm: Corbado Observe bổ sung observability cho passkey và mọi phương thức đăng nhập khác. Corbado Connect mang đến managed passkey với analytics tích hợp (song hành cùng IDP của bạn). VicRoads vận hành passkey cho hơn 5M người dùng với Corbado (kích hoạt passkey +80%). Trao đổi với chuyên gia Passkey →

Conditional UI yêu cầu phải kiểm tra khả năng hỗ trợ của trình duyệt thông qua PublicKeyCredential.isConditionalMediationAvailable() trước khi bắt đầu quy trình xác thực. Trường input phải bao gồm HTML token autocomplete="username webauthn" và người dùng phải có một resident key (discoverable credential) đã được đăng ký. Bạn nên dùng một server endpoint riêng biệt để xử lý quy trình đăng nhập bằng Conditional UI.

Tối thiểu, hãy lưu trữ Credential ID (do authenticator tạo ra trong quá trình đăng ký) và User ID (user_id), vốn được trả về dưới dạng userHandle trong đối tượng assertion. Sử dụng Credential ID để tra cứu tài khoản người dùng có liên kết và so sánh userHandle đó để xác nhận việc đăng nhập. Tránh sử dụng user.name để so sánh vì thông tin này có thể bị thay đổi theo thời gian.

Resident keys (discoverable credentials) được lưu trữ trên chính authenticator và được truy xuất ra trong quá trình xác thực, điều kiện bắt buộc để tính năng Conditional UI có thể hoạt động. Non-resident keys lưu trữ Credential ID trên máy chủ và gửi nó đến authenticator trong quá trình xác thực. Trường residentKey trong authenticatorSelection sẽ kiểm soát hành vi này với các giá trị "required", "preferred" hoặc "discouraged".

Trường userVerification kiểm soát việc liệu authenticator có cần phải xác minh người dùng trong quá trình đăng nhập hay không, qua việc chấp nhận các giá trị "required", "preferred" (mặc định) hoặc "discouraged". Khi được đặt ở mức "preferred", người dùng hoặc thiết bị của họ có thể bỏ qua hoàn toàn quy trình xác minh trong lúc xác thực, điều này có khả năng làm giảm đi tính bảo mật. Thiết lập thuộc tính này ở mức "required" nhằm đảm bảo quy trình xác minh sẽ luôn diễn ra trước khi tiến trình xác thực được hoàn tất.