एक बियरर टोकन क्या है? उपयोग, जोखिम, और सर्वोत्तम प्रथाएँ

Scrapeless Scraping API x-api-token हेडर में एक खाता API कुंजी का उपयोग करता है, जो OAuth Bearer प्रमाणीकरण के बजाय है, यह प्रदर्शित करता है कि क्रेडेंशियल प्रकार और HTTP प्रस्तुति योजना अलग डिज़ाइन विकल्प हैं।

एक बेयरर टोकन क्या है?

एक धारक टोकन एक सुरक्षा टोकन है जिसकी प्राधिकृति धारण पर आधारित होती है। "धारक" शब्द का अर्थ है कि टोकन ले जाने वाला पक्ष इसे एक संरक्षित संसाधन के सामने प्रस्तुत कर सकता है। एक स्वामित्व प्रमाण डिजाइन के विपरीत, एक मौलिक धारक प्रवाह को प्रत्येक अनुरोध के लिए एक अलग एन्क्रिप्टेड कुंजी पर नियंत्रण प्रदर्शित करने की आवश्यकता नहीं होती है।

RFC 6750 OAuth 2.0 धारक टोकन उपयोग को परिभाषित करता हैयह वर्णन करता है कि ग्राहक संसाधन सर्वरों को पहुंच टोकन कैसे भेजते हैं, सर्वर प्रामाणिकता चुनौतियाँ और त्रुटियाँ कैसे लौटाते हैं, और कौन से सुरक्षा खतरों का कार्यान्वयन को समाधान करना चाहिए।

बेरर टोकन HTTP एपीआई में सामान्य होते हैं क्योंकि क्लाइंट इंटरएक्शन सरल होता है। प्राधिकरण सर्वर एक एक्सेस टोकन जारी करता है, क्लाइंट इसे स्टोर करता है, और क्लाइंट इसे एपीआई अनुरोधों के साथ भेजता है। सरलता ट्रांसपोर्ट सुरक्षा, टोकन हैंडलिंग, सत्यापन, स्कोप डिज़ाइन, और घटना प्रतिक्रिया की जिम्मेदारी को स्थानांतरित करती है।

कैसे ऑथराइजेशन हेडर काम करता है

पसंदीदा HTTP प्रस्तुति का उपयोग करती है Authorization अनुरोध हेडर के साथ Bearer योजना:

Authorization: Bearer REDACTED

स्कीम का नाम HTTP प्रमाणीकरण पार्सिंग के तहत केस-संवेदनशील नहीं है, लेकिन ग्राहकों को पारंपरिक पूंजीकरण का उपयोग करना चाहिए। टोकन का मूल्य ग्राहक के लिए अस्पष्ट है जब तक कि टोकन प्रोफ़ाइल स्पष्ट रूप से ग्राहक को इसे निरीक्षण करने का कारण न दे। ग्राहकों को एक्सेस-टोकन सामग्री को डीकोड करके प्राधिकरण निर्णय नहीं लेने चाहिए; संसाधन सर्वर प्रवर्तन बिंदु है।

अनुरोध को HTTPS का उपयोग करना चाहिए, और क्लाइंट को अपने प्लेटफ़ॉर्म ट्रस्ट मॉडल के अनुसार सर्वर के प्रमाणपत्र को मान्य करना चाहिए। हेडर अभी भी एप्लिकेशन लॉग, ट्रेसिंग एजेंट, डिबगिंग प्रॉक्सी, क्रैश रिपोर्ट्स, या ब्राउज़र एक्सटेंशनों के माध्यम से लीक हो सकता है, इसलिए प्रत्येक परत जो अनुरोधों को देखती है, को रेडैक्शन नियमों की आवश्यकता होती है।

बीयार टोकन, एक्सेस टोकन, और OAuth

एक एक्सेस टोकन एक क्रेडेंशियल है जो किसी संसाधन तक पहुँचने के लिए अधिकृतता का प्रतिनिधित्व करता है। बियरर यह वर्णन करता है कि उस टोकन का उपयोग कैसे किया जाता है। ओथ (OAuth) वह ढांचा है जिसके माध्यम से एक क्लाइंट एक अनुदान के तहत एक एक्सेस टोकन प्राप्त कर सकता है। ये शर्तें संबंधित हैं लेकिन एक दूसरे के स्थान पर नहीं प्रयोग की जा सकतीं।

OAuth ऐक्सेस टोकन अक्सर बेयर टोकन होते हैं, लेकिन एक और प्रोफ़ाइल एक टोकन को क्लाइंट-धारण कुंजी से बाँध सकती है। एक गैर-OAuth प्रणाली भी एक बेयर-शैली टोकन आविष्कार कर सकती है, हालांकि मानक योजना का उपयोग करना बिना संबंधित सुरक्षा और त्रुटि अर्थव्यवस्था का पालन किए भ्रम उत्पन्न करता है।

