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

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

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

परिचय

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

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

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

Verify JWS/JWT नीति का इस्तेमाल करने पर, अमान्य JWS/JWT को अस्वीकार कर दिया जाएगा. साथ ही, गड़बड़ी की स्थिति पैदा हो जाएगी . इसी तरह, Decode JWS/JWT नीति का इस्तेमाल करने पर, गलत तरीके से फ़ॉर्मैट किए गए JWS/JWT की वजह से गड़बड़ी की स्थिति पैदा हो जाएगी.

वीडियो

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

JWT के स्ट्रक्चर के बारे में ज़्यादा जानने के लिए, यह शॉर्ट वीडियो देखें.

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

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

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

JWS/JWT के हिस्से

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

header.payload.signature
  • Generate JWS/JWT नीति, इन तीनों हिस्सों को बनाती है.
  • Verify JWS/JWT नीति, इन तीनों हिस्सों की जांच करती है.
  • Decode JWS/JWT नीति, सिर्फ़ हेडर और पेलोड की जांच करती है.

JWS, डिटैच फ़ॉर्मैट के साथ भी काम करता है. इस फ़ॉर्मैट में, JWS से पेलोड को हटा दिया जाता है:

header..signature

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

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

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

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

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

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

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

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

JWS और JWT का इस्तेमाल करते समय, टेंप्लेट इंजेक्शन को रोकना

अनधिकृत तरीके से डेटा की जानकारी होने से रोकने के लिए, GenerateJWT या GenerateJWS नीतियों का इस्तेमाल करते समय, इन दिशा-निर्देशों का पालन करें:

  • उपयोगकर्ता के इनपुट का सीधे तौर पर रेफ़रंस देने से बचें: टेंप्लेटिंग की सुविधा वाले ref एट्रिब्यूट में, कभी भी भरोसेमंद न माने जाने वाले इनपुट (जैसे, request.queryparam.* या request.header.*) का सीधे तौर पर इस्तेमाल न करें.
  • इनपुट को सैनिटाइज़ करें: अगर आपको JWT/JWS दावे में बाहरी डेटा का इस्तेमाल करना है, तो पहले एक AssignMessage नीति का इस्तेमाल करके, रेफ़रंस देने से पहले इनपुट से कर्ली ब्रेसिज़ ({ }) या टेंप्लेट के अन्य वर्ण हटाएं.
  • स्ट्रिंग के लिए, साफ़ तौर पर दावे का इस्तेमाल करें: सामान्य स्ट्रिंग दावों के लिए, type="map" का इस्तेमाल न करें. डिफ़ॉल्ट type="string" का इस्तेमाल करने से, रेफ़रंस दी गई वैल्यू की टेंप्लेटिंग नहीं होती.
  • पुष्टि करने और जनरेट करने की नीतियों के बीच, व्यवहार में अंतर को ध्यान में रखें: JWS और JWT जनरेट करने की नीतियां, टेंप्लेटिंग के मामले में, पुष्टि करने की नीतियों से अलग तरीके से काम करती हैं.

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

JWS/JWT की पुष्टि करने और JWS/JWT जनरेट करने की नीतियां, RSA, RSASSA-PSS, ECDSA, और HMAC एल्गोरिदम के साथ काम करती हैं. इनमें SHA2 चेकसम का इस्तेमाल किया जाता है. इसकी बिट स्ट्रेंथ 256, 384 या 512 होती है. JWS/JWT को साइन करने के लिए, जिस एल्गोरिदम का इस्तेमाल किया गया था उसके बावजूद, JWS/JWT को डिकोड करने की नीति काम करती है.

HMAC एल्गोरिदम

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

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

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

RSA एल्गोरिदम

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

RSASSA-PSS एल्गोरिदम

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

ECDSA एल्गोरिदम

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

एल्गोरिदम कर्व कुंजी की ज़रूरत
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 Web Key Set (JWKS) का इस्तेमाल करना

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

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

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

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

JWKS का स्ट्रक्चर

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

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

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

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

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

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

  1. किसी दिए गए जारीकर्ता के लिए, जाने-माने एंडपॉइंट से, कुंजियों और आईडी की सूची पाना. इस चरण के लिए, Service Callout नीति का इस्तेमाल किया जा सकता है.
  2. Verify 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>

Verify JWT नीति, बाकी सभी काम करती है:

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

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