OAuth 2.0 बियरर टोकन वास्तव में क्या है?


171

RFC6750 - The OAuth 2.0 प्राधिकरण फ्रेमवर्क के अनुसार: बियर टोकन उपयोग, वाहक टोकन है:

संपत्ति के साथ एक सुरक्षा टोकन जो किसी भी पार्टी के टोकन (एक "वाहक") के कब्जे में है, किसी भी तरह से उस टोकन का उपयोग कर सकता है जो किसी अन्य पार्टी के कब्जे में है।

मेरे लिए यह परिभाषा अस्पष्ट है और मुझे कोई विनिर्देश नहीं मिल रहा है।

  • मान लीजिए मैं एक प्राधिकरण प्रदाता को लागू कर रहा हूं, क्या मैं वाहक टोकन के लिए किसी भी प्रकार की स्ट्रिंग की आपूर्ति कर सकता हूं?
  • क्या यह एक यादृच्छिक स्ट्रिंग हो सकता है?
  • क्या यह कुछ विशेषताओं के एक base64 एन्कोडिंग होना चाहिए?
    क्या इसे हैशेड किया जाना चाहिए?
  • और क्या सेवा प्रदाता को इस टोकन को मान्य करने के लिए प्राधिकरण प्रदाता को क्वेरी करने की आवश्यकता है?

किसी भी सूचक के लिए धन्यवाद।


मान लीजिए मैं एक प्राधिकरण प्रदाता को लागू कर रहा हूं, क्या मैं वाहक टोकन के लिए किसी भी प्रकार की स्ट्रिंग की आपूर्ति कर सकता हूं? यह एक यादृच्छिक स्ट्रिंग हो सकता है ?. एक्सेस टोकन प्रामाणिक 0 के OAuth 2.0 समापन बिंदुओं के माध्यम से जारी किए जाते हैं: / प्राधिकृत और / oauth / टोकन। एक्सेस टोकन प्राप्त करने के लिए आप किसी भी OAuth 2.0-संगत लाइब्रेरी का उपयोग कर सकते हैं। यदि आपके पास पहले से ही एक पसंदीदा OAuth 2.0 पुस्तकालय नहीं है, तो Auth0 कई भाषाओं और रूपरेखाओं के लिए पुस्तकालय प्रदान करता है।
भारथकुमार V

जवाबों:


146

बियरर टोकन
एक संपत्ति के साथ एक सुरक्षा टोकन जो टोकन के कब्जे में किसी भी पार्टी (एक "वाहक") किसी भी तरह से टोकन का उपयोग कर सकता है जो किसी अन्य पार्टी के कब्जे में हो सकता है। एक वाहक टोकन का उपयोग करने के लिए क्रिप्टोग्राफिक कुंजी सामग्री (प्रूफ-ऑफ-कब्जे) को साबित करने के लिए एक वाहक की आवश्यकता नहीं होती है।

बियरर टोकन आपके लिए ऑथेंटिकेशन सर्वर द्वारा बनाया गया है। जब कोई उपयोगकर्ता आपके एप्लिकेशन (क्लाइंट) को प्रमाणीकरण सर्वर प्रमाणित करता है तो वह आपके लिए टोकन ले जाता है। बियरर टोकन OAuth 2.0 के साथ उपयोग किए जाने वाले प्रमुख प्रकार के टोकन हैं। एक बियर टोकन मूल रूप से कहता है "इस टोकन एक्सेस के वाहक को दें"।

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

उदाहरण के लिए एक एपीआई का उपयोग करने के लिए आपको एक एक्सेस टोकन का उपयोग करने की आवश्यकता है। एक्सेस टोकन अल्पकालिक (एक घंटे के आसपास) हैं। आप एक नया एक्सेस टोकन प्राप्त करने के लिए वाहक टोकन का उपयोग करते हैं। एक्सेस टोकन प्राप्त करने के लिए आप ऑथेंटिकेशन सर्वर को इस क्लाइंट टोकन को अपनी क्लाइंट आईडी के साथ भेजें। इस तरह से सर्वर जानता है कि बियरर टोकन का उपयोग करने वाला एप्लिकेशन वही एप्लिकेशन है जिसके लिए बियरर टोकन बनाया गया था। उदाहरण: मैं आपके आवेदन के लिए बनाए गए एक टोकन टोकन को नहीं ले सकता और अपने आवेदन के साथ इसका उपयोग करूंगा क्योंकि यह मेरे लिए उत्पन्न नहीं हुआ था।

