ऑथेंटिकेशन प्रोसेस माइनिंग (Authentication Process Mining): अगला CIAM अनुशासन

1. परिचय (Introduction)#

पासकी (Passkeys) CIAM को आगे बढ़ा रहे हैं। बेहतरीन टीमें एंड-टू-एंड लॉगिन जर्नी को इंस्ट्रूमेंट करना, उन त्रुटियों को वर्गीकृत करना जिन्हें उन्होंने पहले कभी लॉग नहीं किया था, और पहली बार क्लाइंट-साइड टेलीमेट्री (client-side telemetry) को देखना शुरू कर रही हैं। पहचान (identity) टीमों का एक बड़ा हिस्सा अभी तक वहाँ नहीं पहुँचा है: कोई वास्तविक ऑथेंटिकेशन ऑब्जर्वेबिलिटी लेयर नहीं है, कोई प्रति-सत्र इवेंट ग्राफ़ नहीं है, कोई क्लाइंट-साइड सेरेमनी डेटा नहीं है। सर्वर-साइड प्रयास, सफलता और विफलता अभी भी पूरी तस्वीर बने हुए हैं।

ऑथेंटिकेशन प्रोसेस माइनिंग अगला तार्किक कदम है लेकिन केवल तभी जब वह अंतर्निहित (underlying) इवेंट डेटा मौजूद हो। ऑब्जर्वेबिलिटी लेयर के बिना, माइन करने के लिए कुछ भी नहीं है। इसके होने पर, एक नया अनुशासन उपलब्ध हो जाता है। यह सीधे बिजनेस प्रोसेस माइनिंग से उधार लेता है, जिसने 2010 के दशक में कच्चे ERP इवेंट लॉग्स को अनुकूलित वर्कफ़्लो में बदल दिया था। पहचान पर लागू होने पर, यह डिज़ाइन की गई लॉगिन जर्नी की तुलना वास्तविक जर्नी (lived journey) से करता है, विचलन (deviation) रास्तों को सामने लाता है और फिर फाइन-ग्रेन्ड स्टेप-अप ऑथेंटिकेशन (step-up authentication), सप्रेशन रूल्स (suppression rules) या UX बदलावों (UX changes) के साथ इस अंतर को पाटता है जिन्हें एंड-टू-एंड मापा जाता है।

यह लेख उस रूपरेखा को फिर से परिभाषित करता है जिसे CIAM टीमों को ऑथेंटिकेशन ऑब्जर्वेबिलिटी (authentication observability) लेयर के ऊपर बनाना चाहिए।

1.1 प्रश्न जिनका उत्तर यह लेख देता है#

इस लेख में, हम निम्नलिखित प्रश्नों से निपटते हैं:

1. प्रोसेस माइनिंग ने BPM के लिए क्या किया, और ऑथेंटिकेशन के लिए इसके क्या प्रत्यक्ष समानांतर (direct parallel) हैं?
2. पासकी रोलआउट्स (passkey rollouts) ने इस अंतर को क्यों उजागर किया, और केवल ऑथेंटिकेशन लॉग्स अपने आप में पर्याप्त क्यों नहीं थे?
3. एक ऑथेंटिकेशन प्रोसेस-माइनिंग इवेंट मॉडल वास्तव में एंड-टू-एंड कैसा दिखता है?
4. प्रोसेस माइनिंग फाइन-ग्रेन्ड स्टेप-अप ऑथेंटिकेशन (step-up authentication) और ऑथराइजेशन से कैसे जुड़ता है?
5. CIAM वेंडर लैंडस्केप और उन पहचान टीमों के लिए इसका क्या अर्थ है जिनके पास पहले से ही एक IDP है?

2. प्रोसेस माइनिंग ने BPM के लिए क्या किया#

2.1 इवेंट लॉग्स से अनुकूलित प्रक्रियाओं (Optimized Processes) तक#

