डेवलपर्स के लिए पासकीज़ चीट शीट

पासकीज़ चीट शीट को मुफ़्त में डाउनलोड करें और सभी जानकारी प्राप्त करें।

• ✅ 4,000 से अधिक बार डाउनलोड किया जा चुका है
• ✅ Ally, Kmart, Octopus Energy और Stanford CS की डेवलपर टीमों द्वारा अनुरोधित
• ✅ कोई मार्केटिंग बातें नहीं - केवल तकनीकी जानकारी

अंतिम पासकी डेवलपर गाइड

पासकीज़ चीट शीट डाउनलोड करें

प्लेटफ़ॉर्म सपोर्ट, ब्राउज़र व्यवहार, UX सर्वोत्तम प्रथाओं और एकीकरण सुझावों को कवर करने वाले सभी पासकीज़ के लिए डेवलपर-केंद्रित संदर्भ प्राप्त करें।

मुफ़्त पासकीज़ चीट शीट डाउनलोड करें

वर्क ईमेल *

नाम *

कंपनी *

पद *

मुफ़्त में डाउनलोड करें

पासकीज़ के साथ ऑथेंटिकेशन दो प्रक्रियाओं पर आधारित है, जिन्हें समारोह भी कहा जाता है, पंजीकरण (उर्फ attestation चरण) और लॉगिन (उर्फ assertion चरण)।
प्रत्येक चरण में सर्वर द्वारा उत्पन्न एक यादृच्छिक चुनौती की आवश्यकता होती है, जिसे ऑथेंटिकेटर द्वारा हस्ताक्षरित किया जाता है और उपयोगकर्ता को सत्यापित करने के लिए WebAuthn सर्वर को वापस भेजा जाता है।

Passkeys Debugger में passkey flows के साथ experiment करें.

मुफ्त में आज़माएं

पंजीकरण समारोह दो केंद्रीय ऑब्जेक्ट्स का उपयोग करता है: PublicKeyCredentialCreationOptions और attestation.

लॉगिन समारोह दो केंद्रीय ऑब्जेक्ट्स का उपयोग करता है: PublicKeyCredentialRequestOptions और assertion.

देखें कि वास्तव में कितने लोग passkeys इस्तेमाल करते हैं.

Adoption data देखें

पासकीज़ के साथ पंजीकरण और लॉगिन के लिए, चार मुख्य ऑब्जेक्ट्स हैं:

• PublicKeyCredentialCreationOptions
• PublicKeyCredentialRequestOptions
• attestation
• assertion

यह अनुभाग authenticatorSelection ऑब्जेक्ट की भी व्याख्या करता है, जिसका उपयोग 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 attestation चरण (पंजीकरण) का केंद्रीय ऑब्जेक्ट है। यह 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": {}
    }
}

ऑब्जेक्ट में ये विशेषताएँ शामिल हैं:

• rp: रिलाइंग पार्टी (= उपयोगकर्ता को प्रमाणित करने के लिए सर्वर) की पहचान करता है, देखें अनुभाग 4.2 रिलाइंग पार्टी आईडी (rpID)।
• user: attestation का अनुरोध करने वाले उपयोगकर्ता खाते के बारे में डेटा शामिल है। आईडी रिलाइंग पार्टी द्वारा चुना गया एक बाइट अनुक्रम है, जिसमें व्यक्तिगत जानकारी नहीं होनी चाहिए। उपयोगकर्ता नाम या ई-मेल पता इसके बजाय name या displayName विशेषता में सहेजा जाता है। इसके बारे में अनुभाग 4.1 डेटाबेस स्कीमा में और पढ़ें।
• challenge: एक यादृच्छिक रूप से उत्पन्न base64URL एन्कोडेड BufferSource जिसे ऑथेंटिकेटर द्वारा हस्ताक्षरित करने की आवश्यकता है।
• pubKeyCredParams: बनाए जाने वाले क्रेडेंशियल की निर्दिष्ट विशेषताएँ, आमतौर पर समर्थित एल्गोरिदम।
• timeout: क्लाइंट द्वारा कॉल पूरा होने की प्रतीक्षा करने के लिए मिलीसेकंड में वैकल्पिक समय।
• excludeCredentials: एक डिवाइस पर कई पासकीज़ के निर्माण को सीमित करने के लिए क्रेडेंशियल्स की वैकल्पिक सूची।
• authenticatorSelection: विधि के लिए उपयोग किए गए ऑथेंटिकेटर का वैकल्पिक चयन, उदा. क्या residentKey की आवश्यकता है। 2.5 authenticatorSelection देखें।
• attestation: इसका उपयोग यह अनुरोध करने के लिए किया जा सकता है कि attestation ऑब्जेक्ट रिलाइंग पार्टी को एक विशिष्ट रूप में दिया जाए। संभावित मान none (डिफ़ॉल्ट), indirect, direct और enterprise हैं।
• extensions: अतिरिक्त प्रसंस्करण के लिए वैकल्पिक अनुरोध, जैसे कि विशिष्ट रिटर्न मान। उदा.
  • credProbs यह जानकारी का अनुरोध करता है कि बनाया गया क्रेडेंशियल डिस्कवरेबल है या नहीं
  • prf रिलाइंग पार्टी को एक क्रेडेंशियल से जुड़े छद्म-यादृच्छिक फ़ंक्शन (PRF) से आउटपुट का उपयोग करने की अनुमति देता है

