JWT और OAuth प्रमाणीकरण के बीच मुख्य अंतर क्या हैं?


356

मेरे पास JWT का उपयोग करते हुए एक स्टेटलेस प्रमाणीकरण मॉडल के साथ एक नया एसपीए है। मुझे अक्सर प्रमाणीकरण प्रवाह के लिए OAuth को संदर्भित करने के लिए कहा जाता है, जैसे मुझे एक साधारण टोकन हेडर के बजाय हर अनुरोध के लिए 'बियरर टोकन' भेजने के लिए कहा जाता है, लेकिन मुझे लगता है कि OAuth एक साधारण JWT आधारित प्रमाणीकरण की तुलना में बहुत अधिक जटिल है। मुख्य अंतर क्या हैं, क्या मुझे OWuth की तरह JWT प्रमाणीकरण का व्यवहार करना चाहिए?

मैं अपने XSRF-TOKEN के रूप में JWT का उपयोग भी कर रहा हूं ताकि XSRF को रोका जा सके लेकिन मुझे उन्हें अलग रखने के लिए कहा जा रहा है? क्या मुझे उन्हें अलग रखना चाहिए? यहां किसी भी मदद की सराहना की जाएगी और समुदाय के लिए दिशानिर्देशों का एक सेट हो सकता है।

जवाबों:


330

TL; DR यदि आपके पास बहुत ही सरल परिदृश्य हैं, जैसे एकल क्लाइंट एप्लिकेशन, एक एकल एपीआई तो यह OAuth 2.0 पर जाने के लिए भुगतान नहीं कर सकता है, दूसरी तरफ, बहुत सारे अलग-अलग क्लाइंट (ब्राउज़र-आधारित, देशी मोबाइल, सर्वर-साइड) , आदि) तो OAuth 2.0 नियमों से चिपके रहना आपके सिस्टम को रोल करने की तुलना में इसे अधिक प्रबंधनीय बना सकता है।


जैसा कि एक अन्य उत्तर में कहा गया है, JWT ( Learn JSON Web टोकन ) सिर्फ एक टोकन प्रारूप है, यह पार्टियों के बीच डेटा संचारित करने के लिए एक कॉम्पैक्ट और स्व-निहित तंत्र को परिभाषित करता है जिसे सत्यापित और विश्वसनीय माना जा सकता है क्योंकि यह डिजिटल रूप से हस्ताक्षरित है। इसके अतिरिक्त, JWT के एन्कोडिंग नियम भी HTTP के संदर्भ में इन टोकन का उपयोग करना बहुत आसान बनाते हैं।

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

व्यवहार में, आप जो कर रहे हैं वह पहले से ही वाहक टोकन के आधार पर वर्गीकृत किया जा सकता है। हालांकि, यह विचार करें कि आप OAuth 2.0 संबंधित चश्मा ( RFC 6750 देखें ) द्वारा निर्दिष्ट वाहक टोकन का उपयोग नहीं कर रहे हैं । इसका तात्पर्य, AuthorizationHTTP हेडर पर निर्भर होना और Bearerप्रमाणीकरण योजना का उपयोग करना होगा ।

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

सलाह का एक अंतिम टुकड़ा, भले ही आपको पूर्ण OAuth 2.0 जाने की आवश्यकता न हो, मैं कस्टम हेडर के साथ जाने के बजाय हेडर के भीतर अपनी पहुंच टोकन पास करने की दृढ़ता से सलाह Authorizationदूंगा । यदि वे वास्तव में वाहक टोकन हैं, तो RFC 6750 के नियमों का पालन करें, यदि नहीं, तो आप हमेशा एक कस्टम प्रमाणीकरण योजना बना सकते हैं और फिर भी उस हेडर का उपयोग कर सकते हैं।

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

(स्रोत: आरएफसी 6819, खंड 5.4.1 )


2
क्या इसका मतलब है कि अगर मैं मोबाइल ऐप पर जेडब्ल्यूटी प्रमाणीकरण का उपयोग करता हूं, तो मुझे सीएसआरएफ को अपने पोस्ट अनुरोध पर शामिल करने की आवश्यकता नहीं है? रूपों के साथ वेब इंटरफ़ेस के विपरीत?
user805981

2
कुकीज़ बनाम टोकन: निश्चित मार्गदर्शिका, यानी , 00bb/cookies-vs-tokens-definitive-guide काम नहीं कर रहा है। यह एक और महान चर्चा पोस्ट है: stackoverflow.com/questions/37582444-…
सिद्धार्थ जैन

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