बिजनेस प्रोसेस माइनिंग इस एहसास से उभरा कि प्रत्येक ERP, CRM या टिकटिंग सिस्टम इवेंट लॉग्स लिखता है जो पुनर्निर्माण किए जाने पर वास्तविक वर्कफ़्लो को प्रकट करते हैं, न कि उस वर्कफ़्लो को जो विकी पर है। एक खरीद आदेश जिसे तीन अप्रूवर्स से होकर गुजरना था, वह 40% समय उनमें से दो के बिना ही रूट हो गया। एक क्लेम्स फ़्लो जिसे एक सीधी रेखा के रूप में डॉक्युमेंट किया गया था, वह 18% क्लेम्स के लिए पाँच बार वापस लूप हुआ। Celonis द्वारा लोकप्रिय बनाए गए प्रोसेस-माइनिंग टूल्स ने टाइमस्टैम्प्ड इवेंट्स से उन ग्राफ़ को फिर से बनाया और ऑपरेटरों को एक नया प्रश्न पूछने दिया: वास्तविक प्रक्रिया (lived process) डिज़ाइन की गई प्रक्रिया से कहाँ विचलित होती है, और उस विचलन की क्या लागत है?

2.2 ऑथेंटिकेशन में समानांतर#

ऑथेंटिकेशन की संरचना भी समान है। हर लॉगिन इवेंट्स का एक टाइमस्टैम्प्ड अनुक्रम है: पेज लोड हुआ, आइडेंटिफ़ायर दर्ज किया गया, चुनौती का चयन किया गया, बायोमेट्रिक प्रॉम्प्ट किया गया, एसेर्शन (assertion) वापस किया गया। संरचनात्मक समानांतर सटीक है। व्यावहारिक अंतर यह है कि, ERP या CRM के विपरीत, यह इवेंट डेटा अभी तक आपके IDP लॉग्स में नहीं रहता है - कम से कम उस विस्तृत रूप में नहीं जिसकी प्रोसेस माइनिंग को आवश्यकता होती है। IDPs साइन-इन परिणामों और उपयोग की गई विधि को रिकॉर्ड करते हैं। वे इसके तहत क्लाइंट-साइड सेरेमनी को रिकॉर्ड नहीं करते हैं: Conditional UI इन्वोकेशन, बायोमेट्रिक प्रॉम्प्ट्स, क्रेडेंशियल मैनेजर (credential manager) चयन, सर्वर तक अनुरोध पहुँचने से पहले ही मूक परित्याग। उस प्री-एसेर्शन लेयर को फ़्रंट-एंड SDK लेयर पर इंस्ट्रूमेंट किया जाना चाहिए और प्रोसेस माइनिंग के काम करने से पहले एक प्रति-सत्र (per-session) ग्राफ़ में फिर से जोड़ा जाना चाहिए।

एक बार जब डेटा आ जाता है, तो वही तकनीकें लागू होती हैं: डिज़ाइन की गई पासकी जर्नी बनाम वास्तविक पासकी जर्नी, डिज़ाइन किया गया रिकवरी फ़्लो बनाम वास्तविक रिकवरी फ़्लो, डिज़ाइन किया गया स्टेप-अप बनाम वास्तविक स्टेप-अप। इस कार्य के इर्द-गिर्द अकादमिक अनुशासन परिपक्व हो रहा है। IEEE Task Force on Process Mining का Process Mining Manifesto एक उपयोगी प्रविष्टि बिंदु है, जो कन्फर्मंस चेकिंग, वेरिएंट एनालिसिस और एन्हांसमेंट को तीन मुख्य तकनीकों के रूप में प्रस्तुत करता है। प्रत्येक ऑथेंटिकेशन पर वन-टू-वन मैप करता है।

3. पासकी रोलआउट्स ने इस अंतर को क्यों उजागर किया#

3.1 पासकीज़ टीमों को फ़्रंटएंड लॉगिंग पर पुनर्विचार करने के लिए मजबूर करते हैं#