Google रीफ़्रेश टोकन कुछ इस तरह दिखता है: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

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

अपडेट करें:

हर इनलाइन एक्शन HTTP रिक्वेस्ट के ऑथराइजेशन हेडर में एक बियरर टोकन सेट किया गया है। उदाहरण के लिए:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

"AbCdEf123456"उपरोक्त उदाहरण में स्ट्रिंग वाहक प्राधिकरण टोकन है। यह प्रमाणीकरण सर्वर द्वारा निर्मित एक क्रिप्टोग्राफ़िक टोकन है। क्रियाओं के साथ भेजे गए सभी बियर टोकन में मुद्दा फ़ील्ड होता है, ऑडियंस फ़ील्ड के साथ फ़ॉर्मेट के URL को https: // के रूप में निर्दिष्ट करता है। उदाहरण के लिए, यदि ईमेल noreply@example.com से है, तो दर्शक https://example.com है

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

बियरर टोकन OAuth V2 मानक का हिस्सा है और व्यापक रूप से कई एपीआई द्वारा अपनाया गया है।


2
@ जेवियर एगी बियरर टोकन मूल रूप से आपका ताज़ा टोकन है और एक्सेस टोकन नहीं है।
अखिल नंबियार

13
बीयर टोकन का मतलब यह नहीं है कि इसका ताज़ा टोकन @AqeelSmith tools.ietf.org/html/rfc6750#section-6.1.1 है
सुमन कुंडू

9
पहले पैराग्राफ का तात्पर्य है कि एक बियर टोकन एक ताज़ा टोकन है और एक्सेस टोकन नहीं है। यह मामला नहीं है। बियरर टोकन से "यह विनिर्देश बताता है कि जब OAuth पहुँच टोकन एक वाहक टोकन है तो संरक्षित संसाधन अनुरोध कैसे करें।" RFC6750
डैनियल

8
जवाब पढ़ने के बाद, मैंने यह भी सोचा कि बियर टोकन और ताज़ा टोकन समान हैं। इसे स्पष्ट करने के लिए उत्तर को अद्यतन किया जाना चाहिए।
कुरियोज़ 7

2
यह जवाब बहुत ही भ्रामक है। इस उत्तर के प्रारंभिक कथन के अनुसार बियर टोकन को ताज़ा नहीं किया जाता है। कृपया सही करें।
विचार 01

67

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

लेकिन आपका प्रश्न बियरर टोकन कार्यक्षमता पर उत्तर खोजने की कोशिश कर रहा है:

मान लीजिए मैं एक प्राधिकरण प्रदाता को लागू कर रहा हूं, क्या मैं वाहक टोकन के लिए किसी भी प्रकार की स्ट्रिंग की आपूर्ति कर सकता हूं? क्या यह एक यादृच्छिक स्ट्रिंग हो सकता है? क्या यह कुछ विशेषताओं के एक base64 एन्कोडिंग होना चाहिए? क्या इसे हैशेड किया जाना चाहिए?

इसलिए, मैं यह बताने की कोशिश करूंगा कि बीयर के टोकन और ताज़ा टोकन कैसे काम करते हैं:

जब उपयोगकर्ता एसएसएल के माध्यम से एक टोकन भेजने वाले उपयोगकर्ता और पासवर्ड के लिए सर्वर से अनुरोध करता है, तो सर्वर दो चीजें लौटाता है: एक एक्सेस टोकन और एक ताज़ा टोकन

एक एक्सेस टोकन एक बियरर टोकन है जिसे आपको कंक्रीट उपयोगकर्ता के रूप में प्रमाणित करने के लिए सभी अनुरोध हेडर में जोड़ना होगा।

Authorization: Bearer <access_token>

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

एक्सेस टोकन की समय सीमा समाप्त हो जाती है (यानी 30 मिनट)। यदि पहुंच टोकन में एक लंबी समाप्ति थी, तो यह एक समस्या होगी, क्योंकि सैद्धांतिक रूप से इसे रद्द करने की कोई संभावना नहीं है। तो एक उपयोगकर्ता को एक भूमिका = "व्यवस्थापक" के साथ कल्पना करें जो "उपयोगकर्ता" में बदलता है। यदि कोई उपयोगकर्ता भूमिका के साथ पुराने टोकन को रखता है = "व्यवस्थापक" तो वह व्यवस्थापक अधिकारों के साथ टोकन समाप्ति तक पहुंच बना सकेगा। इसलिए एक्सेस टोकन की समय सीमा समाप्त हो गई है।

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

