JWT (Json वेब टोकन) ऑडियंस "ऑड" बनाम Client_Id - क्या अंतर है?

Question

मैं अपने प्रमाणीकरण सर्वर में OAuth 2.0 JWT access_token को लागू करने पर काम कर रहा हूं। लेकिन, JWT audक्लेम और client_idHTTP हेडर वैल्यू के बीच क्या अंतर हैं, इस पर मैं स्पष्ट नहीं हूं । क्या यह वही है? यदि नहीं, तो क्या आप दोनों के बीच अंतर बता सकते हैं?

मेरा संदेह यह है कि audसंसाधन सर्वर (ओं) client_idको संदर्भित करना चाहिए , और प्रमाणीकरण सर्वर (यानी वेब ऐप, या आईओएस ऐप) द्वारा मान्यता प्राप्त ग्राहक अनुप्रयोगों में से एक को संदर्भित करना चाहिए।

मेरे वर्तमान मामले में, मेरा संसाधन सर्वर मेरा वेब ऐप क्लाइंट भी है।

Answer 1

जैसा कि यह पता चला है, मेरा संदेह सही था। audएक JWT में दर्शकों का दावा संसाधन सेवकों को संदर्भित करना है जो टोकन को स्वीकार करना चाहिए।

इस पोस्ट के रूप में बस यह डालता है:

एक टोकन के दर्शकों को टोकन का इरादा प्राप्तकर्ता है।

दर्शकों का मूल्य एक स्ट्रिंग है - आम तौर पर, संसाधन का आधार पता, जैसे कि एक्सेस किया जा रहा है https://contoso.com।

client_idOAuth में क्लाइंट अनुप्रयोग है कि संसाधन सर्वर से संसाधनों का अनुरोध किया जाएगा को दर्शाता है।

क्लाइंट ऐप (जैसे आपका iOS ऐप) आपके प्रमाणीकरण सर्वर से एक JWT का अनुरोध करेगा। ऐसा करने में, यह इसे पास करता है client_idऔर client_secretइसके साथ किसी भी उपयोगकर्ता क्रेडेंशियल की आवश्यकता होती है। प्राधिकरण सर्वर क्लाइंट का उपयोग करता है client_idऔर client_secretJWT देता है।

JWT में एक audदावा शामिल होगा जो निर्दिष्ट करता है कि JWT किस संसाधन सर्वर के लिए वैध है। यदि audइसमें शामिल है www.myfunwebapp.com, लेकिन क्लाइंट ऐप JWT का उपयोग करने की कोशिश करता है www.supersecretwebapp.com, तो एक्सेस से इनकार कर दिया जाएगा क्योंकि रिसोर्स सर्वर यह देखेगा कि JWT इसके लिए नहीं था।

Comments

ऐसा लगता है कि ऑड क्लाइंट_ड भी हो सकता है। उपकरण देखें ।ietf.org aud REQUIRED for session_token. Contains the client_id of the client receiving the assertion.

— id/

रिसोर्स सर्वर को यह पता नहीं होता है कि क्लाइंट JWT को कहां भेजता है। संसाधन सर्वर आपके iOS-ऐप से किसी अन्य URL पर ऐसे ट्रैफ़िक को कैसे अस्वीकार करेगा? मुझे नहीं लगता कि आप सही हैं।

— जॉन कोर्न्स

मैं कहता हूं "अगर" ऑड "में" www.webapp.com "शामिल है, लेकिन क्लाइंट ऐप JWT को" secret.webapp.com "पर उपयोग करने की कोशिश करता है

— catamphetamine

RFC का कहना है कि ऑडियंस (ऑड) प्राप्तकर्ताओं की पहचान करता है। प्राप्तकर्ता आपके JWT टोकन प्राप्त करते हैं। यदि आपके पास एक वेब ऐप है तो यह शायद contoso.com हो सकता है, लेकिन अगर आपके पास कुछ डेस्कटॉप या मोबाइल ऐप हैं (जो प्रमाणित करता है) तो दर्शकों के पास कोई URI नहीं है। जारीकर्ता वह है जो सर्वर के सबसे संभवतः पते को JWT टोकन जेनरेट करता है। RFC का कहना है कि इस दावे का उपयोग वैकल्पिक है, इसलिए इसका उपयोग केवल तब करें जब आपको इसकी आवश्यकता हो।

— कोनराड

वास्तव में मुझे भ्रम है कि दर्शकों और जारीकर्ता के बीच अंतर क्या होगा।

— एंडी

Answer 2

JWT aud(श्रोता) का दावा

RFC 7519 के अनुसार :

