security - OAuth v2 में एक्सेस और रीफ्रेश टोकन दोनों क्यों हैं?




access-token refresh-token (8)

क्यों न केवल access_token को तब तक रीफ्रेश_टोकन करें और रीफ्रेश_टोकन न करें?

महान उत्तरों के अलावा अन्य लोगों ने प्रदान किया है कि एक और कारण है कि रीफ्रेश टोकन का उपयोग क्यों करें और दावों के साथ किया जाए।

प्रत्येक टोकन में ऐसे दावे होते हैं जिनमें उपयोगकर्ता नाम, उनकी भूमिका या प्रदाता से कुछ भी शामिल हो सकता है जो दावा उत्पन्न करता है। एक टोकन को ताज़ा किया जाता है क्योंकि इन दावों को अद्यतन किया जाता है।

यदि हम टोकन को अधिक बार ताज़ा करते हैं तो हम स्पष्ट रूप से हमारी पहचान सेवाओं पर अधिक तनाव डाल रहे हैं, हालांकि हमें अधिक सटीक और अद्यतित दावे मिल रहे हैं।

ड्राफ्ट OAuth 2.0 प्रोटोकॉल का सेक्शन 4.2 इंगित करता है कि एक प्राधिकरण सर्वर एक access_token (जिसे संसाधन के साथ स्वयं प्रमाणित करने के लिए उपयोग किया जाता है) के साथ-साथ एक refresh_token दोनों को वापस कर सकता है, जिसका उपयोग पूरी तरह से एक नई access_token बनाने के लिए किया जाता है:

https://tools.ietf.org/html/rfc6749#section-4.2

दोनों क्यों हैं? क्यों न केवल access_token को तब तक refresh_token और refresh_token न करें?


सबसे पहले, प्राधिकरण प्राधिकरण अनुदान देकर प्राधिकरण सर्वर के साथ प्रमाणित करता है।

फिर, क्लाइंट एक्सेस टोकन देकर संरक्षित संसाधन के लिए संसाधन सर्वर से अनुरोध करता है।

संसाधन सर्वर पहुंच टोकन को मान्य करता है और संरक्षित संसाधन प्रदान करता है।

ग्राहक संसाधन टोकन को संसाधन टोकन प्रदान करके सुरक्षित संसाधन अनुरोध करता है, जहां संसाधन सर्वर इसे मान्य करता है और मान्य होने पर अनुरोध करता है। जब तक पहुंच टोकन समाप्त नहीं हो जाती है तब तक यह चरण दोहराया जाता है।

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

क्लाइंट रीफ्रेश टोकन प्रदान करके प्राधिकरण सर्वर के साथ प्रमाणित करता है।

प्रमाणीकरण सर्वर क्लाइंट को प्रमाणीकृत करके रीफ्रेश टोकन को मान्य करता है और यदि यह मान्य है, तो एक नया एक्सेस टोकन जारी करता है।


इन उत्तरों में से कोई भी मूल कारण ताज़ा टोकन मौजूद नहीं है। जाहिर है, आप अपने क्लाइंट क्रेडेंशियल को ऑथ सर्वर पर भेजकर हमेशा एक नई एक्सेस-टोकन / रीफ्रेश-टोकन जोड़ी प्राप्त कर सकते हैं - यह कि आप उन्हें पहले स्थान पर कैसे प्राप्त करते हैं।

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


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

इस तरह के एक परिदृश्य के बारे में सोचो। आप 3600 सेकेंड के एक्सेस टोकन के उपयोगकर्ता को जारी करते हैं और एक दिन के रूप में टोकन को रीफ्रेश करते हैं।

  1. उपयोगकर्ता एक अच्छा उपयोगकर्ता है, वह घर पर है और अपनी वेबसाइट खरीदारी पर / बंद हो जाता है और अपने आईफोन पर खोज करता है। उनका आईपी पता बदलता नहीं है और आपके सर्वर पर बहुत कम भार है। 3-5 पृष्ठों की तरह हर मिनट का अनुरोध करें। जब एक्सेस टोकन पर उसके 3600 सेकेंड खत्म हो जाते हैं, तो उसे रीफ्रेश टोकन के साथ एक नया चाहिए। हम, सर्वर की ओर, अपने गतिविधि इतिहास और आईपी पते की जांच करें, लगता है कि वह एक इंसान है और खुद से व्यवहार करता है। हम उसे हमारी सेवा का उपयोग जारी रखने के लिए एक नया एक्सेस टोकन देते हैं। उपयोगकर्ता को फिर से उपयोगकर्ता नाम / पासवर्ड दर्ज करने की आवश्यकता नहीं होगी जब तक कि वह ताज़ा टोकन के एक दिन के जीवनकाल तक नहीं पहुंच जाता।

  2. उपयोगकर्ता एक लापरवाही उपयोगकर्ता है। वह न्यूयॉर्क, यूएसए में रहता है और अपने वायरस प्रोग्राम को बंद कर देता है और पोलैंड में हैकर द्वारा हैक किया गया था। जब हैकर को एक्सेस टोकन मिल गया और टोकन रीफ्रेश किया गया, तो वह उपयोगकर्ता का प्रतिरूपण करने और हमारी सेवा का उपयोग करने का प्रयास करता है। लेकिन शॉर्ट-लाइव एक्सेस टोकन समाप्त होने के बाद, जब हैकर एक्सेस टोकन को रीफ्रेश करने का प्रयास करता है, तो सर्वर पर, हमने उपयोगकर्ता व्यवहार इतिहास में नाटकीय आईपी परिवर्तन देखा है (हे, यह आदमी संयुक्त राज्य अमेरिका में लॉग इन लॉग इन करता है और अब पोलैंड में पहुंच रीफ्रेश करता है केवल 3600 के बाद ???)। हम रीफ्रेश प्रक्रिया को समाप्त करते हैं, रीफ्रेश टोकन को अमान्य कर देते हैं और फिर उपयोगकर्ता नाम / पासवर्ड दर्ज करने के लिए संकेत देते हैं।

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

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

