मैं समझना चाहता हूं कि टोकन-आधारित प्रमाणीकरण का क्या मतलब है। मैंने इंटरनेट पर खोज की लेकिन कुछ भी समझ में नहीं आया।
जवाबों:
मुझे लगता है कि यह अच्छी तरह से यहाँ समझाया गया है - लंबे लेख के प्रमुख वाक्य उद्धृत करते हुए:
टोकन-आधारित प्रमाणीकरण प्रणाली के पीछे सामान्य अवधारणा सरल है। उपयोगकर्ताओं को अपना उपयोगकर्ता नाम और पासवर्ड दर्ज करने की अनुमति दें ताकि एक टोकन प्राप्त किया जा सके जो उन्हें अपने उपयोगकर्ता नाम और पासवर्ड का उपयोग किए बिना एक विशिष्ट संसाधन लाने की अनुमति देता है। एक बार उनका टोकन प्राप्त हो जाने के बाद, उपयोगकर्ता टोकन की पेशकश कर सकता है - जो एक विशिष्ट संसाधन तक एक समय अवधि के लिए - दूरस्थ साइट तक पहुंच प्रदान करता है।
दूसरे शब्दों में: प्रमाणीकरण के लिए अप्रत्यक्ष का एक स्तर जोड़ें - प्रत्येक संरक्षित संसाधन के लिए उपयोगकर्ता नाम और पासवर्ड के साथ प्रमाणित करने के बजाय, उपयोगकर्ता उस तरह से एक बार (सीमित अवधि के सत्र के भीतर) को प्रमाणित करता है, बदले में समय-सीमित टोकन प्राप्त करता है। , और सत्र के दौरान आगे प्रमाणीकरण के लिए उस टोकन का उपयोग करता है।
लाभ कई हैं - जैसे, उपयोगकर्ता टोकन प्राप्त कर सकता है, एक बार वे इसे प्राप्त करने के बाद, कुछ अन्य स्वचालित प्रणाली पर, जो वे सीमित समय और संसाधनों के सीमित सेट के लिए भरोसा करने के लिए तैयार हैं, लेकिन तैयार नहीं होंगे अपने उपयोगकर्ता नाम और पासवर्ड के साथ भरोसा करना (यानी, हर संसाधन के साथ उन्हें एक्सेस करने की अनुमति दी जाती है, हमेशा के लिए या कम से कम जब तक वे अपना पासवर्ड नहीं बदलते)।
यदि अभी भी कुछ भी स्पष्ट नहीं है, तो कृपया अपने प्रश्न को संपादित करें यह स्पष्ट करने के लिए कि आपके लिए 100% स्पष्ट नहीं है, और मुझे यकीन है कि हम आपकी आगे मदद कर सकते हैं।
से Auth0.com
टोकन-आधारित प्रमाणीकरण, एक हस्ताक्षरित टोकन पर निर्भर करता है जो प्रत्येक अनुरोध पर सर्वर को भेजा जाता है।
टोकन-आधारित दृष्टिकोण का उपयोग करने के क्या लाभ हैं?
क्रॉस-डोमेन / कॉर्स: कुकीज़ + कॉर्स अलग-अलग डोमेन में अच्छा नहीं खेलते हैं। टोकन-आधारित दृष्टिकोण आपको किसी भी सर्वर पर किसी भी सर्वर पर AJAX कॉल करने की अनुमति देता है, क्योंकि आप उपयोगकर्ता जानकारी को प्रसारित करने के लिए एक HTTP हेडर का उपयोग करते हैं।
स्टेटलेस (उर्फ सर्वर साइड स्केलेबिलिटी): सेशन स्टोर रखने की कोई आवश्यकता नहीं है, टोकन एक स्व-निहित इकाई है जो सभी उपयोगकर्ता जानकारी को बताती है। बाकी राज्य क्लाइंट की तरफ कुकीज़ या स्थानीय भंडारण में रहते हैं।
CDN: आप अपने एप्लिकेशन की सभी संपत्तियाँ CDN (जैसे जावास्क्रिप्ट, HTML, चित्र, आदि) से सेवा कर सकते हैं, और आपका सर्वर पक्ष सिर्फ API है।
Decoupling: आप किसी विशेष प्रमाणीकरण योजना से बंधे नहीं हैं। टोकन कहीं भी उत्पन्न हो सकता है, इसलिए आपके एपीआई को उन कॉलों को प्रमाणित करने के एक ही तरीके से कहीं से भी कॉल किया जा सकता है।
मोबाइल तैयार: जब आप एक देशी प्लेटफॉर्म (आईओएस, एंड्रॉइड, विंडोज 8, आदि) पर काम करना शुरू करते हैं तो कुकीज़ आदर्श नहीं होते हैं जब टोकन-आधारित दृष्टिकोण का उपभोग करने से यह बहुत सरल हो जाता है।
CSRF: चूंकि आप कुकीज़ पर निर्भर नहीं हैं, इसलिए आपको क्रॉस साइट अनुरोधों से बचाने की आवश्यकता नहीं है (जैसे कि आपकी साइट को सिब करना संभव नहीं होगा, एक POST अनुरोध उत्पन्न करें और मौजूदा प्रमाणीकरण कुकी का फिर से उपयोग करें क्योंकि कोई भी नहीं होगा )।
प्रदर्शन: हम यहां कोई हार्ड परफेक्ट बेंचमार्क नहीं पेश कर रहे हैं, लेकिन एक नेटवर्क राउंडट्रिप (उदाहरण के लिए डेटाबेस पर एक सत्र खोजना) एक टोकन की पुष्टि करने और इसकी सामग्री को पार्स करने के लिए HMACSHA256 की गणना की तुलना में अधिक समय लेने की संभावना है।
A tokenडेटा का एक टुकड़ा है जो केवल Server Xसंभवतः बनाया जा सकता है, और जिसमें किसी विशेष उपयोगकर्ता की पहचान करने के लिए पर्याप्त डेटा होता है।
आप अपनी प्रवेश जानकारी प्रस्तुत करते हैं और पूछ सकते हैं Server Xएक के लिए token; और फिर आप अपने को प्रस्तुत कर सकते हैं tokenऔर पूछ सकते हैंServer X कुछ उपयोगकर्ता-विशिष्ट कार्रवाई करने के लिए सकते हैं।
Tokens क्रिप्टोग्राफी के क्षेत्र के साथ-साथ सुरक्षा अनुसंधान के व्यापक क्षेत्र से इनपुट के साथ विभिन्न तकनीकों के विभिन्न संयोजनों का उपयोग करके बनाए जाते हैं। यदि आप अपना खुद का tokenसिस्टम बनाने और बनाने का निर्णय लेते हैं , तो आप वास्तव में बहुत स्मार्ट थे।
एक टोकन सर्वर द्वारा बनाए गए डेटा का एक टुकड़ा है, और इसमें किसी विशेष उपयोगकर्ता और टोकन वैधता की पहचान करने के लिए जानकारी होती है। टोकन में उपयोगकर्ता की जानकारी होगी, साथ ही एक विशेष टोकन कोड भी होगा जो उपयोगकर्ता सर्वर को पास कर सकता है जो प्रमाणीकरण और पासवर्ड को सीधे पारित करने के बजाय प्रमाणीकरण का समर्थन करने वाली हर विधि के साथ हो सकता है।
टोकन-आधारित प्रमाणीकरण एक सुरक्षा तकनीक है जो उन उपयोगकर्ताओं को प्रमाणित करती है जो सर्वर द्वारा प्रदान किए गए सुरक्षा टोकन का उपयोग करके सर्वर, नेटवर्क या किसी अन्य सुरक्षित सिस्टम में लॉग इन करने का प्रयास करते हैं।
एक प्रमाणीकरण सफल होता है यदि कोई उपयोगकर्ता किसी सर्वर को साबित कर सकता है कि वह एक सुरक्षा टोकन पारित करके एक वैध उपयोगकर्ता है। सेवा सुरक्षा टोकन को मान्य करती है और उपयोगकर्ता के अनुरोध को संसाधित करती है।
सेवा द्वारा टोकन को मान्य किए जाने के बाद, इसका उपयोग क्लाइंट के लिए सुरक्षा संदर्भ स्थापित करने के लिए किया जाता है, इसलिए सेवा लगातार उपयोगकर्ता के अनुरोधों के लिए प्राधिकरण निर्णय या ऑडिट गतिविधि कर सकती है।
टोकन आधारित (सुरक्षा / प्रमाणीकरण)
इसका मतलब है कि हमारे लिए यह साबित करने के लिए कि हम पहले पहुंच चुके हैं, हमें टोकन प्राप्त करना है। एक वास्तविक जीवन परिदृश्य में, टोकन निर्माण के लिए एक एक्सेस कार्ड हो सकता है, यह आपके घर के लॉक की कुंजी हो सकता है। अपने कार्यालय या अपने घर की कुंजी के लिए एक प्रमुख कार्ड को पुनः प्राप्त करने के लिए, आपको सबसे पहले यह साबित करना होगा कि आप कौन हैं, और वास्तव में आपके पास उस टोकन तक पहुंच है। यह कुछ सरल हो सकता है जैसे किसी को अपनी आईडी दिखाना या उन्हें गुप्त पासवर्ड देना। इसलिए कल्पना करें कि मुझे अपने कार्यालय तक पहुंचने की आवश्यकता है। मैं सुरक्षा कार्यालय में जाता हूं, मैं उन्हें अपनी आईडी दिखाता हूं, और वे मुझे यह टोकन देते हैं, जो मुझे इमारत में आने देता है। अब मेरे पास अप्रतिबंधित पहुंच है जो कुछ भी मैं इमारत के अंदर करना चाहता हूं, जब तक कि मेरे पास मेरा टोकन नहीं है।
टोकन आधारित सुरक्षा का क्या लाभ है?
यदि हम असुरक्षित API पर वापस सोचते हैं, तो उस स्थिति में हमें क्या करना था, हमें अपना पासवर्ड हर उस चीज़ के लिए प्रदान करना था जो हम करना चाहते थे।
कल्पना कीजिएहर बार जब हम अपने कार्यालय में एक दरवाजा दर्ज करते हैं, तो हमें दरवाजे के पास बैठे सभी को अपना पासवर्ड देना होगा। अब यह बहुत बुरा होगा, क्योंकि इसका मतलब है कि हमारे कार्यालय के अंदर कोई भी हमारा पासवर्ड ले सकता है और हमें प्रतिरूपण कर सकता है, और यह बहुत बुरा है। इसके बजाय, हम जो करते हैं वह यह है कि हम पासवर्ड के साथ मिलकर टोकन को पुनः प्राप्त करते हैं, लेकिन हम इसे एक व्यक्ति से प्राप्त करते हैं। और फिर हम इस टोकन का उपयोग भवन के अंदर जहां चाहें कर सकते हैं। बेशक अगर हम टोकन खो देते हैं, तो हमें वही समस्या होती है जैसे कि किसी और को हमारा पासवर्ड पता था, लेकिन यह हमें उन चीजों में ले जाता है जैसे हम कैसे सुनिश्चित करते हैं कि अगर हम टोकन खो देते हैं, तो हम एक्सेस को रद्द कर सकते हैं, और शायद टोकन 24 घंटे से अधिक समय तक नहीं रहना चाहिए, इसलिए अगले दिन जब हम कार्यालय आते हैं, हमें फिर से अपनी आईडी दिखाने की आवश्यकता होती है। लेकिन फिर भी, केवल एक व्यक्ति है जिसे हम आईडी दिखाते हैं,
सवाल पुराना है और तकनीक उन्नत हो गई है, यहाँ वर्तमान स्थिति है:
JSON वेब टोकन (JWT) वेब एप्लिकेशन वातावरण में पार्टियों के बीच दावों को पारित करने के लिए JSON-आधारित ओपन स्टैंडर्ड (RFC 7519) है। टोकन विशेष रूप से वेब ब्राउज़र सिंगल साइन-ऑन (SSO) संदर्भ में कॉम्पैक्ट, URL-सुरक्षित और प्रयोग करने योग्य हैं।
यह सिर्फ हैश है जो डेटाबेस या किसी अन्य तरीके से उपयोगकर्ता के साथ जुड़ा हुआ है। यह टोकन प्रमाणित करने के लिए इस्तेमाल किया जा सकता है और फिर आवेदन की एक उपयोगकर्ता पहुंच संबंधित सामग्री को अधिकृत कर सकता है। क्लाइंट साइड लॉगिन पर इस टोकन को पुनः प्राप्त करने के लिए आवश्यक है। पहली बार लॉगिन करने के बाद आपको पुनर्प्राप्त किए गए टोकन को सहेजने की आवश्यकता है जैसे सत्र, सत्र आईडी जैसे कोई अन्य डेटा नहीं क्योंकि यहां सब कुछ आवेदन के अन्य संसाधनों तक पहुंचने के लिए टोकन है।
टोकन का उपयोग उपयोगकर्ता की प्रामाणिकता को आश्वस्त करने के लिए किया जाता है।
आजकल वेब एपीआई संसाधनों को सुरक्षित करने के लिए सबसे पसंदीदा तरीका वेब एपीआई सर्वर में उपयोगकर्ताओं को हस्ताक्षरित टोकन का उपयोग करके प्रमाणित करना है (जिसमें किसी विशेष उपयोगकर्ता की पहचान करने के लिए पर्याप्त जानकारी है) जो क्लाइंट को सर्वर द्वारा प्रत्येक के साथ भेजा जाना चाहिए और हर अनुरोध। इसे टोकन-आधारित प्रमाणीकरण दृष्टिकोण कहा जाता है।
टोकन-आधारित प्रमाणीकरण निम्नानुसार काम करता है:
एक उपयोगकर्ता नाम और पासवर्ड क्लाइंट में दर्ज करता है (क्लाइंट का अर्थ है ब्राउज़र या मोबाइल डिवाइस आदि)।
क्लाइंट तब इन क्रेडेंशियल (अर्थात उपयोगकर्ता नाम और पासवर्ड) को प्राधिकरण सर्वर को भेजता है।
तब प्राधिकरण सर्वर क्लाइंट क्रेडेंशियल (अर्थात उपयोगकर्ता नाम और पासवर्ड) को प्रमाणित करता है और फिर यह एक पहुंच टोकन को उत्पन्न और वापस करता है। इस एक्सेस टोकन में एक उपयोगकर्ता की पहचान करने के लिए पर्याप्त जानकारी होती है और इसमें टोकन समाप्ति समय भी होता है।
क्लाइंट एप्लिकेशन में टोकन समाप्त होने तक संसाधन सर्वर से प्रतिबंधित संसाधनों तक पहुंचने के लिए HTTP अनुरोध के प्राधिकरण हेडर में एक्सेस टोकन शामिल है।
निम्न लेख दिखाता है कि कैसे WEB एपीआई कदम में टोकन आधारित प्रमाणीकरण को लागू किया जाए।
https://dotnettutorials.net/lesson/token-based-authentication-web-api/
जब आप एक नई वेबसाइट के लिए पंजीकरण करते हैं, तो अक्सर आपको अपना खाता सक्रिय करने के लिए एक ईमेल भेजा जाता है। उस ईमेल में आमतौर पर लिंक पर क्लिक करना होता है। उस लिंक के एक हिस्से में एक टोकन होता है, सर्वर इस टोकन के बारे में जानता है और इसे आपके खाते के साथ जोड़ सकता है। टोकन में आमतौर पर एक समाप्ति की तारीख जुड़ी होगी, इसलिए आपके पास लिंक पर क्लिक करने और अपने खाते को सक्रिय करने के लिए केवल एक घंटा हो सकता है। कुकीज या सेशन वेरिएबल्स में से कोई भी संभव नहीं होगा, क्योंकि इसके अज्ञात ग्राहक किस ब्राउजर या ईमेल का उपयोग कर रहे हैं।