Latest news के लिए हमारे Passkeys Substack को subscribe करें.

Subscribe करें

PublicKeyCredentialRequestOptions assertion चरण (लॉगिन) का केंद्रीय ऑब्जेक्ट है। यह WebAuthn सर्वर द्वारा बनाया और वापस किया जाता है।

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

ऑब्जेक्ट में ये विशेषताएँ शामिल हैं:

• challenge, timeout, extensions: ऊपर देखें।
• rpId: assertion अनुरोध के लिए रिलाइंग पार्टी का पहचानकर्ता, अनुभाग 4.2 रिलाइंग पार्टी आईडी (rpID) देखें।
• allowCredentials: क्रेडेंशियल्स की वैकल्पिक सूची जिन्हें ऑथेंटिकेशन के लिए अनुमति दी गई है, जो अवरोही क्रम में कॉलर्स की प्राथमिकता को दर्शाता है। यह सूची PublicKeyCredentialDescriptors से भरी होगी।
• userVerification: ऑपरेशन के दौरान उपयोगकर्ता सत्यापन के लिए आवश्यकताओं को निर्दिष्ट करने के लिए वैकल्पिक मान। संभावित मान preferred (डिफ़ॉल्ट), required या discouraged हैं।

Attestation / पंजीकरण समारोह के दौरान, ऑथेंटिकेटर यह पंजीकरण प्रतिक्रिया देता है। आप इसे स्वयं 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 में कुछ महत्वपूर्ण घटक शामिल हैं जैसे attestationObject, algorithm और transport-झंडे।

W3C के Webauthn विनिर्देश से लिया गया

attestationObject एक CBOR-एन्कोडेड ऑब्जेक्ट है, जिसमें नए बनाए गए क्रेडेंशियल्स, पब्लिक की और अन्य प्रासंगिक डेटा के बारे में जानकारी होती है:

• fmt आमतौर पर पासकीज़ के लिए "none" पर मूल्यांकन किया जाता है
• attStmt पासकीज़ के लिए खाली होता है और अन्य ऑथेंटिकेटर के लिए भरा जाता है, उदा. हार्डवेयर सुरक्षा कुंजी
• authData मानों का एक बफर है जिसमें निम्नलिखित डेटा होता है:

extensions के बारे में और पढ़ें।

पासकीज़ COSE एल्गोरिदम के साथ उत्पन्न होते हैं, जो attestation ऑब्जेक्ट में parsedCredentialPublicKey के algorithm-विशेषता में उपयोग किए गए एल्गोरिदम को दर्शाते हैं।
यहाँ सबसे प्रासंगिक COSE एल्गोरिदम का अवलोकन दिया गया है:

transports -प्रॉपर्टी उन तंत्रों को इंगित करता है जिनके माध्यम से एक ऑथेंटिकेटर क्लाइंट के साथ संवाद कर सकता है। कुछ सामान्य, नमूना मान संयोजन हैं:

• "transports": ["internal","hybrid"]: पासकीज़ का उपयोग प्लेटफ़ॉर्म ऑथेंटिकेटर (उदा. Face ID, Touch ID, Windows Hello) से या क्रॉस-डिवाइस ऑथेंटिकेशन (क्यूआर कोड और ब्लूटूथ का उपयोग करके) के माध्यम से किया जा सकता है।
• "transports": ["internal"]: पासकीज़ का उपयोग केवल प्लेटफ़ॉर्म ऑथेंटिकेटर (उदा. Face ID, Touch ID, Windows Hello) से किया जा सकता है
• कोई "transports" प्रॉपर्टी सेट नहीं: डिफ़ॉल्ट व्यवहार जो कोई संकेत नहीं देता है