1
@ कोनराड, मैंने एक समान तंत्र लागू किया जो अप्रयुक्त वैध टोकन को एक तालिका में संग्रहीत करता है, जब वे समाप्त होते हैं तो उन्हें वहां से जारी करें। प्रत्येक आने वाले अनुरोध के लिए, मैंने "अप्रयुक्त वैध टोकन" के खिलाफ आने वाले टोकन की जांच करने के लिए कोड लिखा है। हालांकि यह काम करता है, मुझे हमेशा से संदेह था - अप्रयुक्त को संभालने के लिए एक बेहतर तरीका होना चाहिए लेकिन फिर भी मान्य टोकन।
टेक जंकी

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

281

OAuth 2.0 एक प्रोटोकॉल को परिभाषित करता है, अर्थात निर्दिष्ट करता है कि टोकन कैसे स्थानांतरित किए जाते हैं, JWT एक टोकन प्रारूप को परिभाषित करता है।

OAuth 2.0 और "JWT प्रमाणीकरण" के समान (2) चरण में आता है, जहां क्लाइंट रिसोर्स सर्वर को टोकन प्रस्तुत करता है: टोकन हेडर में पास होता है।

लेकिन "JWT प्रमाणीकरण" एक मानक नहीं है और यह निर्दिष्ट नहीं करता है कि क्लाइंट पहले स्थान (1 चरण) में टोकन कैसे प्राप्त करता है। यही वह जगह है जहां से OAuth की कथित जटिलता आती है: यह विभिन्न तरीकों को भी परिभाषित करता है जिसमें क्लाइंट उस चीज से एक्सेस टोकन प्राप्त कर सकता है जिसे प्राधिकरण सर्वर कहा जाता है।

तो असली अंतर यह है कि JWT सिर्फ एक टोकन प्रारूप है, OAuth 2.0 एक प्रोटोकॉल है (जो कि JWT को टोकन प्रारूप के रूप में उपयोग कर सकता है )।


10
क्या अधिकांश मामलों के लिए OAuth प्रोटोकॉल कार्यान्वयन JWT को टोकन प्रारूप के रूप में उपयोग करते हैं? यदि नहीं तो क्या सबसे आम है?
जेम्स विर्ज़बा


128

सबसे पहले, हमें JWT और OAuth में अंतर करना होगा। असल में, JWT एक टोकन प्रारूप है। OAuth एक प्राधिकरण प्रोटोकॉल है जो JWT को टोकन के रूप में उपयोग कर सकता है। OAuth सर्वर-साइड और क्लाइंट-साइड स्टोरेज का उपयोग करता है। यदि आप वास्तविक लॉगआउट करना चाहते हैं तो आपको OAuth2 के साथ जाना होगा। JWT टोकन के साथ प्रमाणीकरण वास्तव में लॉगआउट नहीं हो सकता है। क्योंकि आपके पास एक प्रमाणीकरण सर्वर नहीं है जो टोकन का ट्रैक रखता है। यदि आप 3rd पार्टी क्लाइंट को API प्रदान करना चाहते हैं, तो आपको OAuth2 का भी उपयोग करना चाहिए। OAuth2 बहुत लचीला है। JWT कार्यान्वयन बहुत आसान है और इसे लागू करने में लंबा समय नहीं लगता है। यदि आपके एप्लिकेशन को इस प्रकार के लचीलेपन की आवश्यकता है, तो आपको OAuth2 के साथ जाना चाहिए। लेकिन अगर आपको इस उपयोग-मामले के परिदृश्य की आवश्यकता नहीं है, तो OAuth2 को लागू करना समय की बर्बादी है।

XSRF टोकन हमेशा ग्राहक को हर प्रतिक्रिया हेडर में भेजा जाता है। इससे कोई फर्क नहीं पड़ता कि एक जेडआरटी टोकन में सीएसआरएफ टोकन भेजा जाता है या नहीं, क्योंकि सीएसआरएफ टोकन खुद के साथ सुरक्षित है। इसलिए JWT में CSRF टोकन भेजना अनावश्यक है।


7
मुझे समझ नहीं आ रहा है कि इस उत्तर में बहुत सारे बदलाव क्यों हैं, यह बताता है कि "OAuth एक प्रमाणीकरण ढांचा है" और यह पूरी तरह से गलत है। OAuth एक प्राधिकरण प्रोटोकॉल है और केवल एक प्राधिकरण प्रोटोकॉल है।
माइकल

4
हाय @Michael इस बारे में बहुत गलतफहमी है। मैंने अपनी टिप्पणी संपादित की धन्यवाद।
मेलिस्सा Şimşek