ताज़ा टोकन डीबी में संग्रहीत किए जाते हैं और लंबे समय तक समाप्ति (उदाहरण: 1 महीने) होगी।

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

यदि उपयोगकर्ता पहुँच टोकन से समझौता कर लिया गया है, तो उस उपयोगकर्ता के ताज़ा टोकन को DB से हटा दिया जाना चाहिए। इस तरह से टोकन केवल तब तक मान्य रहेगा जब तक कि टोकन समाप्त नहीं हो जाता है क्योंकि जब हैकर ताज़ा टोकन भेजकर एक नया एक्सेस टोकन प्राप्त करने का प्रयास करता है, तो इस क्रिया से इनकार कर दिया जाएगा।


2
मैं इस हिस्से को नहीं समझता: "एक बार जब प्राधिकरण सर्वर को एक्सेस टोकन प्राप्त होता है, तो वह इसे डिक्रिप्ट कर सकेगा और इन उपयोगकर्ता गुणों को पढ़ सकेगा। इस तरह, उपयोगकर्ता को मान्य किया जाएगा और सभी एप्लिकेशन के साथ प्रदान किया जाएगा"। क्या प्राधिकरण सर्वर वह नहीं है जो टोकन तक पहुँच प्रदान करता है, उसे प्राप्त नहीं करता है? मैं इस विषय के आसपास अपना सिर लाने की कोशिश कर रहा हूं और बहुत सारे उदाहरण प्राधिकरण सर्वर और संसाधन सर्वर के बीच एक स्पष्ट अंतर बनाता है। मुझे क्या समझ में आया है कि आपको ऑथराइजेशन सर्वर से ऐक्सेस टोकन मिलता है और फिर रिसोर्स सर्वर से किए जाने वाले हर रिक्वेस्ट के साथ इसे पास करते हैं?
किविकॉल

1
@kivikall आप सही हैं। मैंने इसे उत्तर में बदल दिया है। संसाधन सर्वर प्रत्येक अनुरोध में टोकन (टोकन जो प्राधिकरण सर्वर टोकन निर्माण प्रक्रिया में एन्क्रिप्ट किया गया है) प्राप्त करता है और इसे डिक्रिप्ट करता है।
जेवियर एगिया

1
@kivikall वास्तव में, टोकन को डिक्रिप्ट करने के लिए प्राधिकरण से संबंधित कुछ होना चाहिए, इसलिए यह प्राधिकरण सर्वर से संबंधित होना चाहिए। इसलिए जवाब में इसे लिखा है। लेकिन व्यवहार में, इसका मतलब यह होगा कि प्रत्येक अनुरोध में आपको प्राधिकृत सर्वर टोकन के साथ मान्य करना होगा (हो सकता है कि दूसरा अनुरोध कर रहा हो)। इसलिए, प्रदर्शन के नुकसान से बचने के लिए, संसाधन सर्वर को टोकन को डिक्रिप्ट करने के लिए कुछ कार्यक्षमता देना बेहतर है। अगले लिंक की जाँच करें: stackoverflow.com/questions/12296017/…
जेवियर एगिया

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

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

9

बियरर टोकन वर्णमाला, अंक, "-", "का एक या अधिक दोहराव है।" , "_", "~", "+", "/" के बाद 0 या अधिक "="।

RFC 6750 2.1। प्राधिकरण अनुरोध हैडर फ़ील्ड (प्रारूप ABNF (संवर्धित BNF) है)

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

यह Base64 जैसा दिखता है, लेकिन क्या हेडर में टोकन के अनुसार base64 एन्कोडेड होना चाहिए? , यह नहीं।

"HTTP / 1.1, भाग 7: प्रमाणीकरण" ** में थोड़ा गहरा खुदाई करते हुए, हालांकि, मैं देखता हूं कि b64token सिर्फ एक ABNF सिंटैक्स परिभाषा है जो आमतौर पर बेस 64, बेस 64url, आदि में उपयोग किए जाने वाले वर्णों के लिए अनुमति देता है। इसलिए b64token नहीं करता है किसी भी एन्कोडिंग या डिकोडिंग को परिभाषित करें, लेकिन केवल यह परिभाषित करता है कि प्राधिकरण शीर्षलेख के भाग में कौन से वर्णों का उपयोग किया जा सकता है जिसमें टोकन शामिल होगा।

संदर्भ


आप बियरर टोकन के सभी उद्देश्य के बारे में नहीं बता रहे हैं।
Jaime Hablutzel
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.