JWS और JWT की नीतियों की खास जानकारी

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी

इस विषय में, JWT (JSON वेब टोकन) और JWS (JSON Web Signature) और Apigee JWS/JWT की नीतियों के बारे में सामान्य जानकारी दी गई है. ये नीतियां Apigee के प्रॉक्सी डेवलपर को पसंद आ सकती हैं.

शुरुआती जानकारी

आम तौर पर, JWS और JWT, दोनों का इस्तेमाल कनेक्ट किए गए ऐप्लिकेशन के बीच दावे या दावे शेयर करने के लिए किया जाता है. JWS/JWT की नीतियां, Edge API की प्रॉक्सी को इन कामों के लिए चालू करती हैं:

• साइन किया गया JWT या JWS जनरेट करें.
• साइन किए गए JWT या JWS की पुष्टि करें और साथ ही, JWS/JWT में दावे की पुष्टि करें.
• हस्ताक्षर की पुष्टि किए बिना, साइन किए गए JWT या JWS को डिकोड करें.

बाद के दो मामलों में, नीति ऐसे वैरिएबल भी सेट करती है जो अतिरिक्त नीतियों या बैकएंड सेवाओं को अनुमति देती हैं. इनकी मदद से, पुष्टि किए गए दावों की जांच की जाती है और उन दावों के आधार पर फ़ैसले लिए जाते हैं.

पुष्टि करें JWS/JWT नीति का इस्तेमाल करने पर, कोई अमान्य JWS/JWT अस्वीकार कर दिया जाएगा और इससे गड़बड़ी की स्थिति बनेगी. इसी तरह, Decode JWS/JWT नीति का इस्तेमाल करने पर, किसी गलत JWS/JWT का इस्तेमाल करने पर गड़बड़ी की स्थिति बनेगी.

वीडियो

JWT के बारे में तुरंत जानकारी पाने के लिए यह छोटा वीडियो देखें. इस वीडियो को खास तौर पर JWT जनरेट करने के लिए बनाया गया है. हालांकि, JWS के कई कॉन्सेप्ट एक जैसे ही हैं.

JWT के स्ट्रक्चर के बारे में ज़्यादा जानकारी देने वाला छोटा वीडियो.

इस्तेमाल के उदाहरण

इन कामों के लिए JWS/JWT की नीतियों का इस्तेमाल किया जा सकता है:

• Edge प्रॉक्सी के प्रॉक्सी या टारगेट एंडपॉइंट साइड पर नया JWS/JWT जनरेट करें. उदाहरण के लिए, ऐसा प्रॉक्सी रिक्वेस्ट फ़्लो बनाया जा सकता है जो JWS/JWT जनरेट करता है और उसे क्लाइंट को देता है. इसके अलावा, आपके पास प्रॉक्सी को इस तरह डिज़ाइन करने का विकल्प है कि वह टारगेट अनुरोध फ़्लो पर JWS/JWT जनरेट करे और उसे टारगेट को भेजे गए अनुरोध से अटैच कर दे. इसके बाद, इन दावों का इस्तेमाल बैकएंड सेवाओं को, बेहतर सुरक्षा प्रोसेसिंग के लिए करने के लिए किया जा सकेगा.
• इनबाउंड क्लाइंट अनुरोधों, टारगेट सेवा के रिस्पॉन्स, सेवा कॉलआउट की नीति के जवाबों या अन्य सोर्स से मिले JWS/JWT के दावों की पुष्टि करके उन्हें एक्सट्रैक्ट करें. Edge, JWS/JWT पर हस्ताक्षर की पुष्टि करेगा. चाहे JWS/JWT किसी तीसरे पक्ष ने जनरेट किया हो या खुद Edge ने आरएसए या एचएमएसी एल्गोरिदम का इस्तेमाल किया हो.
• JWS/JWT डिकोड करें. डिकोड करना तब सबसे ज़्यादा कारगर साबित होता है, जब इसे 'पुष्टि JWS/JWT नीति' के साथ इस्तेमाल किया जाता है. ऐसा तब करना चाहिए, जब JWS/JWT के अंदर किसी दावे (JWT) या हेडर (JWS/JWT) की वैल्यू की पुष्टि करने से पहले, आपको JWS/JWT की पुष्टि करनी पड़े.

JWS/JWT के हिस्से

साइन किया गया JWS/JWT पीरियड से अलग किए गए तीन हिस्सों में जानकारी को कोड में बदलता है: हेडर, पेलोड, और सिग्नेचर:

header.payload.signature

• JWS/JWT जनरेट करने की नीति, सभी तीन हिस्सों को बनाती है.
• पुष्टि करें JWS/JWT नीति में तीनों हिस्सों की जांच की जाती है.
• Decode JWS/JWT नीति सिर्फ़ हेडर और पेलोड की जांच करती है.

JWS से detached फ़ॉर्मैट भी काम करता है, जो JWS से पेलोड को हटा देता है:

header..signature

अलग किए गए JWS में, पेलोड को JWS से अलग भेजा जाता है. रॉ और बिना कोड वाले JWS पेलोड की जानकारी देने के लिए, पुष्टि करें JWS नीति के <DetachedContent> एलिमेंट का इस्तेमाल किया जा सकता है. इसके बाद, पुष्टि करें JWS नीति, <DetachedContent> एलिमेंट से बताए गए पेलोड और JWS में हेडर और सिग्नेचर का इस्तेमाल करके JWS की पुष्टि करती है.

टोकन और उन्हें कोड में बदलने और साइन करने के तरीके के बारे में ज़्यादा जानने के लिए, यहां देखें:

• जेडब्लयूटी: आईईटीएफ़ RFC7519
• जेडब्ल्यूएस: आईईटीएफ़ RFC7515

JWS और JWT के बीच अंतर

कनेक्ट किए गए ऐप्लिकेशन के बीच दावे या दावे शेयर करने के लिए, JWT या JWS का इस्तेमाल किया जा सकता है. इन दोनों के बीच का बड़ा अंतर पेलोड का प्रतिनिधित्व है:

• जेडब्लयूटी
  • पेलोड हमेशा एक JSON ऑब्जेक्ट होता है
  • पेलोड हमेशा JWT से जुड़ा रहता है
  • टोकन का typ हेडर हमेशा JWT पर सेट होता है
• JWS
  • पेलोड को किसी भी फ़ॉर्मैट में दिखाया जा सकता है, जैसे कि JSON ऑब्जेक्ट, बाइट स्ट्रीम, ऑक्टेट स्ट्रीम वगैरह
  • पेलोड को JWS से अटैच करना ज़रूरी नहीं है

JWT फ़ॉर्मैट हमेशा पेलोड को दिखाने के लिए, JSON ऑब्जेक्ट का इस्तेमाल करता है. इसलिए, Edge generate JWT और पुष्टि करने वाली JWT की नीतियां, रजिस्टर किए गए सामान्य दावों के नामों को मैनेज करने के लिए काम करती हैं. जैसे, aud, iss, sub वगैरह. इसका मतलब है कि इन दावों को पेलोड में सेट करने के लिए, JWT जनरेट करने की नीति के एलिमेंट का इस्तेमाल किया जा सकता है. साथ ही, इनकी वैल्यू की पुष्टि करने के लिए, 'JWT की पुष्टि करें' नीति के एलिमेंट का भी इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, JWT की खास बातों में रजिस्टर किए गए दावों के नाम वाला सेक्शन देखें.

जनरेट किए गए कुछ चुनिंदा दावों के नामों के साथ-साथ, JWT जनरेट करने की नीति सीधे तौर पर JWT में आर्बिट्रेरी नाम वाले दावे जोड़ने की सुविधा देती है. हर दावा एक आसान नाम/वैल्यू पेयर होता है. इसमें वैल्यू, टाइप नंबर, बूलियन, स्ट्रिंग, मैप या अरे हो सकती है.

हालांकि, JWS पेलोड के लिए किसी भी डेटा रिप्रज़ेंटेशन का इस्तेमाल कर सकता है, इसलिए पेलोड पर दावे नहीं जोड़े जा सकते. JWS से जुड़ी नीति के तहत, JWS के हेडर में आर्बिट्रेरी नाम वाले दावे जोड़े जा सकते हैं. साथ ही, JWS नीतियां अलग किए गए पेलोड के साथ काम करती हैं, जहां JWS को पेलोड को छोड़ दिया जाता है. डिटैच्ड पेलोड की मदद से, JWS और पेलोड को अलग-अलग भेजा जा सकता है. साथ ही, यह सुरक्षा के कई स्टैंडर्ड के लिए ज़रूरी होता है.

सिग्नेचर एल्गोरिदम के बारे में जानकारी