Assertion / लॉगिन समारोह के दौरान, ऑथेंटिकेटर यह लॉगिन प्रतिक्रिया देता है। आप इसे स्वयं 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 में कुछ महत्वपूर्ण घटक शामिल हैं जैसे झंडे, हस्ताक्षर और userHandle।

यहाँ सबसे प्रासंगिक flags और उनके संयोजनों का अवलोकन दिया गया है:

signature का उपयोग यह सत्यापित करने के लिए किया जाता है कि लॉग इन करने का प्रयास करने वाले उपयोगकर्ता के पास वास्तव में प्राइवेट की है। हस्ताक्षर authenticatorData और clientDataHash (यानी ClientDataJSON का SHA-256 संस्करण) को जोड़कर और ऑथेंटिकेटर में प्राइवेट की के साथ परिणाम पर हस्ताक्षर करके बनाया जाता है। पब्लिक की के साथ सत्यापित करने के लिए, हम authenticatorData और clientDataHash को भी जोड़ते हैं। यदि सत्यापन परिणाम सही आता है, तो ऑथेंटिकेशन सफल होता है।

userHandle वास्तविक user_id है। अनुभाग 4.1 डेटाबेस स्कीमा में user_id के बारे में और पढ़ें।

authenticatorSelection - ऑब्जेक्ट सर्वर को निम्नलिखित मानों के साथ ऑथेंटिकेटर और क्रेडेंशियल निर्माण के लिए सेटिंग्स निर्देशित करने की अनुमति देता है:

• Platform: ऑथेंटिकेटर क्लाइंट के प्लेटफ़ॉर्म से जुड़ा हुआ है और इसलिए इसे हटाया नहीं जा सकता है।
• Cross-platform: ऑथेंटिकेटर क्लाइंट के प्लेटफ़ॉर्म से बाध्य नहीं है और इसका उपयोग कई उपकरणों पर किया जा सकता है।

• Required: ऑथेंटिकेटर को एक resident key बनानी चाहिए (यदि संभव न हो तो ऑपरेशन विफल होना चाहिए)।
• Preferred: ऑथेंटिकेटर को एक resident key बनाने का प्रयास करना चाहिए (यदि संभव न हो तो उसे एक non-resident key बनानी चाहिए)।
• Discouraged: ऑथेंटिकेटर को एक non-resident key बनानी चाहिए (यदि संभव न हो तो ऑपरेशन विफल होना चाहिए)।

• Required: ऑपरेशन को उपयोगकर्ता को सत्यापित करना चाहिए।
• Preferred: ऑपरेशन को उपयोगकर्ता को सत्यापित करना चाहिए, लेकिन इसके बिना आगे बढ़ सकता है (मानक विकल्प)
• Discouraged: ऑपरेशन को उपयोगकर्ता को सत्यापित नहीं करना चाहिए।

Conditional UI (पासकी ऑटोफिल) उपयोगकर्ता के लिए चयन ड्रॉपडाउन में उपलब्ध पासकीज़ प्रदर्शित करता है, जब किसी उपयोगकर्ता के पास रिलाइंग पार्टी के साथ पंजीकृत एक resident key होती है। यह पासकीज़ की प्रयोज्यता में सुधार करता है, लेकिन इसके लिए अतिरिक्त विकास प्रयासों की आवश्यकता होती है और यह सभी OS / ब्राउज़र संयोजनों के लिए उपलब्ध नहीं है।

एक नियमित लॉगिन की तरह, Conditional UI भी PublicKeyCredentialRequestOptions और assertion ऑब्जेक्ट्स का उपयोग करता है

Conditional UI ऑपरेटिंग सिस्टम और ब्राउज़र के सभी संयोजनों पर (अभी तक) उपलब्ध नहीं है। यहाँ वर्तमान ब्राउज़र कवरेज (मार्च 2024) का अवलोकन दिया गया है:

अद्यतित अवलोकन के लिए यह वेबसाइट देखें।

Conditional UI विधि के लिए एक पूर्ण, न्यूनतम कोड इस तरह दिखता है:

<!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 {
                    // 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 केवल resident keys / डिस्कवरेबल क्रेडेंशियल्स के साथ काम करता है
Conditional UI लॉगिन शुरू करने के लिए एक अलग सर्वर एंडपॉइंट प्रदान करने की अनुशंसा की जाती है।
क्लाइंट को कई आवश्यकताओं को पूरा करने की आवश्यकता है:

• ब्राउज़र को Conditional UI का समर्थन करने की आवश्यकता है (देखें 3.2 डिवाइस संगतता)।
• जावास्क्रिप्ट सक्षम होना चाहिए और वेब पेज को एक HTML इनपुट फ़ील्ड प्रदान करना चाहिए।
• टाइमआउट मापदंडों की उपेक्षा की जानी चाहिए

त्रुटियों से बचने के लिए, सर्वर को पहले इस फ़ंक्शन के साथ क्लाइंट की उपलब्धता का परीक्षण करना चाहिए: वास्तविक ट्रैफ़िक में, पता लगाने और जीवनचक्र के मुद्दे अक्सर NotAllowedError या AbortError के रूप में सामने आते हैं। अपेक्षित बनाम अप्रत्याशित वर्गीकरण के लिए इस WebAuthn त्रुटि गाइड का उपयोग करें, जिसमें मूल क्रेडेंशियल प्रबंधक पासकी त्रुटियाँ शामिल हैं।

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// `window.PublicKeyCredential` की उपलब्धता का मतलब है कि WebAuthn प्रयोग करने योग्य है।
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // जांचें कि क्या सशर्त मध्यस्थता (conditional mediation) उपलब्ध है।
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // WebAuthn प्रमाणीकरण प्रारंभ एंडपॉइंट को कॉल करें
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
    ...
    */
    }
}

इनपुट फ़ील्ड को एक HTML ऑटोफिल टोकन प्राप्त होना चाहिए, जो क्लाइंट को चल रहे अनुरोध में पासकीज़ को पॉप्युलेट करने का संकेत देता है। पासकीज़ के अलावा, ऑटोफिल टोकन को मौजूदा टोकन के साथ जोड़ा जा सकता है, उदा. उपयोगकर्ता नाम और पासवर्ड:

• autocomplete="username webauthn": पासकीज़ प्रदर्शित करने के अलावा, यह उपयोगकर्ता नाम ऑटोफिल का भी सुझाव देता है।
• autocomplete="current-password webauthn": पासकीज़ प्रदर्शित करने के अलावा, यह पासवर्ड ऑटोफिल के लिए भी संकेत देता है।

<label for="name">Username:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Password:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

WebAuthn सर्वर के लिए कोई अनिवार्य या मानकीकृत डेटाबेस स्कीमा नहीं है। हालाँकि, इस उदाहरण डेटाबेस स्कीमा का उपयोग आवश्यक जानकारी संग्रहीत करने और WebAuthn सर्वर की सभी कार्यक्षमता प्रदान करने के लिए किया जा सकता है:

बोल्ड विशेषताएँ न्यूनतम व्यवहार्य कार्यान्वयन के लिए अनिवार्य हैं, जबकि अन्य की आवश्यकता केवल वैकल्पिक, लेकिन सहायक सुविधाओं के लिए होती है।

• Credential ID: यह एक अद्वितीय आईडी है जो पासकी के पंजीकरण के दौरान ऑथेंटिकेटर द्वारा उत्पन्न होती है। इसका उपयोग उस वास्तविक उपयोगकर्ता खाते को देखने के लिए किया जाना चाहिए जो पासकी से जुड़ा है। इसके अतिरिक्त userHandle (user_id से) की तुलना ऑथेंटिकेशन के लिए उपयोग किए गए खाते को मान्य करने के लिए की जानी चाहिए। तुलना के लिए user.name विशेषता का उपयोग न करें क्योंकि यह समय के साथ बदल सकता है।
• User ID (user_id): रिलाइंग पार्टी द्वारा उनके सिस्टम में उपयोगकर्ता खाते का प्रतिनिधित्व करने के लिए निर्दिष्ट अद्वितीय आईडी। यह assertion-ऑब्जेक्ट के भीतर userHandle के रूप में वापस आ जाता है।

• User DisplayName (user.displayName): उपयोगकर्ता के अनुकूल, पढ़ने योग्य नाम जो आमतौर पर उपयोगकर्ता का पूरा नाम होता है। यह उपयोगकर्ता को दिखाया जाता है, लेकिन ऑथेंटिकेशन के दौरान उपयोग नहीं किया जाता है।

• User Name (user.name): अद्वितीय और पढ़ने योग्य नाम जो आमतौर पर एक ई-मेल पता या उपयोगकर्ता नाम होता है। इसे उपयोगकर्ता को दिखाया जा सकता है, लेकिन ऑथेंटिकेशन के दौरान इसका उपयोग नहीं किया जाता है।

रिलाइंग पार्टी आईडी (rpID) पासकी के भीतर संग्रहीत एक डोमेन है, जो यह सुनिश्चित करता है कि पासकी केवल सही डोमेन के लिए काम करती है (ब्राउज़र URL, नेटिव ऐप्स के लिए इस लेख को देखें)। ऑथेंटिकेशन के दौरान, ब्राउज़र URL के विरुद्ध rpID की जाँच की जाती है और केवल इन दो मामलों में अनुमति दी जाती है:

1. URL ठीक rpId से मेल खाता है या
2. URL एक सबडोमेन है जो rpId से मेल खाता है और पैरेंट डोमेन सार्वजनिक प्रत्यय सूची (Public Suffix List) में नहीं है

यहाँ (अ)मान्य संयोजनों के उदाहरण दिए गए हैं:

पासकीज़ को लागू करने के लिए उपयोगी टूल और वेबसाइटों की सूची यहाँ दी गई है।

• Passkeys Debugger: JSON के रूप में WebAuthn प्रतिक्रियाओं को डीबग करने और विभिन्न विकल्पों के साथ WebAuthn संचालन का परीक्षण करने के लिए उपकरण।
• Passkeys Glossary: पासकी से संबंधित शब्दों और अवधारणाओं की व्याख्या
• WebAuthn Specification: यह आधिकारिक WebAuthn विनिर्देश है।
• Chrome Device Log: आपके डिवाइस के WebAuthn ऑपरेशंस का लॉग दिखाने वाला टूल (केवल chrome://device-log के माध्यम से Chrome पर उपलब्ध)

तकनीकी कार्यान्वयन से परे अपने पासकी UX को अनुकूलित करने की रणनीतियों के लिए, पासकी निर्माण सर्वोत्तम प्रथाओं और पासकी लॉगिन सर्वोत्तम प्रथाओं पर हमारे गाइड देखें।

यदि आप किसी भी एप्लिकेशन में कोड की कुछ पंक्तियों के साथ पासकीज़ को लागू करना चाहते हैं, तो आप Corbado Complete (नए ऐप्स के लिए) या Corbado Connect (मौजूदा ऐप्स के लिए) का भी उपयोग कर सकते हैं।

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Authentication Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →

Conditional UI को ऑथेंटिकेशन शुरू करने से पहले PublicKeyCredential.isConditionalMediationAvailable() के माध्यम से ब्राउज़र समर्थन की जाँच करने की आवश्यकता होती है। इनपुट फ़ील्ड में autocomplete="username webauthn" HTML टोकन शामिल होना चाहिए और उपयोगकर्ता के पास एक resident key (डिस्कवरेबल क्रेडेंशियल) पंजीकृत होनी चाहिए। Conditional UI लॉगिन फ्लो को संभालने के लिए एक अलग सर्वर एंडपॉइंट की अनुशंसा की जाती है।

कम से कम, क्रेडेंशियल आईडी (पंजीकरण के दौरान ऑथेंटिकेटर द्वारा उत्पन्न) और यूजर आईडी (user_id) को संग्रहीत करें, जिसे assertion ऑब्जेक्ट में userHandle के रूप में वापस किया जाता है। संबंधित उपयोगकर्ता खाते को देखने के लिए क्रेडेंशियल आईडी का उपयोग करें और ऑथेंटिकेशन को मान्य करने के लिए userHandle की तुलना करें। तुलना के लिए user.name का उपयोग करने से बचें क्योंकि यह समय के साथ बदल सकता है।

Resident keys (डिस्कवरेबल क्रेडेंशियल्स) ऑथेंटिकेटर पर ही संग्रहीत होते हैं और ऑथेंटिकेशन के दौरान प्राप्त किए जाते हैं, जो Conditional UI के काम करने के लिए आवश्यक है। Non-resident keys सर्वर पर क्रेडेंशियल आईडी संग्रहीत करते हैं और इसे ऑथेंटिकेशन के दौरान ऑथेंटिकेटर को भेजते हैं। authenticatorSelection में residentKey फ़ील्ड "required", "preferred" या "discouraged" के मानों के साथ इस व्यवहार को नियंत्रित करता है।

userVerification फ़ील्ड यह नियंत्रित करता है कि लॉगिन के दौरान ऑथेंटिकेटर को उपयोगकर्ता को सत्यापित करना चाहिए या नहीं, जो "required", "preferred" (डिफ़ॉल्ट) या "discouraged" के मान स्वीकार करता है। जब इसे "preferred" पर सेट किया जाता है, तो उपयोगकर्ता या उनका उपकरण ऑथेंटिकेशन प्रक्रिया के दौरान सत्यापन को पूरी तरह से छोड़ सकता है, जो संभावित रूप से सुरक्षा को कमजोर करता है। इसे "required" पर सेट करने से यह सुनिश्चित होता है कि ऑथेंटिकेशन पूरा होने से पहले सत्यापन हमेशा होता है।