क्लासिकल पासवर्ड ऑथ (auth) ने सर्वर-साइड तीन चीजें लॉग कीं: प्रयास, सफलता, विफलता। एक पासवर्ड सिस्टम को चलाने के लिए इतना पर्याप्त है, क्योंकि विफलता मोड सरल है: उपयोगकर्ता ने एक स्ट्रिंग गलत टाइप की, और अगला प्रयास या तो काम कर गया या नहीं किया। पासकीज़ के साथ, महत्वपूर्ण क्षण फ़्रंटएंड पर चले जाते हैं: Conditional UI फ़ायरिंग, ब्राउज़र का यह निर्णय लेना कि प्रॉम्प्ट दिखाना है या नहीं, क्रेडेंशियल मैनेजर (credential manager) द्वारा एक विकल्प देना, बायोमेट्रिक चुनौती का सफल होना या खारिज कर दिया जाना। यह सब उपभोक्ता के डिवाइस पर होता है, इससे पहले कि एसेर्शन (assertion) कभी भी बैकएंड तक पहुँचे।

यह बदलाव ही कारण है कि कई टीमें अब इस बात पर पुनर्विचार कर रही हैं कि वे क्लाइंट-साइड व्यवहार को कैसे लॉग करती हैं। फ़्रंटएंड इंस्ट्रूमेंटेशन के बिना, वे यह नहीं देख सकते कि उपयोगकर्ता क्यों छोड़ रहे हैं, उपयोगकर्ता लॉगिन से पहले क्या कदम उठाते हैं, या वास्तव में क्या हुआ जब कोई लॉगिन प्रयास पूरा नहीं हुआ। सर्वर लॉग केवल अनुपस्थिति दिखाते हैं, कारण नहीं। पूरी इवेंट टैक्सोनॉमी के लिए ऑथेंटिकेशन ऑब्जर्वेबिलिटी (authentication observability) पर हमारा डीप डाइव देखें।

3.2 डिज़ाइन की गई जर्नी और वास्तविक जर्नी के बीच अंतर#

एक बार जब टीमों के पास क्लाइंट-साइड इवेंट्स आ गए, तो वे कुछ नया देख सकते थे: डिज़ाइन की गई पासकी जर्नी (लॉगिन पर लैंड करें, पासकी बटन (passkey button) देखें, टैप करें, ऑथेंटिकेट करें, काम पूरा) का उपयोग शायद 30% योग्य उपयोगकर्ताओं द्वारा किया गया था। अन्य 70% लोग पासवर्ड फ़ील्ड्स, सोशल लॉगिन (social login), मैजिक लिंक्स के माध्यम से भटक गए या पूरी तरह से छोड़ दिया। वह एक प्रोसेस-माइनिंग समस्या है, लॉगिंग समस्या नहीं। अतिरिक्त WebAuthn त्रुटि कोड्स की कोई भी मात्रा अपने आप में इस अंतर को कम नहीं कर सकती थी।

3.3 ऑथेंटिकेशन लॉग्स कभी भी पर्याप्त क्यों नहीं थे#

केवल ऑथेंटिकेशन लॉग्स आपको परिणाम बताते हैं। वे आपको रास्ते नहीं बताते हैं। सभी विधियों में 92% लॉगिन सफलता दर (login success rate) पासकी पथ पर 40% परित्याग दर और पासवर्ड पथ पर 15% परित्याग दर को छुपा सकती है, जो समग्र रूप से "ठीक" लगती है। प्रोसेस माइनिंग इस औसतीकरण (averaging) को अस्वीकार करता है। यह प्रत्येक वेरिएंट को अलग से देखने और फिर आवृत्ति (frequency), लागत और विफलता दर के आधार पर वेरिएंट्स को रैंक करने पर जोर देता है।

4. ऑथेंटिकेशन प्रोसेस माइनिंग वास्तव में कैसा दिखता है#

4.1 इवेंट मॉडल: प्रक्रियाएँ, इवेंट्स और परिणाम वर्गीकरण#

विश्लेषण की इकाई एक भी इवेंट नहीं है, यह एक प्रक्रिया (process) है: उपभोक्ता के डिवाइस पर एक पूर्ण लॉगिन या क्रेडेंशियल-अपेंड (credential-append) प्रयास, ऑथ सर्फेस लोड होने के क्षण से लेकर सत्र के पूरा होने या छोड़ दिए जाने के क्षण तक। प्रत्येक प्रक्रिया में सूक्ष्म-स्तरीय (fine-grained) इवेंट्स की एक धारा होती है, इसमें पहचान करने वाला मेटाडेटा होता है और एक परिणाम वर्गीकरण में समाप्त होता है जो बाइनरी "सफलता या विफलता" से कहीं अधिक समृद्ध है।