JWS/JWT की पुष्टि करने वाली और JWS/JWT जनरेट करने की नीतियां, आरएसए, आरएसएएसए-पीएसएस, ईसीडीएसए, और एचएमएसी एल्गोरिदम के साथ काम करती हैं. इनके लिए, बिट की स्ट्रेंथ 256, 384 या 512 के SHA2 चेकसम का इस्तेमाल किया जाता है. JWS/JWT डिकोड करने की नीति इस बात पर ध्यान दिए बिना काम करती है कि JWS/JWT को साइन करने के लिए इस्तेमाल किए गए किसी भी एल्गोरिदम का इस्तेमाल किया जा रहा है या नहीं.

एचएमएसी एल्गोरिदम

एचएमएसी एल्गोरिदम, शेयर किए गए सीक्रेट सीक्रेट का इस्तेमाल करता है, जिसे सीक्रेट कुंजी कहा जाता है. इससे हस्ताक्षर बनाने और हस्ताक्षर की पुष्टि करने में मदद मिलती है. इसे JWS/JWT के तौर पर भी जाना जाता है.

सीक्रेट कुंजी की कम से कम लंबाई, एल्गोरिदम की बिट क्षमता पर निर्भर करती है:

• HS256: कुंजी की कम से कम लंबाई 32 बाइट
• HS386: कुंजी की कम से कम लंबाई 48 बाइट
• HS512: कुंजी की कम से कम लंबाई 64 बाइट

आरएसए एल्गोरिदम

आरएसए एल्गोरिदम, क्रिप्टोग्राफ़िक हस्ताक्षर के लिए, सार्वजनिक/निजी की-पेयर का इस्तेमाल करता है. आरएसए सिग्नेचर की मदद से, हस्ताक्षर करने वाला पक्ष, JWS/JWT को साइन करने के लिए आरएसए निजी कुंजी का इस्तेमाल करता है. साथ ही, पुष्टि करने वाली पार्टी, JWS/JWT पर हस्ताक्षर की पुष्टि करने के लिए, मेल खाने वाली आरएसए सार्वजनिक कुंजी का इस्तेमाल करती है. कुंजियों के लिए साइज़ की कोई शर्त नहीं है.

आरएसएएसए-पीएसएस एल्गोरिदम

आरएसएएसएसए-पीएसएस एल्गोरिदम, आरएसए एल्गोरिदम से जुड़ा अपडेट है. आरएसएस की तरह ही, आरएसएएसएसए-पीएसएस भी क्रिप्टोग्राफ़िक हस्ताक्षर के लिए, आरएसए के सार्वजनिक/निजी पासकोड के जोड़े का इस्तेमाल करता है. कुंजी का फ़ॉर्मैट और आरएसएस का फ़ॉर्मैट एक ही होता है. हस्ताक्षर करने वाली पार्टी, JWS/JWT को साइन करने के लिए निजी पासकोड का इस्तेमाल करती है. साथ ही, पुष्टि करने वाली पार्टी, JWS/JWT पर हस्ताक्षर की पुष्टि करने के लिए, मिलती-जुलती सार्वजनिक कुंजी का इस्तेमाल करती है. कुंजियों के लिए साइज़ की कोई शर्त नहीं है.

ईसीडीएसए एल्गोरिदम

एलिप्टिक कर्व डिजिटल सिग्नेचर एल्गोरिदम (ईसीडीएसए) एल्गोरिदम एक एलिप्टिक-कर्व क्रिप्टोग्राफ़ी एल्गोरिदम है. इसमें P-256, P-384, और P-521 कर्व शामिल हैं. ईसीडीएसए एल्गोरिदम का इस्तेमाल करते समय, एल्गोरिदम यह तय करता है कि आपको किस तरह की सार्वजनिक और निजी कुंजी तय करनी है:

एल्‍गोरि‍दम	कर्व	ज़रूरी शर्त
ES256	P-256	P-256 कर्व से जनरेट हुई कुंजी (इसे secp256r1 या prime256v1 भी कहा जाता है)
ES384	P-384	P-384 कर्व से जनरेट हुई कुंजी (इसे secp384r1 भी कहा जाता है)
ES512	P-521	P-521 कर्व से जनरेट हुई कुंजी (इसे secp521r1 भी कहा जाता है)

कुंजी को एन्क्रिप्ट करने के एल्गोरिदम