6
@ माइकल, कृपया अन्य bcz के उत्तर की सराहना करें, उन्होंने अपने परिष्कृत ज्ञान को हमारे साथ साझा किया और मुझे वास्तव में उत्तर का आनंद मिला।
यासिर शब्बीर चौधरी

क्या आप लोग कह रहे हैं कि Oauth मानकों का एक टुकड़ा है जो डेवलपर्स को पालन करना चाहिए? या यह वास्तव में एक ढांचा है?
स्टॉर्मट्रूपर

65

JWT (JSON वेब कैम) - यह सिर्फ एक टोकन प्रारूप है। JWT टोकन JSON एन्कोडेड डेटा संरचना में जारीकर्ता, विषय (दावे), समाप्ति समय आदि के बारे में जानकारी होती है। यह छेड़छाड़ सबूत और प्रामाणिकता के लिए हस्ताक्षरित है और इसे सममित या असममित दृष्टिकोण का उपयोग करके टोकन जानकारी की सुरक्षा के लिए एन्क्रिप्ट किया जा सकता है। JWT SAML 1.1 / 2.0 की तुलना में सरल है और सभी उपकरणों द्वारा समर्थित है और यह SWT (सिंपल वेब टोकन) से अधिक शक्तिशाली है।

OAuth2 - OAuth2 एक समस्या को हल करता है जो उपयोगकर्ता क्लाइंट सॉफ़्टवेयर का उपयोग करके ब्राउज़ आधारित वेब ऐप, मूल मोबाइल ऐप या डेस्कटॉप ऐप का उपयोग करना चाहता है। OAuth2 केवल प्राधिकरण के लिए है, क्लाइंट सॉफ़्टवेयर को टोकन का उपयोग करके अंतिम उपयोगकर्ता के संसाधनों को एक्सेस करने के लिए अधिकृत किया जा सकता है।

OpenID कनेक्ट - OpenID कनेक्ट OAuth2 के शीर्ष पर बनाता है और प्रमाणीकरण जोड़ें। OpenID कनेक्ट OAuth2 में कुछ बाधाएं जोड़ें जैसे UserInfo समापन बिंदु, आईडी टोकन, ओपनआईडी कनेक्ट प्रदाताओं और सत्र प्रबंधन के खोज और गतिशील पंजीकरण। जेडब्ल्यूटी टोकन के लिए अनिवार्य प्रारूप है।

CSRF सुरक्षा - यदि आपको ब्राउज़र की कुकी में टोकन स्टोर नहीं करना है तो आपको CSRF सुरक्षा लागू करने की आवश्यकता नहीं है।

आप अधिक जानकारी यहाँ पढ़ सकते हैं http://proficientblog.com/microservices-security/


3
कोई कुकीज़ == कोई सीएसआरएफ सुरक्षा नहीं। यदि आप प्राधिकरण के लिए कुकीज़ का उपयोग नहीं करते हैं, तो आपको CSRF सुरक्षा के बारे में चिंता करने की आवश्यकता नहीं है।
निरंजन हरपल

51

ऐसा लगता है कि यहां जवाब देने वाले हर शख्स ने OAUTH की लूट को याद किया

विकिपीडिया से

OAuth एक्सेस डेलिगेशन के लिए एक खुला मानक है, आमतौर पर इंटरनेट उपयोगकर्ताओं के लिए वेबसाइटों या एप्लिकेशन को अन्य वेबसाइटों पर उनकी जानकारी तक पहुंच प्रदान करने के लिए एक मार्ग के रूप में उपयोग किया जाता है, लेकिन उन्हें पासवर्ड दिए बिना। इस तंत्र का उपयोग Google, Facebook, Microsoft और Twitter जैसी कंपनियों द्वारा किया जाता है ताकि उपयोगकर्ताओं को तृतीय पक्ष एप्लिकेशन या वेबसाइटों के साथ अपने खातों के बारे में जानकारी साझा करने की अनुमति दी जा सके।

यहां प्रमुख मुद्दा है access delegation। जब कोई आईडी / pwd आधारित प्रमाणीकरण होता है, तो OAUTH कोई भी क्यों बनाएगा, OTPs जैसे बहुप्रचारित स्रोत द्वारा समर्थित और आगे JWTs द्वारा सुरक्षित किया जा सकता है, जो रास्तों (OAUTH में स्कोप की तरह) तक पहुंच को सुरक्षित करने के लिए उपयोग किया जाता है और इसकी समाप्ति की तिथि निर्धारित करता है पहुंच