प्रक्रिया मेटाडेटा (Process metadata)। प्रत्येक प्रक्रिया में एक प्रोसेस ID और एक टाइमस्टैम्प होता है। यह एक एप्लिकेशन, एक OS, एक ब्राउज़र और एक डिवाइस ब्रांड से जुड़ा होता है। इसे एक विज़िटर श्रेणी (वास्तविक उपयोगकर्ता, मैनुअल टेस्टर, ऑटोमेटेड टेस्टर, अभी तक वर्गीकृत नहीं) के साथ टैग किया जाता है ताकि किसी भी मीट्रिक की गणना करने से पहले ऑटोमेशन और बॉट ट्रैफ़िक को अलग किया जा सके। इसमें एक प्रक्रिया स्कोर और एक इवेंट काउंट भी होता है, जो "यह विशेष सत्र कितना जटिल था" इसके लिए दो सबसे सरल संकेत हैं।

लॉगिन इनिशिएशन (Login initiation)। हर प्रक्रिया रिकॉर्ड करती है कि प्रवाह कैसे शुरू किया गया था। मुख्य इनिशिएशन प्रकार text-field (उपयोगकर्ता ने अपना आइडेंटिफ़ायर टाइप किया), one-tap (संग्रहीत आइडेंटिफ़ायर का पुनः उपयोग किया गया) और cui (Conditional UI ने स्पष्ट बटन क्लिक के बिना एक क्रेडेंशियल प्रस्तुत किया) हैं। इनिशिएशन एक आयाम है, मीट्रिक नहीं: एक ही डिप्लॉयमेंट cui कोहोर्ट पर text-field कोहोर्ट की तुलना में बहुत अलग दिख सकता है, और उनके पार औसतीकरण (averaging) ठीक उसी व्यवहार को छुपाता है जिसे प्रोसेस माइनिंग को प्रकट करना होता है।

परिणाम वर्गीकरण (Outcome classification)। "सफलता" या "विफलता" के बजाय, परिणाम कई क्लासों में से एक होता है जो एक अलग व्यवहार को मैप करता है। पासकीज़ के लिए एक उदाहरण निम्नलिखित है:

• completed - सेरेमनी समाप्त हो गई और उपयोगकर्ता ऑथेंटिकेटेड है।
• filtered-explicit-abort - उपयोगकर्ता ने एक प्रॉम्प्ट देखा और स्पष्ट रूप से रद्द कर दिया।
• filtered-implicit-abort - उपयोगकर्ता बिना निर्णय लिए दूर चला गया या टाइम आउट हो गया।
• filtered-passkey-intel - क्लाइंट-साइड इंटेलिजेंस लेयर ने जानबूझकर पासकी पथ को दबा दिया, आमतौर पर क्योंकि डिवाइस/OS कॉम्बिनेशन के टूटे होने के रूप में जाना जाता है।
• filtered-no-start - प्रवाह कभी भी एंट्री स्टेप से आगे नहीं बढ़ा।
• not-loaded - ऑथ सर्फेस कभी लोड नहीं हो पाया।

अपेंड सेरेमनी (क्रेडेंशियल क्रिएशन) में एक समानांतर वर्गीकरण है, जिसमें एक completed-exclude-credentials केस शामिल है जब उपयोगकर्ता के पास पहले से ही एक क्रेडेंशियल होता है।