"ऑड" (श्रोता) दावा उन प्राप्तकर्ताओं की पहचान करता है जो JWT के लिए अभिप्रेत है। प्रत्येक प्रिंसिपल का इरादा JWT MUST को संसाधित करने का है जो दर्शकों के दावे में एक मूल्य के साथ खुद को पहचानता है। यदि दावा संसाधित करने वाला प्रमुख स्वयं "ऑड" दावे में एक मूल्य के साथ खुद की पहचान नहीं करता है जब यह दावा मौजूद है, तो जेडब्ल्यूटी एमयूटी खारिज कर दिया जाना चाहिए। सामान्य स्थिति में, "ऑड" मान केस-सेंसिटिव स्ट्रिंग्स का एक सरणी है, प्रत्येक में एक स्ट्रिंगऑनरी मान होता है। विशेष मामले में जब JWT में एक दर्शक होता है, तो "ऑड" मूल्य Mring एक एकल-संवेदनशील स्ट्रिंग होता है जिसमें StringOrURI मान होता है। दर्शकों के मूल्यों की व्याख्या आम तौर पर विशिष्ट अनुप्रयोग है। इस दावे का उपयोग वैकल्पिक है।

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

जो भी मूल्य है, जब कोई प्राप्तकर्ता JWT को मान्य कर रहा है और यह मान्य करना चाहता है कि टोकन का उपयोग इसके उद्देश्यों के लिए किया जाना था, तो यह निर्धारित करना होगा कि audपहचान करने वाले में क्या मूल्य है, और टोकन केवल तभी मान्य होना चाहिए जब प्राप्तकर्ता की घोषित आईडी है audदावे में पेश है । इससे कोई फर्क नहीं पड़ता कि यह URL या कोई अन्य एप्लिकेशन विशिष्ट स्ट्रिंग है। उदाहरण के लिए यदि मेरा सिस्टम खुद audको स्ट्रिंग के साथ पहचानता है, api3.app.comतो यह केवल JWT को स्वीकार करना चाहिए, यदि audदावा इसमें api3.app.comदर्शकों के मूल्यों की सूची में है।

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

विनिर्देश के आधार पर मेरी व्याख्या यह है कि audदावा उद्देश्य-निर्मित JWTs बनाने के लिए उपयोगी है जो केवल कुछ उद्देश्यों के लिए मान्य हैं। एक प्रणाली के लिए इसका मतलब हो सकता है कि आप एक टोकन को कुछ सुविधाओं के लिए मान्य होना चाहते हैं, लेकिन दूसरों के लिए मान्य नहीं है। आप टोकन जारी कर सकते हैं जो केवल एक निश्चित "दर्शकों" तक ही सीमित हैं, जबकि अभी भी एक ही कुंजी और सत्यापन एल्गोरिथ्म का उपयोग कर रहे हैं।

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

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

उदाहरण: प्रवेश बनाम ताज़ा करें टोकन

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

का उपयोग करके audहम refreshताज़ा टोकन के लिए दावा कर सकते हैं और accessइन टोकन बनाने पर पहुँच टोकन के लिए दावा कर सकते हैं । जब एक ताज़ा टोकन से एक नया एक्सेस टोकन प्राप्त करने के लिए अनुरोध किया जाता है, तो हमें यह सत्यापित करने की आवश्यकता है कि ताज़ा टोकन एक वास्तविक ताज़ा टोकन था। audसत्यापन जैसा कि ऊपर वर्णित हमें बता देंगे टोकन वास्तव में एक वैध ताज़ा के एक दावे के लिए विशेष रूप से देख कर टोकन था कि क्या refreshमें aud।

OAuth क्लाइंट आईडी बनाम JWT audक्लेम

OAuth क्लाइंट आईडी पूरी तरह से असंबंधित है, और JWT के audदावों का कोई सीधा संबंध नहीं है। OAuth के दृष्टिकोण से, टोकन अपारदर्शी वस्तुएं हैं।

जो आवेदन इन टोकन को स्वीकार करता है, वह इन टोकन के अर्थ को पार्स और मान्य करने के लिए जिम्मेदार है। मुझे JWT audदावे के भीतर OAuth क्लाइंट आईडी निर्दिष्ट करने में बहुत अधिक मूल्य नहीं दिखता है ।

Comments

मैं पूरी तरह से फजी हूँ "बिट को ही पहचानना चाहिए"। RFC7519 इस तरह अस्पष्टीकृत बिट्स से भरा हुआ है, साथ ही अन्य ऑर्गेनिक सिस्टम के लिए अस्पष्ट गठजोड़ के साथ, जो कि संभव है कि मानक दावों के क्षेत्रों की उचित व्याख्या पाई जाए। सच कहूँ तो, RFC, जितना उपयोगी हो सकता है, ऐसी अवस्था में ड्राफ्ट स्टेज कभी नहीं छोड़ना चाहिए।

— चक एडम्स

@ChuckAdams मैंने अपने विचारों को स्पष्ट करने के लिए संपादन किया। मैं मानता हूं कि RFC "मानक दावों" के आसपास विशेष रूप से अस्पष्ट है और उनका उपयोग कैसे / कब करना है।