एक प्रमाणन कोड संसाधन एपीआई के लिए एक धारक पहुंच टोकन नहीं है। यह अधिकृत सर्वर के टोकन अंत बिंदु पर विनिमय किए गए एक अल्पकालिक इंटरमीडिएट क्रेडेंशियल है। एक रिफ्रेश टोकन भी सामान्य संसाधन सर्वरों को नहीं भेजा जाता है; इसे मौजूदा अनुदान को जारी रखने के लिए अधिकृत सर्वर के साथ उपयोग किया जाता है।

बियरर टोकन बनाम एपीआई कुंजी बनाम JWT

JWT एकधारी टोकन हो सकता है, लेकिन हर JWT एक एक्सेस टोकन नहीं होता और हर एकधारी टोकन एक JWT नहीं होता। एक सिग्न किया गया JWT यह साबित करता है कि एक स्वीकृत प्रदाता ने दावों को परिवर्तन से सुरक्षित रखा; यह यह साबित नहीं करता कि प्रस्तुतकर्ता इच्छित धारक है जब तक प्रोफ़ाइल प्रेषक बाइंडिंग को न जोड़ता है।

अस्पष्ट और स्व-निहित एकधारी टोकन

अस्पष्ट टोकन

एक अस्पष्ट टोकन एक अप्रत्याशित मान है जिसका अर्थ प्राधिकरण अवसंरचना द्वारा रखा जाता है। संसाधन सर्वर एक अंतर्दृष्टि अंतबिंदु को बुला सकता है, साझा टोकन स्टोर का उपयोग कर सकता है, या एक गेटवे पर भरोसा कर सकता है जो टोकन को हल करता है। केंद्रीय खोज तेजी से निरसन और नीति परिवर्तनों को दर्शा सकती है, लेकिन यह उपलब्धता, विलंबता, और कैशिंग निर्णयों को जोड़ती है।

स्व-निहित टोकन

एक स्व-निहित टोकन में दावे होते हैं जिन्हें संसाधन सर्वर स्थानीय रूप से मान्य कर सकता है। JWT एक सामान्य प्रतिनिधित्व है। सर्वर एक सख्त प्रोफ़ाइल के तहत सिग्नेचर या संदेश प्रमाणीकरण कोड की पुष्टि करता है और फिर प्रदाता, दर्शक, समय, टोकन प्रकार, दायरा, और किसी भी आवश्यक पुष्टि दावों की जांच करता है।

RFC 8725 JWT सुरक्षा के लिए सर्वोत्तम वर्तमान प्रथाएँ प्रदान करता है।यह एल्गोरिदम भ्रम, कमजोर प्रमाणीकरण, क्रॉस-JWT भ्रम, और प्राप्त दावों पर अंधा भरोसा करने के खिलाफ चेतावनी देता है। एक संसाधन सर्वर को अनुमत एल्गोरिदम और अपेक्षित टोकन प्रोफाइल को कॉन्फ़िगर करना चाहिए न कि जो भी टोकन हेडर अनुरोध करता है उसे स्वीकार करना।

एक संसाधन सर्वर को क्या मान्य करना चाहिए

• टोकन अखंडता या सक्रिय स्थिति। अनुमत एल्गोरिदम के तहत सिग्नेचर की पुष्टि करें या विश्वसनीय प्राधिकरण प्रणाली के माध्यम से अस्पष्ट टोकन हल करें।
• प्रदाता। केवल इस संसाधन के लिए कॉन्फ़िगर किए गए प्राधिकरण सर्वर से टोकन स्वीकार करें।
• दर्शक। पुष्ट करें कि टोकन इस API या संसाधन सेट के लिए जारी किया गया था।
• आयु। छोटी दस्तावेज़ीकृत घड़ी सहिष्णुता के साथ समाप्ति और किसी भी नकारने से पहले की स्थिति लागू करें।
• टोकन प्रोफ़ाइल और प्रकार। निश्चित करें कि एक आईडी टोकन, प्राधिकरण कोड, या दूसरे प्रोटोकॉल संदर्भ से टोकन को API एक्सेस टोकन के रूप में स्वीकार नहीं किया जाता है।
• दायरा या प्राधिकरण दावे। पुष्ट करें कि टोकन अनुरोध की गई क्रिया की अनुमति देता है।
• संसाधन-स्तरीय नीति। दर्शक, स्वामित्व, भूमिका, वस्तु स्थिति, और अन्य डोमेन नियमों की जांच करें जब भी टोकन का दायरा व्यापक हो।

