Vincent
Created: June 17, 2025
Updated: July 1, 2025
अटेस्टेशन तीन चीजों का उल्लेख कर सकता है (अक्सर बोलचाल की भाषा में इन्हें एक दूसरे के स्थान पर उपयोग किया जाता है, हालांकि सटीक रूप से देखने पर इनका मतलब अलग होता है):
सबसे पहले और अधिक सामान्य रूप से, क्रिप्टोग्राफ़िक क्षेत्र में अटेस्टेशन एक शब्द है जहाँ एक पक्ष दूसरे पक्ष को क्रिप्टोग्राफ़िक रूप से एक बयान "प्रमाणित" करता है।
दूसरे, WebAuthn में पंजीकरण चरण के दौरान ऑथेंटिकेटर द्वारा एक अटेस्टेशन ऑब्जेक्ट बनाया जाता है और रिलाइंग पार्टी को लौटाया जाता है। यह एक कंटेनर ऑब्जेक्ट है जिसमें निम्नलिखित जानकारी होती है:
fmt
)attStmt
- नीचे देखें)authData
)पंजीकरण की निम्नलिखित प्रक्रिया प्रवाह WebAuthn में अटेस्टेशन (ऑब्जेक्ट) की भूमिका को दर्शाता है:
{ "root": { "id": "QFPlQVypLmmx71e0tmS3IfCFky0", "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0", "response": { "attestationObject": { "fmt": "none", "attStmt": {}, "authData": { "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc", "flags": { "userPresent": true, "userVerified": true, "backupEligible": true, "backupStatus": true, "attestedData": true, "extensionData": false }, "counter": 0, "aaguid": "00000000-0000-0000-0000-000000000000", "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0", "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...", "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM", "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw" } } }, "clientDataJSON": { "type": "webauthn.create", "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp", "origin": "https://passkeys.eu", "crossOrigin": false }, "transports": ["hybrid", "internal"], "publicKeyAlgorithm": -7 }, "authenticatorAttachment": "cross-platform" } }
ऊपर दिए गए स्क्रीनशॉट में, कोई AAGUID और कोई अटेस्टेशन स्टेटमेंट प्रदान नहीं किया गया है।
सबसे महत्वपूर्ण विशेषताओं के तकनीकी विश्लेषण के लिए पढ़ना जारी रखें।
WebAuthn में, अटेस्टेशन यह सुनिश्चित करता है कि उपयोगकर्ता प्रमाणीकरण सुरक्षित और पारदर्शी है। अटेस्टेशन स्टेटमेंट के साथ, आप यह सुनिश्चित कर सकते हैं कि एक क्रेडेंशियल एक विशिष्ट ऑथेंटिकेटर / डिवाइस पर बनाया गया था।
ये अटेस्टेशन प्रकार अटेस्टेशन स्टेटमेंट को संदर्भित करते हैं (अटेस्टेशन ऑब्जेक्ट को नहीं)। इन्हें रिलाइंग पार्टी द्वारा एक वरीयता माना जाता है (इसलिए ऑथेंटिकेटर अलग तरह से व्यवहार कर सकता है क्योंकि यह केवल एक वरीयता है)।
none
): उन मामलों के लिए जहां गोपनीयता अत्यंत महत्वपूर्ण है या
सिंक किए गए डिवाइस उपयोग में हैं, यह प्रकार डिवाइस के बारे में कोई जानकारी प्रदान नहीं
करता है, जिससे उपयोगकर्ता की गोपनीयता बनी रहती है। इस मान का उपयोग करने का एक और कारण
सर्टिफिकेट अथॉरिटी (CA) के लिए राउंडट्रिप बचाना हो सकता है। none
डिफ़ॉल्ट मान भी है।indirect
): रिलाइंग पार्टी
अटेस्टेशन प्राप्त करना पसंद करती है लेकिन क्लाइंट को यह तय करने की अनुमति देती है कि
अटेस्टेशन स्टेटमेंट कैसे प्राप्त करें। क्लाइंट उपयोगकर्ता की गोपनीयता की रक्षा के लिए
ऑथेंटिकेटर-जनित अटेस्टेशन स्टेटमेंट को अनाम अटेस्टेशन स्टेटमेंट से बदल सकता है।direct
): यह सबसे पारदर्शी रूप है। यहां,
रिलाइंग पार्टी ऑथेंटिकेटर को बताती है कि वह एक अटेस्टेशन
स्टेटमेंट चाहती है, ताकि रिलाइंग पार्टी को डिवाइस के बारे में
विस्तृत जानकारी मिल सके, जिसमें उसका ब्रांड, मॉडल और अन्य विवरण शामिल हैं। हालांकि यह
उच्चतम पारदर्शिता प्रदान करता है, यह कुछ परिदृश्यों में गोपनीयता संबंधी चिंताएं बढ़ा
सकता है या सिंक किए गए क्रेडेंशियल्स के लिए वास्तव में प्रयोग करने योग्य नहीं हो सकता
है।enterprise
): रिलाइंग पार्टी एक
अटेस्टेशन स्टेटमेंट प्राप्त करना चाहती है जिसमें अद्वितीय पहचान जानकारी शामिल हो सकती
है। इस प्रकार का अटेस्टेशन आमतौर पर उन व्यवसायों या संगठनों में उपयोग किया जाता है जो
विशिष्ट डिवाइस / ऑथेंटिकेटर्स का ट्रैक रखना चाहते हैं। वेब
ब्राउज़र (उपयोगकर्ता एजेंट) को यह विस्तृत अटेस्टेशन तब तक प्रदान नहीं करना चाहिए जब तक
कि उनकी सेटिंग्स अनुरोध करने वाली पार्टी के लिए विशेष रूप से इसकी अनुमति न दें। यदि
सेटिंग्स इसकी अनुमति देती हैं, तो ब्राउज़र को डिवाइस को यह बताना चाहिए कि इसकी आवश्यकता
कब है (प्रक्रिया की शुरुआत में) कि इस विशिष्ट प्रकार के अटेस्टेशन का अनुरोध किया जा रहा
है। ब्राउज़र को फिर डिवाइस की अद्वितीय आईडी और अटेस्टेशन प्रूफ को ठीक वैसे ही पास करना
चाहिए जैसे वे उन्हें रिलाइंग पार्टी को प्राप्त करते हैं।अटेस्टेशन ऑब्जेक्ट में कई विशेषताएँ होती हैं, यहाँ कुछ चुनिंदा विशेषताओं का संक्षिप्त विवरण दिया गया है:
"attestationObject": { "fmt": "none", "attStmt": {}, "authData": { "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc", "flags": { "userPresent": true, "userVerified": true, "backupEligible": true, "backupStatus": true, "attestedData": true, "extensionData": false }, "counter": 0, "aaguid": "00000000-0000-0000-0000-000000000000", "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0", "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...", "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM", "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw" } }
attestationObject एक CBOR एन्कोडेड ऑब्जेक्ट है, जिसमें नए बनाए गए क्रेडेंशियल्स, पब्लिक की और अन्य प्रासंगिक डेटा के बारे में जानकारी होती है:
ऊपर दिए गए अटेस्टेशन ऑब्जेक्ट के विपरीत जहां पठनीयता के कारणों से attStmt
को खाली छोड़
दिया गया था, एक भरा हुआ अटेस्टेशन स्टेटमेंट ऐसा दिखेगा।
{ "alg": -65535, "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ", "ver": "2.0", "x5c": [ "MIIFwDCCA6oIaK6tZ7M", "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM" ], "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w", "certInfo": "_1RDR4AXAniCekfsiDI" }
alg
: alg प्रॉपर्टी क्रिप्टोग्राफ़िक एल्गोरिथम पहचानकर्ता को इंगित करती है जिसका उपयोग
ऑथेंटिकेटर द्वारा अटेस्टेशन स्टेटमेंट पर हस्ताक्षर करने के लिए किया जाता है।sig
: sig प्रॉपर्टी में ऑथेंटिकेटर द्वारा उत्पन्न डिजिटल हस्ताक्षर होता है। इस
हस्ताक्षर का उपयोग अटेस्टेशन स्टेटमेंट की प्रामाणिकता को सत्यापित करने के लिए किया जाता
है।ver
: ver प्रॉपर्टी अटेस्टेशन स्टेटमेंट फॉर्मेट के संस्करण को निर्दिष्ट करती है।x5c
: x5c ऐरे में एक या अधिक X.509 प्रमाणपत्र होते हैं जो एक प्रमाणन पथ बनाते हैं, जो
अटेस्टेशन को मान्य करने में सहायता करता है।pubArea
: pubArea प्रॉपर्टी में पब्लिक की और ऑथेंटिकेटर की
विशेषताओं के बारे में विस्तृत जानकारी होती है।certInfo
: certInfo प्रॉपर्टी में आमतौर पर एक विश्वसनीय पक्ष द्वारा ऑथेंटिकेटर के
प्रमाणीकरण के बारे में जानकारी शामिल होती है।"clientDataJSON": { "type": "webauthn.create", "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp", "origin": "https://www.passkeys-debugger.io", "crossOrigin": false }
clientDataJSON
के बारे में अधिक जानकारी
संबंधित शब्दावली लेख में पढ़ें।
"transports": [ "hybrid", "internal" ]
transports-प्रॉपर्टी उन तंत्रों को इंगित करती है जिनके माध्यम से एक ऑथेंटिकेटर क्लाइंट के साथ संवाद कर सकता है। कुछ सामान्य, नमूना मान संयोजन हैं:
"transports": ["internal","hybrid"]
: पासकी का उपयोग
प्लेटफ़ॉर्म ऑथेंटिकेटर (जैसे Face ID, Touch ID,
Windows Hello) से या क्रॉस-डिवाइस प्रमाणीकरण (
QR कोड और ब्लूटूथ का उपयोग करके) के माध्यम से किया
जा सकता है।"transports": ["internal"]
: पासकी का उपयोग
प्लेटफ़ॉर्म ऑथेंटिकेटर (जैसे Face ID, Touch ID,
Windows Hello) से किया जा सकता है।transports
प्रॉपर्टी सेट नहीं है: डिफ़ॉल्ट व्यवहार जो कोई संकेत नहीं देता है।WebAuthn में अटेस्टेशन (अटेस्टेशन स्टेटमेंट) महत्वपूर्ण है क्योंकि यह एक ऑथेंटिकेटर की वास्तविकता का प्रमाण प्रदान करता है। यह सुनिश्चित करता है कि प्रमाणीकरण प्रक्रिया एक विश्वसनीय डिवाइस द्वारा की जाती है, जिससे संभावित सुरक्षा खतरों से बचाव होता है।
Ben Gould
Head of Engineering
I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.
3,000+ डेवलपर्स Corbado पर भरोसा करते हैं और पासकी के साथ इंटरनेट को सुरक्षित बनाते हैं। कोई प्रश्न हैं? हमने पासकी पर 150+ ब्लॉग पोस्ट लिखे हैं।
पासकी समुदाय में शामिल होंहाँ, क्योंकि पासकी को डिवाइसों के बीच सिंक किया जा सकता है (जैसे iPhone से MacBook तक
Keychain के माध्यम से), रिलाइंग पार्टी अब वास्तव
में यह निर्धारित नहीं कर सकती हैं कि कौन सा प्रमाणित डिवाइस वास्तव में किसी ऐप या वेबसाइट
में लॉग इन कर रहा है। इसलिए, Apple और Google ने फैसला किया है कि सिंक की गई पासकी के लिए,
वे अब अटेस्टेशन स्टेटमेंट प्रदान नहीं करेंगे। हालांकि, रिलाइंग पार्टी के लिए UX को बेहतर
बनाने और उन्हें Apple और Google इकोसिस्टम (iCloud Keychain और
Google Password Manager) से पासकी को पहचानने
और प्रदर्शित करने का अवसर देने के लिए, AAGUID अभी भी प्रदान किया जाएगा
(जब तक कि WebAuthn सर्वर सेटिंग्स में PublicKeyCredentialCreationOptions
के लिए
अटेस्टेशन direct
या indirect
पर सेट है)। विवरण के लिए यह
GitHub मुद्दा देखें।
यदि आप अपनी वेबसाइट और ऐप में पासकी प्रमाणीकरण को
एकीकृत करना चाहते हैं, और अपने उपयोगकर्ताओं को एक बेहतरीन पासकी UX प्रदान करना चाहते हैं,
तो आपको निम्नलिखित पर विचार करना चाहिए। हम मानते हैं कि आप अपना समाधान मुख्य रूप से एक ऐसे
परिदृश्य के लिए बनाते हैं जहां आपके अधिकांश उपयोगकर्ता Windows,
iOS, macOS या
Android ऑपरेटिंग सिस्टम का उपयोग करते हैं। इसके
अलावा, हम मानते हैं कि अधिकांश पासकी (Windows को छोड़कर) सिंक की गई पासकी हैं। चूंकि न तो
iOS, macOS और न ही Android अब एक अटेस्टेशन
स्टेटमेंट भेजते हैं, इसलिए एक ऑथेंटिकेटर का वास्तविक सत्यापन अब उपयोग नहीं किया जाता है
(Windows के लिए यह अभी भी काम करता है, शायद इसलिए कि Windows अभी तक
Windows Hello के माध्यम से सिंक की गई पासकी की पेशकश नहीं करता
है)। हालांकि, AAGUID प्राप्त करने के लिए, जैसे कि खाता सेटिंग्स में
बेहतर पासकी प्रबंधन के लिए, हम अटेस्टेशन वरीयता को indirect
पर सेट करने की सलाह देते
हैं, क्योंकि यह अभी भी AAGUID प्राप्त करने की अनुमति देगा जबकि
अटेस्टेशन स्टेटमेंट या तो भेजा जाता है (Windows) या नहीं भेजा जाता है (iOS, macOS,
Android)।
FIDO मेटाडेटा सेवा विभिन्न ऑथेंटिकेटर्स के लिए मेटाडेटा का एक भंडार प्रदान करती है। अटेस्टेशन के दौरान, इस सेवा से ऑथेंटिकेटर के बारे में विवरण प्राप्त करने और मान्य करने के लिए पूछताछ की जा सकती है, जिससे प्रक्रिया की सटीकता और विश्वसनीयता बढ़ती है। FIDO मेटाडेटा सेवा अटेस्टेशन स्टेटमेंट (अटेस्टेशन ऑब्जेक्ट नहीं) की जाँच करती है।
हाँ, प्रत्यक्ष अटेस्टेशन (अटेस्टेशन स्टेटमेंट में), डिवाइस के बारे में विस्तृत जानकारी प्रदान करके उच्चतम पारदर्शिता प्रदान करते हुए, कुछ परिदृश्यों में गोपनीयता संबंधी चिंताएँ बढ़ा सकता है। अटेस्टेशन के प्रकार का चयन करते समय पारदर्शिता बनाम गोपनीयता की आवश्यकता का आकलन करना महत्वपूर्ण है।
WebAuthn विभिन्न प्रकार की अटेस्टेशन वरीयताएँ प्रदान
करता है - कोई नहीं, अप्रत्यक्ष, प्रत्यक्ष और एंटरप्राइज़। उन परिदृश्यों के लिए जहां
उपयोगकर्ता की गोपनीयता
महत्वपूर्ण है, attestation=none
का उपयोग किया जा सकता है, जो डिवाइस के बारे में कोई
विवरण प्रदान नहीं करता है, जिससे उपयोगकर्ता की गोपनीयता सुरक्षित रहती है।
Table of Contents
Enjoyed this read?
🤝 Join our Passkeys Community
Share passkeys implementation tips and get support to free the world from passwords.
🚀 Subscribe to Substack
Get the latest news, strategies, and insights about passkeys sent straight to your inbox.