फ़नल (Funnel) और इन्वेंट्री लेयर्स। प्रक्रियाओं के ऊपर, दो समग्र (aggregate) लेयर्स मायने रखती हैं। एक फ़नल लेयर समय के साथ प्रक्रियाओं को परिणाम, इनिशिएशन, कंप्लीशन स्थिति, OS और एप्लिकेशन के अनुसार बकेट करती है, लॉगिन और अपेंड दोनों के लिए। एक क्रेडेंशियल इन्वेंट्री लेयर सिंक स्थिति (सिंक किए गए बनाम सिंक नहीं किए गए), ट्रांसपोर्ट (internal, hybrid, usb, nfc, ble, smart-card), ऑथेंटिकेटर (authenticator) (Apple, Google Password Manager, iCloud Keychain, Windows Hello, 1Password, Bitwarden, Dashlane, YubiKey), OS और ब्राउज़र द्वारा मौजूदा पासकीज़ को समूहीकृत करती है। इन्वेंट्री लेयर के बिना यह पूछना असंभव है कि क्या कोई दिया गया विचलन वेरिएंट किसी विशिष्ट क्रेडेंशियल मैनेजर या सिंक स्थिति पर केंद्रित है।

यह वह न्यूनतम आकार है जो प्रोसेस माइनिंग को प्रबंधनीय (tractable) बनाता है। प्रत्येक इवेंट में समूहीकृत, फ़िल्टर और रैंक किए जाने के लिए पर्याप्त मेटाडेटा होता है। प्रत्येक प्रक्रिया को व्यक्तिगत रूप से ट्रैक किया जा सकता है, जो कि नीचे दिए गए उदाहरणों को सक्षम बनाता है।

4.2 हैप्पी पाथ बनाम विचलन विश्लेषण (Deviation Analysis)#

एक बार जब इवेंट्स को प्रति सत्र एक निर्देशित ग्राफ़ (directed graph) के रूप में संग्रहीत कर लिया जाता है, तो आप प्रोसेस-माइनिंग का प्रश्न पूछ सकते हैं: कितने प्रतिशत सत्र हैप्पी पाथ का अनुसरण करते हैं, और जो ऐसा नहीं करते हैं, उनके लिए आवृत्ति द्वारा रैंक किए गए शीर्ष पांच विचलन वेरिएंट्स क्या हैं? हमारे एनालिटिक्स डेटा (analytics data) में, शीर्ष पांच वेरिएंट्स आमतौर पर सभी विचलनों का 85% हिस्सा होते हैं। उनमें से दो को ठीक करने से आमतौर पर हैप्पी पाथ पर किसी भी A/B टेस्ट की तुलना में संख्याएँ अधिक चलती हैं।

4.3 कोहोर्ट ड्रिफ्ट डिटेक्शन#

वेरिएंट्स ड्रिफ्ट करते हैं (बदलते हैं)। एक ब्राउज़र अपडेट, एक OS रोलआउट, एक क्रेडेंशियल मैनेजर (credential manager) परिवर्तन पहले के मामूली वेरिएंट को अचानक हावी (dominant) कर सकता है। कोहोर्ट ड्रिफ्ट डिटेक्शन केवल कुल सफलता दर को देखने के बजाय, समय के साथ प्रति डिवाइस/OS/ब्राउज़र कोहोर्ट के वेरिएंट डिस्ट्रीब्यूशन को देखने का अनुशासन है। इसी तरह टीमें शांत प्रतिगमन (silent regressions) को तिमाहियों के बजाय घंटों में पकड़ती हैं।

5. प्रोसेस माइनिंग से फाइन-ग्रेन्ड स्टेप-अप तक#

5.1 स्टेप-अप का कम उपयोग क्यों हुआ है#

स्टेप-अप ऑथेंटिकेशन (Step-up authentication) एक दशक से अधिक समय से मौजूद है। इसका कम उपयोग किया गया है क्योंकि अधिकांश टीमें जोखिम की परवाह किए बिना उसी तरह से स्टेप अप करती हैं: थ्रेशोल्ड (सीमा) से ऊपर के प्रत्येक लेनदेन पर OTP लागू करना। यह एक जोखिम-स्कोर (risk-scored) निर्णय नहीं बल्कि एक ब्लंट नियम है। यह संदिग्ध 5% को रोकने के लिए 95% वैध उच्च-मूल्य वाले लेनदेनों पर घर्षण (friction) पैदा करता है।