एक मान्य सिग्नेचर केवल एक जांच है। यह साबित करता है कि टोकन को स्वीकृत एल्गोरिदम के तहत एक विश्वसनीय कुंजी द्वारा सुरक्षित किया गया था। यह यह साबित नहीं करता कि टोकन इस API को लक्षित करता है, वर्तमान है, आवश्यक प्राधिकरण है, या इस विशेष रिकॉर्ड तक पहुंच सकता है।

एकधारी टोकन सुरक्षा जोखिम

केंद्र जोखिम टोकन प्रकटीकरण है। एक कॉपी किया गया एकधारी टोकन तब तक उपयोग किया जा सकता है जब तक कि यह समाप्त न हो जाए, रद्द न किया जाए, या किसी अन्य नीति नियंत्रण द्वारा अस्वीकार न किया जाए। एक्सपोज़र विशेष रूप से URL, एप्लिकेशन लॉग, समर्थन स्क्रीनशॉट, ब्राउज़र स्टोरेज, रेफरर हेडर, प्रॉक्सी ट्रेस, स्रोत नियंत्रण, या समझौता किए गए क्लाइंट उपकरणों के माध्यम से हो सकता है।

URLs विशेष रूप से खतरनाक होते हैं। क्वेरी स्ट्रिंग्स वेब-सर्वर एक्सेस लॉग, ब्राउज़र इतिहास, विश्लेषिकी सिस्टम, और कॉपी किए गए लिंक में दिखाई देती हैं। RFC 6750 एक सीमित स्थिति के तहत एक फॉर्म-कोडित बॉडी विधि को परिभाषित करता है और संगतता के लिए URI क्वेरी उपयोग का दस्तावेजीकरण करता है, लेकिन नए ग्राहकों को ऑथराइजेशन हेडर का उपयोग करना चाहिए।

क्रॉस-साइट स्क्रिप्टिंग ब्राउज़र-सुलभ टोकन को उजागर कर सकती है। स्थानीय स्टोरेज में एक दीर्घकालिक एकधारी टोकन रखना इसे समान उत्पत्ति में चलने वाली दुर्भावनापूर्ण स्क्रिप्ट के लिए उपलब्ध बनाता है। ब्राउज़र आर्किटेक्चर को JavaScript के लिए टोकन एक्सपोज़र को कम करना चाहिए, छोटी एक्सेस आयु का उपयोग करना चाहिए, एक मजबूत सामग्री सुरक्षा नीति लागू करनी चाहिए, और उपयुक्त होने पर एक बैकेंड-फॉर-फ्रंटेंड पैटर्न पर विचार करना चाहिए।

क्लाइंट प्रकार द्वारा टोकन स्टोरेज

एक बैकेंड सेवा सर्वर-साइड मेमोरी या एक स्वीकृत सुरक्षित क्रेडेंशियल स्टोर में टोकन्स को संग्रहीत करती है और उन तक पहुंच को सीमित करती है जिसे उनकी आवश्यकता होती है। टोकन को डिस्क कैश, पर्यावरण डंप, या सामान्य लॉग में बिना किसी समीक्षा कारण और सुरक्षा मॉडल के बिना नहीं लिखा जाना चाहिए।

एक इंस्टॉल किया गया एप्लिकेशन उपलब्ध होने पर ऑपरेटिंग सिस्टम की सुरक्षित स्टोरेज का उपयोग करता है। एक ब्राउज़र क्लाइंट में एक अधिक उजागर वातावरण होता है और इसे टोकन की आयु और स्क्रिप्ट की पहुंच को व्यावहारिक रूप से छोटा रखना चाहिए। एक सत्र कुकी स्वचालित रूप से सुरक्षित नहीं होती; कुकी डिजाइन को सुरक्षित, HttpOnly, SameSite, क्रॉस-साइट अनुरोध धोखाधड़ी नियंत्रण, और सर्वर-साइड सत्र नीति की आवश्यकता होती है।

कोई स्टोरेज विकल्प एक शक्तिशाली टोकन को ठीक नहीं करता है। दायरे को संकीर्ण रखें, दर्शक को विशिष्ट रखें, आयु को छोटा रखें, और संसाधनों को सर्वर-साइड प्राधिकरण द्वारा सुरक्षित रखें।

प्रेषक-सीमित विकल्प

एक प्रेषक-सीमित टोकन को प्रस्तुतकर्ता को एक अलग कुंजी की स्वामित्व साबित करने की आवश्यकता होती है, जो चोरी किए गए टोकन स्ट्रिंग का मूल्य कम करता है। स्वामित्व का प्रमाण प्रदर्शित करना, या DPoP, OAuth टोकनों को अनुरोधों के साथ संलग्न सिग्नेड प्रमाणों के माध्यम से एक एप्लिकेशन कुंजी से बाइंड करता है।

