जेडब्ल्यूटी

Question

के लिए सर्वश्रेष्ठ HTTP प्रमाणीकरण शीर्षलेख प्रकार मैं सोच रहा हूं कि HTTP शीर्षलेख प्रकार JWT tokens के लिए सबसे अच्छा उचित क्या है।

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

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

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

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

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

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

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

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

धन्यवाद।

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

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

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

Answer 1

ए जेडब्ल्यूटी टोकन ओएथ के बिना उपयोग किया जा सकता है।

इस प्रकार, एक साधारण "Authorization: JWT <your_token>" अधिक उपयुक्त होगा।

उदाहरण:

curl -H "Authorization: JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" https://api.domain.tld/me/account 

Answer 2

अपने ग्राहक पहुंच टोकन (जेडब्ल्यूटी या किसी अन्य टोकन) भेजने के लिए के लिए सबसे अच्छा 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 का एक अच्छा विकल्प प्रतीत होता है।

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

कस्टम JWT योजना के विपरीत आप अपने प्रश्न, the Bearer one is registered at the IANA में उल्लेख करते हैं। उस संदर्भ में तो लागू नहीं (RFC7616 और RFC7617 देखें)

Basic और Digest प्रमाणीकरण स्कीम के संबंध में, वे एक उपयोगकर्ता नाम और एक गुप्त का उपयोग कर प्रमाणीकरण करने के लिए समर्पित कर रहे हैं।

Answer 3

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

एरर ... नहीं!

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

1.2. Terminology

बियरर टोकन

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

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

जितना हो सके मानकों पर चिपके रहें और अपनी खुद की प्रमाणीकरण योजनाएं न बनाएं।

---

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

2.1. Authorization Request Header Field

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

उदाहरण के लिए: Bearer HTTP प्राधिकरण योजना के साथ Authorization अनुरोध हेडर क्षेत्र का उपयोग कर एक वाहक टोकन के माध्यम से

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

[...]

ग्राहक प्रमाणीकृत करना चाहिए अनुरोध। [...]

अवैध या टोकन गुम होने की स्थिति में Bearer योजना WWW-Authenticate प्रतिक्रिया हेडर में शामिल किया जाना चाहिए:

3. The WWW-Authenticate Response Header Field

संरक्षित संसाधन अनुरोध शामिल नहीं है प्रमाणीकरण प्रमाण-पत्र या इसमें कोई एक्सेस टोकन नहीं है जो संरक्षित संसाधन तक पहुंच को सक्षम बनाता है, संसाधन सर्वर में 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"