— कोकोआ

हमारे पास वर्तमान में ऑड-फ़ील्ड का उपयोग करने के तरीके पर एक ही चर्चा है और मैं सहमत हूं कि इसमें प्राप्तकर्ता को शामिल किया गया है (जो टोकन को मान्य करता है और स्वीकार करता है) और क्लाइंट_आईडी (एक, जिसने टोकन पर कार्रवाई करने के लिए कहा है) उपयोगकर्ता की ओर से)।

— हार्डीसिम

Answer 3

यदि आप यहाँ OpenID Connect (OIDC) खोज कर आए हैं: OAuth 2.0! = OIDC

मैं मानता हूं कि यह oauth 2.0 और NOT OIDC के लिए टैग किया गया है , हालांकि 2 मानकों के बीच अक्सर एक टकराव होता है क्योंकि दोनों मानक JWTs और दावे का उपयोग कर सकते हैं aud। और एक (OIDC) मूल रूप से दूसरे (OAUTH 2.0) का विस्तार है। (मैं खुद OIDC की तलाश में इस सवाल पर लड़खड़ा गया।)

OAuth 2.0 एक्सेस टोकन ##

OAuth 2.0 एक्सेस टोकन के लिए , मौजूदा उत्तर बहुत अच्छी तरह से कवर करते हैं। इसके अतिरिक्त यहाँ OAuth 2.0 फ्रेमवर्क (RFC 6749) से एक प्रासंगिक अनुभाग है

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

OIDC ID टोकन ##

ओआईडीसी में एक्सेस टोकन के अलावा आईडी टोकन भी हैं। audआईडी टोकन में दावे के उपयोग पर OIDC कल्पना स्पष्ट है । ( ओपन-कनेक्ट-कोर-1.0 )

लेखापरीक्षा की गई
। श्रोता (ओं) कि इस आईडी टोकन के लिए इरादा है। इसमें ऑडियंस वेल्यू के रूप में Relying Party का OAuth 2.0 क्लाइंट_आईडी होना आवश्यक है। यह भी अन्य दर्शकों के लिए पहचानकर्ता होते हैं। सामान्य स्थिति में, ऑड वैल्यू केस संवेदनशील स्ट्रिंग्स का एक सरणी है। आम विशेष मामले में जब एक दर्शक होता है, तो ऑड वैल्यू एक एकल केस संवेदनशील स्ट्रिंग होता है।

इसके अलावा OIDC उस azpदावे को निर्दिष्ट करता है जो एक से अधिक मूल्य audहोने पर संयोजन के साथ उपयोग किया जाता है aud।

azp
वैकल्पिक। अधिकृत पार्टी - वह पार्टी जिसे आईडी टोकन जारी किया गया था। यदि मौजूद है, तो उसके पास इस पार्टी का OAuth 2.0 क्लाइंट आईडी होना चाहिए। इस क्लेम की जरूरत तभी पड़ती है जब आईडी टोकन की एक ही ऑडियंस वैल्यू हो और वह ऑडियंस अधिकृत पार्टी से अलग हो। यह तब भी शामिल किया जा सकता है जब अधिकृत पार्टी एकमात्र दर्शकों के समान हो। Azp मान एक केस संवेदनशील स्ट्रिंग है जिसमें StringOrURI मान होता है।

Comments

बस एक बात पर ध्यान दें: Oauth2 JWT के उपयोग को बाध्य नहीं करता है।

— ज़ोरान

Answer 4

हालांकि यह पुराना है, मुझे लगता है कि सवाल आज भी मान्य है

मेरा संदेह यह है कि ऑड को रिसोर्स सर्वर (नों) को संदर्भित करना चाहिए, और क्लाइंट_ड को ऑथेंटिकेशन सर्वर द्वारा मान्यता प्राप्त क्लाइंट एप्लिकेशन में से एक को संदर्भित करना चाहिए।

हां, ऑड को टोकन लेने वाली पार्टी का उल्लेख करना चाहिए। और client_id टोकन प्राप्त करने वाली पार्टी को संदर्भित करता है।

मेरे वर्तमान मामले में, मेरा संसाधन सर्वर मेरा वेब ऐप क्लाइंट भी है।

ओपी के परिदृश्य में, वेब ऐप और संसाधन सर्वर दोनों एक ही पार्टी के हैं। तो इसका मतलब क्लाइंट और ऑडियंस एक ही होना है। लेकिन ऐसी परिस्थितियां हो सकती हैं जहां यह मामला नहीं है।

एक एसपीए के बारे में सोचें जो एक OAuth संरक्षित संसाधन का उपभोग करता है। इस परिदृश्य में एसपीए ग्राहक है। संरक्षित संसाधन पहुंच टोकन के दर्शक हैं।

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