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




http-headers (2)

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

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

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

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

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

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

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

धन्यवाद।

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

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

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

Bearer प्रमाणीकरण योजना वह है जिसे आप खोज रहे हैं।

लंबा जवाब

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

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

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

वाहक / erbɛːrə /
संज्ञा

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

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

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

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

1.2। शब्दावली

बियरर टोकन

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

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

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

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

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

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

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

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

[...]

ग्राहक SHOULD Bearer HTTP ऑथराइजेशन स्कीम के साथ Authorization रिक्वेस्ट हेडर फ़ील्ड का उपयोग करके एक बियरर टोकन के साथ प्रमाणित अनुरोध करते हैं। [...]

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

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

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

इस विनिर्देश द्वारा परिभाषित सभी चुनौतियाँ MST-स्कीम वैल्यू 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"

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

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

उदाहरण:

GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ

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

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

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

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







jwt