OAUTH का उपयोग करने का कोई मतलब नहीं है अगर उपभोक्ता अपने विश्वसनीय वेबसाइटों (या ऐप्स) के माध्यम से केवल अपने संसाधनों (आपके अंतिम बिंदु) तक पहुंचते हैं, जो आपके अंतिम बिंदुओं पर फिर से होस्ट किए जाते हैं

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

एक और महत्वपूर्ण नोट:
आप स्वतंत्र रूप से authenticationJWT और OAUTH शब्द का उपयोग कर रहे हैं, लेकिन न तो प्रमाणीकरण तंत्र प्रदान करते हैं। हाँ एक टोकन तंत्र है और दूसरा प्रोटोकॉल है लेकिन एक बार प्रमाणित होने के बाद वे केवल प्राधिकरण (एक्सेस प्रबंधन) के लिए उपयोग किए जाते हैं। आप OAUTH को या तो OPENID प्रकार प्रमाणीकरण या अपने स्वयं के क्लाइंट क्रेडेंशियल्स के साथ वापस करना चाहते हैं


4
OAuth का उपयोग आपके अपने ग्राहकों के लिए भी किया जा सकता है, जरूरी नहीं कि वे केवल 3 पार्टी वाले हों। पासवर्ड क्रेडेंशियल ग्रांट प्रकार बिल्कुल यही करता है।
हरप्रताप

1
मैं इस तरह के ठोस जवाब के लिए गूगल की तलाश कर रहा था, लेकिन एक नहीं मिला। हर कोई सिर्फ टोकन बनाम प्रोटोकॉल जैसी परिभाषाओं की बात कर रहा था। आपके उत्तर ने एक के ऊपर एक का उपयोग करने का सही उद्देश्य समझाया। आपको बहुत - बहुत धन्यवाद!
विवेक गोयल

9

JWT और OAuth के बीच मुख्य अंतर खोजें

  1. OAuth 2.0 एक प्रोटोकॉल को परिभाषित करता है और JWT एक टोकन प्रारूप को परिभाषित करता है।

  2. OAuth JWT को टोकन फॉर्मेट या एक्सेस टोकन के रूप में उपयोग कर सकता है जो बियरर टोकन है।

  3. OpenID कनेक्ट ज्यादातर JWT को एक टोकन प्रारूप के रूप में उपयोग करते हैं।


6

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

जबकि OAuth2 एक प्राधिकरण ढांचा है, जहां इसकी रूपरेखा द्वारा परिभाषित सामान्य प्रक्रियाएं और सेटअप हैं। JWT को OAuth2 के अंदर एक तंत्र के रूप में इस्तेमाल किया जा सकता है।

आप यहाँ इस पर अधिक पढ़ सकते हैं

OAuth या JWT? कौन सा उपयोग करना है और क्यों?


5

सवाल एक आम है, लेकिन यह काफी समझदार नहीं है। JWT एक प्रकार का टोकन है, और OAuth एक फ्रेमवर्क है, जो बताता है कि टोकन को कैसे बांटना है।

"फ्रेमवर्क" से हमारा क्या तात्पर्य है? बस अनुरोधों और प्रतिक्रियाओं का क्रम, और उन स्वरूपों, जो टोकन का अनुरोध करने के लिए इस्तेमाल किया जा सकता है। OAuthv2 अलग-अलग परिदृश्यों के लिए अलग-अलग "प्रवाह" या अनुदान प्रकारों का वर्णन करता है, और विशेष प्रवाह की सुरक्षा बढ़ाने के लिए अलग-अलग एक्सटेंशन (जैसे PKCE) हैं।

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

JWT एक विशेष प्रकार का टोकन है, और JWT को पूरी तरह से OAuth बियरर टोकन के रूप में इस्तेमाल किया जा सकता है। वास्तव में, यह सबसे आम अभ्यास है। उस के प्रकाश में, "JWT बनाम OAuth" सेब और सेब की गाड़ियों की तुलना है।

अक्सर लोग सोचते हैं कि "OAuth टोकन" का अर्थ हमेशा एक अपारदर्शी टोकन होता है - अल्फ़ान्यूमेरिक वर्णों का एक यादृच्छिक अनुक्रम जिसमें कोई अंतर्निहित अर्थ नहीं होता है - जो कि OAuth टोकन औषधालय द्वारा प्रदान किया जाता है, फिर इसे केवल उसी OAuth डिस्पेंसरी सिस्टम के लिए मान्य किया जा सकता है। लेकिन यह OAuth टोकन का एकमात्र प्रकार नहीं है। एक अपारदर्शी टोकन एक प्रकार का टोकन है; JWT को OAuth टोकन के एक अलग प्रकार के रूप में इस्तेमाल किया जा सकता है।