एक और शब्द यह है कि आप प्रत्येक आईपीआई को बुनियादी आईपी घड़ी कुत्ते या किसी भी अन्य उपायों पर लागू करके चोरी किए गए टोकन / सेवा के दुरुपयोग के नुकसान नियंत्रण को सीमित करने का प्रयास कर सकते हैं। लेकिन यह महंगा है क्योंकि आपको उपयोगकर्ता के बारे में रिकॉर्ड पढ़ना और लिखना है और आपकी सर्वर प्रतिक्रिया धीमा कर देगी।


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

ताज़ा टोकन की मेरी यादें सुरक्षा और निरसन के लिए थीं। <...>

निरसन: यदि पहुंच टोकन स्वयं निहित है, तो नए पहुंच टोकन जारी न करके प्राधिकरण को निरस्त किया जा सकता है। संसाधन को प्राधिकरण सर्वर से पूछताछ करने की आवश्यकता नहीं है कि यह देखने के लिए कि टोकन एक्सेस मान्य है या नहीं। यह टोकन सत्यापन तक पहुंच को सरल बनाता है और एकाधिक प्रमाणीकरण सर्वरों को स्केल और समर्थन करना आसान बनाता है। उस समय की एक खिड़की है जब एक्सेस टोकन मान्य होता है, लेकिन प्राधिकरण निरस्त कर दिया जाता है।

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

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

आम तौर पर, टोकन या तो सर्वर के डेटाबेस में विशिष्ट रिकॉर्ड को इंगित करने वाले यादृच्छिक पहचानकर्ता हो सकते हैं, या वे स्वयं में सभी जानकारी शामिल कर सकते हैं (निश्चित रूप से, इस जानकारी को MAC साथ, उदाहरण के लिए, हस्ताक्षर करना होगा)।

लंबे समय तक पहुंचने वाले टोकन वाले सिस्टम को कैसे काम करना चाहिए

सर्वर क्लाइंट को टोकन जारी करके स्कॉप्स के प्री-डिफ़ाइंड सेट के भीतर उपयोगकर्ता के डेटा तक पहुंच प्राप्त करने की अनुमति देता है। चूंकि हम टोकन को पुन: प्रयोज्य रखना चाहते हैं, हमें डेटाबेस में टोकन को "निरस्त" ध्वज के साथ सेट या अनसेट करने के साथ स्टोर करना होगा (अन्यथा, आप स्वयं निहित टोकन के साथ ऐसा कैसे करेंगे?) डेटाबेस में जितना अधिक len(users) x len(registered clients) x len(scopes combination) रिकॉर्ड। प्रत्येक एपीआई अनुरोध तो डेटाबेस को हिट करना होगा। हालांकि ओ (1) प्रदर्शन करने वाले ऐसे डेटाबेस को क्वेरी करने में काफी मुश्किल है, लेकिन विफलता का एक बिंदु स्वयं स्केलेबिलिटी और सिस्टम के प्रदर्शन पर नकारात्मक प्रभाव डाल सकता है।

लंबे समय तक रहने वाले ताज़ा टोकन और अल्पकालिक पहुंच टोकन वाले सिस्टम को कैसे काम करना चाहिए

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

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

फिर भी, हमें अभी भी ताज़ा टोकन का डेटाबेस रखना है, लेकिन इस डेटाबेस के अनुरोधों की संख्या आम तौर पर एक्सेस टोकन (जीवनकाल, कम पहुंच दर) के जीवनकाल द्वारा परिभाषित की जाती है।

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

समझौतों से