RFC 9449 OAuth DPoP को परिभाषित करता है।आधिकारिक TLS एक और प्रेषक-सीमित दृष्टिकोण है जो उपयुक्त गोपनीय क्लाइंट वातावरण के लिए है। ये डिज़ाइन कुंजी उत्पादन, भंडारण, पुन: प्रकट पहचान, और अंतर्विशिष्टता आवश्यकताओं को जोड़ते हैं, इसलिए इन्हें एक स्पष्ट खतरा मॉडल के अंतर्गत चुना जाना चाहिए।

समाप्ति, रद्दीकरण, और अंतर्दृष्टि

कम अवधि वाले एक्सेस टोकन यह सीमित करते हैं कि एक प्रकटीकरण किया गया टोकन कब तक उपयोगी रहता है। क्लाइंट एक अधिकृत सत्र या रीफ्रेश-टोकन प्रक्रिया के माध्यम से नए एक्सेस प्राप्त कर सकता है। रीफ्रेश क्रेडेंशियल को मजबूत सुरक्षा की आवश्यकता है क्योंकि यह एक एक्सेस टोकन की आयु से अधिक पहुंच का विस्तार कर सकता है।

अस्पष्ट टोकन अंतर्दृष्टि या केंद्रीय खोज के माध्यम से रद्दीकरण को दर्शा सकते हैं। स्व-निहित टोकन अक्सर समाप्ति तक स्वीकार किए जाते हैं जब तक कि संसाधन सर्वर रद्दीकरण या सत्र स्थिति की जांच नहीं करता। सही डिज़ाइन तत्काल नीति परिवर्तनों, विलंबता, उपलब्धता, कैशिंग, और जोखिम का संतुलन बनाता है।

लॉगआउट सेमांटिक्स को परिभाषित किया जाना चाहिए। एक स्थानीय क्लाइंट सत्र समाप्त करना, रीफ्रेश टोकन रद्द करना, एक एक्सेस टोकन रद्द करना, और एक प्राधिकरण-सर्वर सत्र समाप्त करना विभिन्न संचालन हैं। एक उपयोगकर्ता इंटरफेस को यह स्पष्ट करना चाहिए कि यह वास्तव में क्या अमान्य करता है।

सामान्य एकधारी टोकन उपयोग के मामले

बैरर टोकन चेकलिस्ट

1. सिर्फ HTTPS पर टोकन भेजें। इच्छित सर्वर को मान्य करें और URLs से टोकन को बाहर रखें।
2. प्राधिकरण हेडर का उपयोग करें। API के दस्तावेजीकृत योजना का पालन करें और वैकल्पिक स्थान को आविष्कार न करें।
3. संकीर्ण प्राधिकरण जारी करें। दर्शकों, दायरे, जीवनकाल, किरायेदार, और संसाधन अनुमतियों को सीमित करें।
4. पूरी टोकन प्रोफ़ाइल को मान्य करें। सिर्फ हस्ताक्षर अपर्याप्त है।
5. पर्यवेक्षिता निर्यात से पहले हटाएं। हेडर, ट्रेस, अपवाद, अनुरोध डंप, और समर्थन उपकरणों को कवर करें।
6. क्लाइंट प्रकार के लिए भंडारण की सुरक्षा करें। सार्वजनिक और गोपनीय क्लाइंट में विभिन्न क्षमताएँ होती हैं।
7. रद्दीकरण और घटना प्रतिक्रिया की योजना बनाएं। जानें कि कौन से टोकन, ग्रांट्स, और सत्र अक्षम किए जा सकते हैं और संसाधन सर्वर परिवर्तन को कितनी जल्दी देखता है।

निष्कर्ष

एक बैरर टोकन शक्तिशाली होता है क्योंकि यह अधिकृत API कॉल को सरल बनाता है: टोकन प्रस्तुत करें और संसाधन सर्वर इसकी प्राधिकरण का मूल्यांकन करता है। यही गुण प्रकटीकरण को गंभीर बनाता है। सुरक्षित बैरर-टोकन प्रणाली TLS, प्राधिकरण हेडर, सख्त टोकन-प्रोफ़ाइल सत्यापन, संकीर्ण दर्शक और दायरे, अल्पकालिक, सुरक्षित भंडारण, आक्रामक सम्पादन, और रद्दीकरण नियंत्रण का उपयोग करती हैं। जब चोरी का जोखिम अधिक आश्वासन की आवश्यकता करता है, तो भेजने वाले-सीमित टोकन एक क्लाइंट-धारित कुंजी से बंधा प्रमाण जोड़ते हैं।