JWT, इसके विपरीत, अपारदर्शी नहीं हैं। JWT एक "पॉइंटर" या सूचना का संदर्भ नहीं है। इसमें वास्तव में बहुत सारी विशिष्ट जानकारी होती है, जिसे टोकन द्वारा किसी भी पार्टी द्वारा निकाला और व्याख्या किया जा सकता है। क्योंकि JWT में वास्तविक जानकारी होती है, एक JWT बड़ी हो सकती है; 300 बाइट्स, 500 बाइट्स, या अधिक, इसके भीतर निहित दावों और इस पर हस्ताक्षर करने के लिए उपयोग किए गए एल्गोरिदम पर निर्भर करता है। जब लोग कहते हैं कि "JWT स्व-वैध हैं" उनका क्या मतलब है, JWT का कोई भी धारक इसे खोल सकता है, इसे सत्यापित कर सकता है, और फिर इसमें प्रस्तुत दावों के आधार पर प्राधिकरण निर्णय कर सकता है। JWT को मान्य करने का अर्थ है: इसकी संरचना को सत्यापित करना, बेस 64 एन्कोडिंग को डिकोड करना, कुंजी को सत्यापित करना सही है, हस्ताक्षर की पुष्टि करना, फिर आवश्यक दावों को सत्यापित करना टोकन में मौजूद हैं, समाप्ति की जांच करना। यह एक साधारण बात नहीं है, बल्कि एक बहु-चरणीय प्रक्रिया है, लेकिन निश्चित रूप से विभिन्न प्रोग्रामिंग भाषाओं में बहुत सारे पुस्तकालय हैं जो इसके साथ हेक्लिप करते हैं, और निश्चित रूप से वेरिफाईजडब्ल्यूटी नीति है जो आपको एपिगी एज एपीआई प्रॉक्सी के भीतर ऐसा करने में मदद करती है। मुद्दा यह है कि कोई भी धारक या रिसीवर टोकन को सत्यापित कर सकता है। इस वजह से, हम कहते हैं कि JWT "फेडरेशन" का समर्थन करता है - कोई भी एक टोकन उत्पन्न कर सकता है, और कोई भी टोकन को पढ़ और मान्य कर सकता है।

कस्टम का दावा है। JWT और अपारदर्शी OAuth टोकन दोनों विषय के बारे में कस्टम दावे कर सकते हैं। सुरक्षा। दोनों सहनशील टोकन हैं। दोनों को रहस्य के रूप में संरक्षित करने की आवश्यकता है। समाप्ति। दोनों को एक समाप्ति के साथ चिह्नित किया जा सकता है। दोनों को तरोताजा किया जा सकता है। प्रमाणीकरण तंत्र या अनुभव। दोनों एक ही उपयोगकर्ता अनुभव प्रस्तुत कर सकते हैं।


0

Jwt हस्ताक्षरित टोकन जारी करने और मान्य करने के लिए निर्देशों का एक सख्त सेट है। टोकन में ऐसे दावे होते हैं जो किसी ऐप द्वारा किसी उपयोगकर्ता तक पहुंच को सीमित करने के लिए उपयोग किए जाते हैं

दूसरी ओर OAuth2 एक प्रोटोकॉल नहीं है, इसका एक प्रतिनिधि प्राधिकरण ढांचा है। उपयोगकर्ताओं और अनुप्रयोगों को निजी और सार्वजनिक दोनों सेटिंग्स में अन्य अनुप्रयोगों के लिए विशिष्ट अनुमति देने के लिए अधिकृत करने के लिए बहुत विस्तृत दिशानिर्देश के बारे में सोचें। OpenID कनेक्ट, जो OAUTH2 के शीर्ष पर बैठता है, आपको प्रमाणीकरण और प्राधिकरण देता है। यह ब्योरा देता है कि आपके सिस्टम में कितनी अलग-अलग भूमिकाएँ, उपयोगकर्ता, API जैसे सर्वर साइड ऐप, और वेबसाइट या देशी मोबाइल ऐप जैसे क्लाइंट, एक-एक को प्रमाणित कर सकते हैं।

नोट oauth2 jwt के साथ काम कर सकता है, लचीला कार्यान्वयन, विभिन्न अनुप्रयोगों के लिए अतिरिक्त


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