रीफ्रेश टोकन आंशिक रूप से एक्सेस टोकन डेटाबेस के एसपीओएफ (विफलता का सिंगल प्वाइंट) को खत्म करते हैं, फिर भी उनके पास कुछ स्पष्ट दोष हैं।

  1. खिड़की"। घटनाओं के बीच एक समय सीमा "उपयोगकर्ता पहुंच को रद्द करता है" और "पहुंच निरस्त करने की गारंटी है"।

  2. ग्राहक तर्क की जटिलता।

    रीफ्रेश टोकन के बिना

    • पहुंच टोकन के साथ एपीआई अनुरोध भेजें
    • यदि एक्सेस टोकन अमान्य है, तो विफल हो और उपयोगकर्ता को फिर से प्रमाणित करने के लिए कहें

    रीफ्रेश टोकन के साथ

    • पहुंच टोकन के साथ एपीआई अनुरोध भेजें
    • यदि एक्सेस टोकन अमान्य है, तो रीफ्रेश टोकन का उपयोग करके इसे अपडेट करने का प्रयास करें
    • अगर रीफ्रेश अनुरोध पास हो जाता है, तो एक्सेस टोकन अपडेट करें और प्रारंभिक API अनुरोध दोबारा भेजें
    • यदि रीफ्रेश अनुरोध विफल रहता है, तो उपयोगकर्ता को पुनः प्रमाणित करने के लिए कहें

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


ग्राहकों को कई तरीकों से समझौता किया जा सकता है। उदाहरण के लिए एक सेल फोन क्लोन किया जा सकता है। एक्सेस टोकन की समाप्ति का मतलब है कि क्लाइंट को प्राधिकरण सर्वर को फिर से प्रमाणीकृत करने के लिए मजबूर होना पड़ता है। पुनः प्रमाणीकरण के दौरान, प्राधिकरण सर्वर अन्य विशेषताओं की जांच कर सकता है (IOW अनुकूल अनुकूली पहुंच प्रबंधन)।

रीफ्रेश टोकन क्लाइंट के लिए केवल पुनः प्रमाणीकरण की अनुमति देता है, जहां उपयोगकर्ता के साथ एक संवाद को दोबारा अधिकृत करने के लिए पुन: अधिकृत करते हैं, जो कई ने संकेत दिया है कि वे ऐसा नहीं करेंगे।

रीफ्रेश टोकन अनिवार्य रूप से उसी स्थान पर फिट होते हैं जहां सामान्य वेबसाइटें समय-समय पर उपयोगकर्ताओं को फिर से प्रमाणीकृत करने का विकल्प चुन सकती हैं (जैसे बैंकिंग साइट)। वर्तमान में इसका अत्यधिक उपयोग नहीं किया जाता है क्योंकि अधिकांश सोशल वेब साइट वेब उपयोगकर्ताओं को फिर से प्रमाणित नहीं करती हैं, तो वे क्लाइंट को फिर से प्रमाणित क्यों करेंगे?


टोकन रीफ्रेश करने का विचार यह है कि यदि एक्सेस टोकन से समझौता किया जाता है, क्योंकि यह अल्पकालिक रहता है, तो हमलावर की एक सीमित खिड़की होती है जिसमें इसका दुरुपयोग किया जाता है।

रीफ्रेश टोकन, अगर समझौता किया गया है, तो बेकार हैं क्योंकि हमलावर को एक्सेस टोकन प्राप्त करने के लिए रीफ्रेश टोकन के अतिरिक्त क्लाइंट आईडी और गुप्त की आवश्यकता होती है।

ऐसा कहने के बाद , क्योंकि प्रमाणीकरण सर्वर और संसाधन सर्वर दोनों के लिए प्रत्येक कॉल एसएसएल पर किया जाता है - मूल ग्राहक आईडी और गुप्त सहित, जब वे एक्सेस / रीफ्रेश टोकन का अनुरोध करते हैं - मुझे यकीन है कि एक्सेस टोकन अब और कैसे है " समझौता करने योग्य "लंबे समय तक रहने वाले ताज़ा टोकन और क्लाइंटिड / गुप्त संयोजन से।

यह निश्चित रूप से कार्यान्वयन के लिए अलग है जहां आप प्राधिकरण और संसाधन सर्वर दोनों को नियंत्रित नहीं करते हैं।

रीफ्रेश टोकन के उपयोग के बारे में बात करने के लिए यहां एक अच्छा धागा है: OAuth अभिलेखागार

उपरोक्त से उद्धरण, ताज़ा टोकन के सुरक्षा उद्देश्यों के बारे में बात करते हुए:

टोकन रीफ्रेश करें ... एक लंबे समय तक पहुंचने वाले access_token लीकिंग के जोखिम को कम करता है (एक असुरक्षित संसाधन सर्वर, बीटा या खराब कोडित संसाधन सर्वर ऐप पर जेएस एसडीके क्लाइंट पर एक लॉग फ़ाइल में क्वेरी पैरामेट, जो एक गैर-https साइट पर जेएस एसडीके क्लाइंट है जो access_token को एक्सेस करता है कुकी, आदि)


बीटी के उत्तर को और सरल बनाने के लिए: रीफ्रेश टोकन का उपयोग करें जब आप आम तौर पर उपयोगकर्ता को क्रेडेंशियल्स में टाइप करना नहीं चाहते हैं, लेकिन फिर भी चाहते हैं कि शक्ति अनुमतियों को निरस्त करने में सक्षम हो (ताज़ा टोकन को रद्द करके)

आप एक्सेस टोकन को निरस्त नहीं कर सकते हैं, केवल एक ताज़ा टोकन।







refresh-token