JWT के लिए बेस्ट HTTP ऑथराइजेशन हैडर टाइप

Question

मैं सोच रहा हूं कि JWT टोकन केAuthorization लिए सबसे उपयुक्त HTTP हेडर टाइप क्या है ।

शायद सबसे लोकप्रिय प्रकार में से एक है Basic। उदाहरण के लिए:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

यह एक लॉगिन और एक पासवर्ड जैसे दो मापदंडों को संभालता है। तो यह JWT टोकन के लिए प्रासंगिक नहीं है।

उदाहरण के लिए , मैंने बीयरर प्रकार के बारे में सुना है :

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

हालाँकि, मैं इसका अर्थ नहीं जानता। क्या यह भालू से संबंधित है?

HTTP Authorizationहेडर में JWT टोकन का उपयोग करने का एक विशेष तरीका है ? क्या हमें उपयोग करना चाहिए Bearer, या हमें सरल करना चाहिए और बस उपयोग करना चाहिए:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

धन्यवाद।

संपादित करें:

या हो सकता है, बस एक JWTHTTP हेडर:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Answer 1

आपके क्लाइंट के लिए एक्सेस टोकन (JWT या किसी अन्य टोकन) भेजने के लिए सबसे अच्छा HTTP हेडर प्रमाणीकरण योजना के Authorizationसाथ हेडर है Bearer।

यह योजना RFC6750 द्वारा वर्णित है ।

उदाहरण:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

यदि आपको मजबूत सुरक्षा सुरक्षा की आवश्यकता है, तो आप निम्नलिखित IETF मसौदे पर भी विचार कर सकते हैं: https://tools.ietf.org/html/draft-ietf-oauth-pop-altecture । यह ड्राफ़्ट (छोड़ दिया गया?) Https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac का एक अच्छा विकल्प प्रतीत होता है ।

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

कस्टम के विपरीत JWTआप अपने प्रश्न में उल्लेख योजना, एक IANA में पंजीकृत किया गया है ।Bearer

Basicऔर Digestप्रमाणीकरण योजनाओं के बारे में , वे एक उपयोगकर्ता नाम और एक गुप्त ( RFC7616 और RFC7617 देखें ) प्रमाणीकरण के लिए समर्पित हैं, इसलिए उस संदर्भ में लागू नहीं है।

Comments

धन्यवाद! इस Bearerकीवर्ड की उत्पत्ति देखने के लिए अच्छा है । लेकिन यह OAuth से आता है। हालांकि JWT का उपयोग OAuth के बिना किया जा सकता है। यह OAuth चश्मा के साथ पूरी तरह से स्वतंत्र है।

— ज़ाग ज़ग ..

हां यह OAuth2 फ्रेमवर्क प्रोटोकोल से आता है, लेकिन किसी अन्य संदर्भ में इस्तेमाल किया जा सकता है। आपका सर्वर अन्य हेडर या तरीके (जैसे शरीर अनुरोध या क्वेरी स्ट्रिंग में) का उपयोग करके JWT को स्वीकार करने के लिए स्वतंत्र है, लेकिन Authenticateहेडर अधिक उपयुक्त है और RFC7235 के साथ अनुपालन है जो HTTP 1.1 संदर्भ में एक प्रामाणिक रूपरेखा का वर्णन करता है

— फ्लोरेंस मोर्सेली

मैं ज़ैग ज़ैग के साथ सहमत हूं, "JWT" ​​जैसी एक कस्टम योजना OAuth2 बियरर योजना को इस में शामिल करने की तुलना में अधिक उपयुक्त लगती है।

— l8nite 21

यह स्वीकृत उत्तर होना चाहिए। का हवाला देते हुए jwt.io/introduction : "। उपयोगकर्ता एजेंट वाहक स्कीमा का उपयोग कर, जेडब्ल्यूटी भेजना चाहिए आम तौर पर प्राधिकरण शीर्षक में शीर्ष लेख की सामग्री के निम्नलिखित तरह दिखना चाहिए: प्राधिकरण: बियरर <टोकन>"

— wrschneider

अगर यह किसी की मदद करता है - मैं इस उदाहरण की तलाश में यहां आया था: - बियर योजना का उपयोग करके कर्ल अनुरोध:curl -H "Authorization: Bearer <TOKEN>" <the rest of your curl cmd>