JWS/JWT की नीतियां, एन्क्रिप्ट (सुरक्षित) करने वाले सभी मुख्य एल्गोरिदम के साथ काम करती हैं. ये एल्गोरिदम, OpenSSL पर काम करते हैं.

JWS/JWT की पुष्टि करने के लिए, JSON वेब कुंजी सेट (JWKS) का इस्तेमाल करना

साइन किए गए JWS/JWT की पुष्टि करने के दौरान, आपको वह सार्वजनिक कुंजी देनी होगी जो टोकन को साइन करने के लिए इस्तेमाल की गई निजी कुंजी से जुड़ी हो. JWS/JWT की पुष्टि करने की नीतियों के लिए, आपके पास सार्वजनिक पासकोड उपलब्ध कराने के दो विकल्प हैं:

• सार्वजनिक पासकोड की असल वैल्यू का इस्तेमाल करें (आम तौर पर, फ़्लो वैरिएबल में दिया जाता है) या
• JWKS में रैप की हुई सार्वजनिक कुंजी का इस्तेमाल करें.

JWKS के बारे में जानकारी

JWKS एक JSON स्ट्रक्चर है, जो JSON वेब कुंजियों (JWK) का सेट दिखाता है. JWK एक JSON डेटा स्ट्रक्चर है, जो क्रिप्टोग्राफ़िक पासकोड के बारे में बताता है. JWK और JWKS की जानकारी RFC7517 में दी गई है. JKWS के उदाहरण अपेंडिक्स A. JSON वेब कुंजी के सेट के उदाहरण

जेडब्ल्यूकेएस स्ट्रक्चर

RFC7517 में, हर तरह की कुंजी के लिए, JWKS मुख्य एलिमेंट के बारे में बताया गया है. जैसे, "आरएसए" या "ईसी". उदाहरण के लिए, कुंजी टाइप के आधार पर, इन पैरामीटर में ये शामिल हो सकते हैं:

• kty - कुंजी का टाइप, जैसे कि "RSA" या "EC".
• kid (कुंजी का आईडी) - यह कोई भी आर्बिट्रेरी वैल्यू हो सकती है (किसी कुंजी सेट में डुप्लीकेट वैल्यू नहीं होनी चाहिए). अगर इनबाउंड JWT में कोई ऐसी कुंजी आईडी मौजूद है जो JWKS के सेट में मौजूद है, तो नीति सही सार्वजनिक कुंजी का इस्तेमाल करके, JWS/JWT हस्ताक्षर की पुष्टि करेगी.

वैकल्पिक एलिमेंट और उनकी वैल्यू के उदाहरण यहां दिए गए हैं:

• alg - मुख्य एल्गोरिदम. यह JWS/JWT में मौजूद साइनिंग एल्गोरिदम से मेल खाना चाहिए.
• use - अगर मौजूद हो, तो sig होना चाहिए.