5.2 जोखिम-स्कोर की गई जर्नीज़ (Risk-scored Journeys)#

प्रोसेस-माइनिंग डेटा के साथ, आप एक सत्र को लगातार स्कोर कर सकते हैं। डिवाइस रेपुटेशन, कोहोर्ट बेसलाइन सफलता दर, दिन-के-समय की विसंगतियाँ (time-of-day anomalies), उपयोगकर्ता के अपने ऐतिहासिक पथ से विचलन, क्रेडेंशियल मैनेजर आइडेंटिटी, IP रेपुटेशन। जोखिम स्कोर तब एक फाइन-ग्रेन्ड स्टेप-अप निर्णय को संचालित करता है: जब सत्र का जोखिम स्कोर लेनदेन मूल्य सीमा से अधिक हो तभी दूसरे कारक (second factor) की आवश्यकता हो। उच्च-मूल्य वाले लेनदेनों के लिए कम जोखिम वाले सत्र पास हो जाते हैं। कम-मूल्य वाले लेनदेनों के लिए उच्च-जोखिम वाले सत्रों को स्टेप-अप किया जाता है।

6. CIAM वेंडर लैंडस्केप के लिए इसका क्या अर्थ है#

6.1 एक विशेषज्ञ अनुशासन के रूप में जर्नी डिज़ाइन#

पहचान उद्योग ने ऐतिहासिक रूप से IDP के भीतर जर्नी डिज़ाइन को बंडल किया है। Okta, Ping, ForgeRock, Auth0 और अन्य के अंदर ऑर्केस्ट्रेशन इंजन आपको फ़्लो कॉन्फ़िगर करने देते हैं। वे जो अच्छी तरह से नहीं करते हैं वह है उन्हें ऑब्जर्व करना। यह बेमेल (mismatch) ही वह है जो एक विशेषज्ञ एनालिटिक्स लेयर के लिए जगह खोलता है।

6.2 कोई भी IDP इसे मूल रूप से शिप क्यों नहीं करेगा#

IDP वेंडर कंट्रोल प्लेन के लिए अनुकूलित करते हैं: कौन साइन इन कर सकता है, किस क्रेडेंशियल के साथ, किस पॉलिसी के तहत। प्रोसेस माइनिंग एक डेटा-प्लेन अनुशासन है: हर इवेंट, बड़े पैमाने पर, OS/ब्राउज़र/क्रेडेंशियल-मैनेजर कॉम्बिनेशन्स में सामान्यीकृत। इवेंट वॉल्यूम, कार्डिनैलिटी और क्रॉस-कस्टमर बेसलाइन सभी एक मूल IDP बिल्ड के खिलाफ काम करते हैं। SDK लेयर पर लागू समान पैटर्न के लिए पासकीज़ के लिए हमारे बाय-बनाम-बिल्ड गाइड (buy-vs-build guide for passkeys) में फ़ील्ड नोट्स देखें।

6.3 नई श्रेणी के रूप में एनालिटिक्स लेयर#

जो उभरता है वह एक पतली एनालिटिक्स और एडॉप्शन लेयर है जो IDP के ऊपर बैठती है, फ़्रंट-एंड से इवेंट्स ग्रहण करती है, उन्हें क्रॉस-डिप्लॉयमेंट बेसलाइन के विरुद्ध सामान्यीकृत करती है और ऑर्केस्ट्रेशन निर्णयों में वापस फ़ीड करती है। यह IDP की जगह नहीं लेती है। यह IDP को मापने योग्य बनाती है।

7. Corbado ऑथेंटिकेशन प्रोसेस माइनिंग में कैसे मदद करता है#

Corbado मापन और एडॉप्शन लेयर प्रदान करता है जो मौजूदा IDPs के ऊपर बैठती है। यह Okta, Auth0, Ory, ForgeRock और कस्टम स्टैक्स को बिना बदले उनके साथ एकीकृत (integrate) होता है। यह विशेष रूप से प्रोसेस-माइनिंग क्षमता को जोड़ता है:

• एंड-टू-एंड इवेंट टैक्सोनॉमी। क्लाइंट-साइड SDK पेज लोड से लेकर एसेर्शन तक पूरी सेरेमनी को कैप्चर करता है, जिसमें प्री-आइडेंटिफ़ायर इवेंट्स, Conditional UI इन्वोकेशन और क्रेडेंशियल मैनेजर चयन शामिल हैं।
• आउट ऑफ़ द बॉक्स वेरिएंट एनालिसिस। प्लेटफ़ॉर्म प्रति कोहोर्ट जर्नी ग्राफ़ का पुनर्निर्माण करता है और आवृत्ति, रिकवरी अवसर और लागत के आधार पर विचलन वेरिएंट्स को रैंक करता है।
• कोहोर्ट ड्रिफ्ट अलर्टिंग। जब एक विशिष्ट OS, ब्राउज़र या क्रेडेंशियल मैनेजर के लिए एक वेरिएंट डिस्ट्रीब्यूशन शिफ्ट होता है, तो प्लेटफ़ॉर्म इसे दिन-2 की समस्या (day-2 problem) बनने से पहले फ़्लैग करता है।
• क्रॉस-डिप्लॉयमेंट बेसलाइन्स। क्योंकि Corbado ग्राहक परिवेशों में अनामित (anonymized) डेटा एकत्र करता है, एक डिप्लॉयमेंट में सामने आई नई त्रुटियों या रिग्रेशन्स को आपके यहाँ पहुँचने से पहले ही वर्गीकृत और डॉक्युमेंट कर लिया जाता है। पूरे दृष्टिकोण के लिए जानें Corbado क्यों (why Corbado) देखें।
• ऑर्केस्ट्रेशन में फ़ीडबैक। जोखिम-स्कोर वाले स्टेप-अप निर्णयों और सप्रेशन रूल्स को वापस IDP में धकेला जा सकता है या डायनामिक किल-स्विचेस और कोहोर्ट-विशिष्ट नज़िंग (nudging) सहित एडॉप्शन लेयर (adoption layer) पर नियंत्रित किया जा सकता है।

8. निष्कर्ष (Conclusion)#

पासकीज़ गंतव्य (destination) नहीं थे। वे इंस्ट्रूमेंटेशन वेज (instrumentation wedge) थे जो CIAM टीमों की पहली लहर को क्लाइंट-साइड इवेंट्स को लॉग करने के लिए मजबूर कर रहे हैं। एक बार जब वह ऑब्जर्वेबिलिटी लेयर मौजूद हो जाती है, तो उसके ऊपर एक नया अनुशासन बैठता है: ऑथेंटिकेशन प्रोसेस माइनिंग। यह इस बात का तरीका है कि कैसे पहचान टीमें "क्या लॉगिन सफल रहा" से "इस उपयोगकर्ता ने जर्नी के किस वेरिएंट को लिया, इसकी क्या लागत थी और अगले सत्र को अलग तरीके से कैसे रूट किया जाना चाहिए" तक जाती हैं। जो टीमें पहले ऑब्जर्वेबिलिटी लेयर बनाती हैं, और तुरंत बाद प्रोसेस-माइनिंग लेयर बनाती हैं, वे श्रेणी के लिए बेंचमार्क सेट करेंगी। जो टीमें समग्र (aggregate) सफलता दर पर टिके रहती हैं, वे अंतर्निहित प्रणालीगत (systemic) वेरिएंट्स को मिस करती रहेंगी।

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Passkey 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 विशेषज्ञ से बात करें →

FAQ#

ऑथेंटिकेशन प्रोसेस माइनिंग क्या है?#

ऑथेंटिकेशन प्रोसेस माइनिंग, लॉगिन इवेंट लॉग्स में बिजनेस प्रोसेस-माइनिंग तकनीकों का अनुप्रयोग (application) है। यह प्रति सत्र इवेंट्स के निर्देशित ग्राफ़ का पुनर्निर्माण करता है, डिज़ाइन की गई जर्नी के मुकाबले वास्तविक ऑथेंटिकेशन जर्नी की तुलना करता है और आवृत्ति तथा लागत के आधार पर विचलन वेरिएंट्स को रैंक करता है। यह ऑथेंटिकेशन ऑब्जर्वेबिलिटी (authentication observability) के ऊपर और ऑर्केस्ट्रेशन के नीचे बैठता है।