— केविन फ्राइडहेम

Answer 2

संक्षिप्त जवाब

Bearerप्रमाणीकरण योजना आप के लिए क्या देख रहे है।

लंबा जवाब

क्या यह भालू से संबंधित है?

इर्रर ... नहीं :)

ऑक्सफोर्ड डिक्शनर्स के अनुसार , यहाँ वाहक की परिभाषा है :

वाहक _{^{/ ˈbɛːrə /}}
संज्ञा

1. वह व्यक्ति या वस्तु जो किसी वस्तु को धारण या धारण करती हो।

2. एक व्यक्ति जो पैसे देने के लिए चेक या अन्य आदेश प्रस्तुत करता है।

पहली परिभाषा में निम्नलिखित पर्यायवाची शब्द शामिल हैं: संदेशवाहक , एजेंट , कन्वेयर , दूत , वाहक , प्रदाता ।

और यहाँ RFC 6750 के अनुसार वाहक टोकन की परिभाषा है :

1.2। शब्दावली

बियरर टोकन

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

Bearerप्रमाणीकरण योजना है IANA में पंजीकृत है और मूल रूप में परिभाषित किया गया आरएफसी 6750 OAuth 2.0 प्राधिकरण ढांचे के लिए, लेकिन कुछ भी का उपयोग करने से बंद हो जाता है Bearerअनुप्रयोग जो OAuth 2.0 का उपयोग नहीं करते में पहुंच टोकन के लिए योजना।

जितना हो सके मानकों पर टिके रहें और अपनी प्रमाणीकरण योजनाएँ न बनाएँ।

---

प्रमाणीकरण योजना Authorizationका उपयोग करके एक पहुंच टोकन अनुरोध हैडर में भेजा जाना चाहिए Bearer:

2.1। प्राधिकरण अनुरोध हैडर फ़ील्ड

AuthorizationHTTP / 1.1 द्वारा परिभाषित अनुरोध हेडर फ़ील्ड में एक्सेस टोकन भेजते समय , क्लाइंट उपयोग करता हैBearer एक्सेस टोकन को प्रेषित करने के प्रमाणीकरण योजना का ।

उदाहरण के लिए:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

[...]

ग्राहक प्रमाणीकरण प्राधिकरण के Authorizationसाथ अनुरोध शीर्ष लेख क्षेत्र का उपयोग करके एक वाहक टोकन के साथ प्रमाणित अनुरोध कर सकते हैं Bearer। [...]

अमान्य या गुम टोकन के मामले में, Bearerयोजना को WWW-Authenticateप्रतिक्रिया शीर्षक में शामिल किया जाना चाहिए :

3. डब्ल्यूडब्ल्यूडब्ल्यू-ऑथेंटिकेटेड रिस्पॉन्स हेडर फील्ड

यदि संरक्षित संसाधन अनुरोध में प्रमाणीकरण क्रेडेंशियल शामिल नहीं है या इसमें एक्सेस टोकन नहीं है जो संरक्षित संसाधन तक पहुंच को सक्षम करता है, तो संसाधन सर्वर में HTTP शामिल होना चाहिए WWW-Authenticate प्रतिक्रिया हेडर फ़ील्ड [...] ।

इस विनिर्देशन द्वारा परिभाषित सभी चुनौतियाँ स्कीम-स्कीम मान का उपयोग करती हैं Bearer । इस योजना को एक या अधिक सामान्य-मान मानों द्वारा पालन किया जाना चाहिए। [...]।

उदाहरण के लिए, प्रमाणीकरण के बिना संरक्षित संसाधन अनुरोध के जवाब में:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

और एक संरक्षित पहुँच टोकन का उपयोग करके प्रमाणीकरण प्रयास के साथ एक संरक्षित संसाधन अनुरोध के जवाब में:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"

Comments

हाँ। यह भालू से संबंधित है। उसी तरह से जो अजगर से संबंधित है। ओह।

— निकोलस हैमिल्टन

भालू .. वह करता है। मेरा दिन बनाने के लिए आपको धन्यवाद।

— user2501323

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

— डैनियल जेनी