नीचे दिए गए JWKS में ज़रूरी एलिमेंट और वैल्यू शामिल हैं और ये Edge पर मान्य होंगे (https://www.googleapis.com/oauth2/v3/certs से):

{  
   "keys":[  
      {  
         "kty":"RSA",
         "alg":"RS256",
         "use":"sig",
         "kid":"ca04df587b5a7cead80abee9ea8dcf7586a78e01",
         "n":"iXn-WmrwLLBa-QDiToBozpu4Y4ThKdwORWFXQa9I75pKOvPUjUjE2Bk05TUSt7-V7KDjCq0_Nkd-X9rMRV5LKgCa0_F8YgI30QS3bUm9orFryrdOc65PUIVFVxIwMZuGDY1hj6HEJVWIr0CZdcgNIll06BasclckkUK4O-Eh7MaQrqb646ghFlG3zlgk9b2duHbDOq3s39ICPinRQWC6NqTYfqg7E8GN_NLY9srUCc_MswuUfMJ2cKT6edrhLuIwIj_74YGkpOwilr2VswKsvJ7dcoiJxheKYvKDKtZFkbKrWETTJSGX2Xeh0DFB0lqbKLVvqkM2lFU2Qx1OgtTnrw",
         "e":"AQAB"
      },
      {
          "kty":"EC",
          "alg":"ES256",
          "use":"enc",
          "kid":"k05TUSt7-V7KDjCq0_N"
          "crv":"P-256",
          "x":"Xej56MungXuFZwmk_xccvsMpCtXmqhvEEMCmHyAmKF0",
          "y":"Bozpu4Y4ThKdwORWFXQa9I75pKOvPUjUjE2Bk05TUSt",
      }
   ]
}

JWKS का इस्तेमाल करने के लिए प्रॉक्सी डिज़ाइन करना

जब जारी करने वाले से JWS/JWT लिया जाता है, तो अक्सर जारी करने वाला बैंक, JWS/JWT हेडर में एक Key आईडी (या बच्चा) डालता है. इस कुंजी से, JWS/JWT पाने वाले को यह पता चलता है कि साइन किए हुए JWS/JWT पर हस्ताक्षर की पुष्टि करने के लिए ज़रूरी सार्वजनिक या सीक्रेट कुंजी को कैसे ढूंढा जाए.

उदाहरण के लिए, मान लीजिए कि कोई जारी करने वाला, निजी कुंजी से JWT पर हस्ताक्षर करता है. "कुंजी आईडी", मेल खाने वाली सार्वजनिक कुंजी की पहचान करता है, ताकि JWT की पुष्टि की जा सके. सार्वजनिक कुंजियों की सूची, आम तौर पर किसी लोकप्रिय एंडपॉइंट पर उपलब्ध होती है. उदाहरण के लिए: https://www.googleapis.com/oauth2/v3/certs.

यह बेसिक क्रम है जिसे Edge (या JWKS के साथ काम करने वाला कोई भी प्लैटफ़ॉर्म) को JWKS वाले JWS/JWT के साथ काम करने की ज़रूरत होगी:

1. कुंजी आईडी (किड) ढूंढने के लिए, JWS/JWT हेडर की जांच करें.
2. साइनिंग एल्गोरिदम (alg), जैसे कि RS256 को खोजने के लिए, JWS/JWT हेडर की जांच करें.
3. दिए गए किसी जारी करने वाले के लिए जाने-माने एंडपॉइंट के JWKS से कुंजियों और आईडी की सूची पाएं.
4. JWS/JWT हेडर में बताए गए कुंजी आईडी वाली और अगर JWKS कुंजी एल्गोरिदम की जानकारी देती है, तो मेल खाने वाले एल्गोरिदम की मदद से, कुंजियों की सूची से सार्वजनिक कुंजी निकालें.
5. JWS/JWT पर हस्ताक्षर की पुष्टि करने के लिए, उस सार्वजनिक कुंजी का इस्तेमाल करें.

Edge API के प्रॉक्सी डेवलपर के तौर पर, आपको JWS/JWT की पुष्टि करने के लिए ये काम करने होंगे:

1. किसी जारी करने वाले के जाने-माने एंडपॉइंट से कुंजियों और आईडी की सूची पाएं. इस चरण के लिए, सेवा की कॉलआउट नीति का इस्तेमाल किया जा सकता है.
2. पुष्टि करें JWS/JWT नीति में, <Source> एलिमेंट में JWS/JWT की और <PublicKey/JWKS> एलिमेंट में JWKS पेलोड की जगह की जानकारी दें. उदाहरण के लिए, VerifyJWT नीति के लिए:

   <VerifyJWT name="JWT-Verify-RS256">
       <Algorithm>RS256</Algorithm>
       <Source>json.jwt</Source>
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
       <PublicKey>
           <JWKS ref="public.jwks"/>
       </PublicKey>
       <Subject>apigee-seattle-hatrack-montage</Subject>
       <Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
       <Audience>urn://c60511c0-12a2-473c-80fd-42528eb65a6a</Audience>
       <AdditionalClaims>
           <Claim name="show">And now for something completely different.</Claim>    
       </AdditionalClaims>
   </VerifyJWT>
   

पुष्टि के लिए JWT की नीति के तहत बाकी सब कुछ किया जा सकता है:

• अगर JWT में दावा किए गए कुंजी आईडी (किड) से मेल खाने वाली कुंजी आईडी, JWKS में नहीं मिलती, तो पुष्टि करें JWT नीति की मदद से गड़बड़ी दिखाई जाती है और JWT की पुष्टि नहीं की जाती.
• अगर इनबाउंड JWT के हेडर में कोई कुंजी आईडी (किड) नहीं है, तो keyid-to-verification-key को मैप नहीं किया जा सकता.

प्रॉक्सी डिज़ाइनर के तौर पर, यह आपकी ज़िम्मेदारी है कि इस्तेमाल की जाने वाली कुंजी तय की जाए. कुछ मामलों में, यह हार्ड कोड की गई कुंजी हो सकती है.