यह ऑथेंटिकेशन एनालिटिक्स से कैसे अलग है?#

ऑथेंटिकेशन एनालिटिक्स (Authentication analytics) लॉगिन सफलता दर (login success rate), ड्रॉप-ऑफ़ दर और पासकी उपयोग दर जैसे मेट्रिक्स की रिपोर्ट करते हैं। प्रोसेस माइनिंग प्रति सत्र पूर्ण इवेंट अनुक्रम (event sequence) का पुनर्निर्माण करके और यह पूछकर आगे जाता है कि जर्नी के कौन से वेरिएंट मौजूद हैं, प्रत्येक कितनी बार होता है और प्रत्येक कहाँ डिज़ाइन किए गए हैप्पी पाथ से विचलित होता है। एनालिटिक्स परिणाम बताते हैं। प्रोसेस माइनिंग रास्तों की व्याख्या करता है।

पासकी एडॉप्शन इस अनुशासन को आवश्यक क्यों बनाता है?#

पासकी रोलआउट्स (Passkey rollouts) पहला कारण है कि CIAM टीमें क्लाइंट-साइड इवेंट्स को बिल्कुल भी इंस्ट्रूमेंट कर रही हैं। एक बार जब वे इवेंट्स मौजूद होते हैं, तो समग्र (aggregate) मेट्रिक्स बहुत कुछ छिपाते हैं: 92% सफलता दर पासकी पथ पर 40% परित्याग दर को छुपा सकती है। प्रोसेस माइनिंग इस औसतीकरण (averaging) को अस्वीकार करता है और टीमों को वेरिएंट्स को अलग से देखने के लिए मजबूर करता है।

प्रोसेस माइनिंग स्टेप-अप ऑथेंटिकेशन से कैसे जुड़ता है?#

स्टेप-अप ऑथेंटिकेशन तब सबसे अच्छा काम करता है जब यह नियम-आधारित (rule-based) होने के बजाय जोखिम-स्कोर (risk-scored) होता है। प्रोसेस माइनिंग सत्र-स्तर के साक्ष्य (कोहोर्ट बेसलाइन, उपयोगकर्ता के ऐतिहासिक पथ से विचलन, डिवाइस रेपुटेशन) प्रदान करता है जो स्टेप-अप इंजन को एक ब्लंट थ्रेशोल्ड (सीमा) निर्णय के बजाय एक फाइन-ग्रेन्ड (बारीक) निर्णय लेने देता है।

क्या मेरा IDP इसे मूल रूप से शिप करेगा?#

निकट भविष्य में इसकी संभावना कम है। IDPs कंट्रोल प्लेन के लिए अनुकूलित करते हैं। प्रोसेस माइनिंग उच्च इवेंट वॉल्यूम और OS, ब्राउज़र और क्रेडेंशियल-मैनेजर कॉम्बिनेशन्स में उच्च कार्डिनैलिटी (cardinality) के साथ एक डेटा-प्लेन अनुशासन है। यह पैटर्न उस चीज़ से मेल खाता है जिसे हम आज SDK लेयर में देखते हैं, जिसे हमारे बाय-बनाम-बिल्ड गाइड (buy-vs-build guide) में शामिल किया गया है।

CIAM टीम को सबसे पहले क्या मापना चाहिए?#

पासकी पथ पर वेरिएंट आवृत्ति (variant frequency) से शुरू करें: कितने प्रतिशत सत्र हैप्पी पाथ का अनुसरण करते हैं, और आवृत्ति द्वारा रैंक किए गए शीर्ष पांच विचलन वेरिएंट्स क्या हैं? वह एकल चार्ट आमतौर पर उन दो या तीन सुधारों को प्रकट करने के लिए पर्याप्त है जो समग्र पासकी एडॉप्शन (passkey adoption) को सबसे अधिक बढ़ाते हैं।