आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
इस पेज पर जाएं
Apigee X दस्तावेज़. जानकारी
यह विषय JWT (JSON वेब टोकन) के बारे में सामान्य जानकारी देता है और JWS (JSON वेब हस्ताक्षर) और Apigee JWS/JWT नीतियां, जो Apigee प्रॉक्सी डेवलपर को पसंद हो सकती हैं.
परिचय
JWS और JWT, दोनों का इस्तेमाल आम तौर पर, एक-दूसरे से जुड़े दावों या दावों को शेयर करने के लिए किया जाता है का इस्तेमाल करें. JWS/JWT नीतियां, Edge API प्रॉक्सी को ये काम करने की सुविधा देती हैं:
- साइन किया गया JWT जनरेट करें या JWS.
- साइन किए गए JWT की पुष्टि करना या JWS और JWS/JWT में होने वाले दावे.
- साइन किए गए JWT को डीकोड करें या हस्ताक्षर की पुष्टि किए बिना JWS.
बाद के दो मामलों में, यह नीति ऐसे वैरिएबल भी सेट करती है जो अतिरिक्त नीतियों की अनुमति देते हैं या पुष्टि किए गए दावों की जांच करने और उनके आधार पर फ़ैसले लेने के लिए, बैकएंड सेवाओं को खुद ही मैनेज किया जाता है दावे.
पुष्टि करें कि JWS/JWT नीति का इस्तेमाल करते समय, अमान्य JWS/JWT अस्वीकार कर दिया जाएगा और इसकी वजह से गड़बड़ी होगी स्थिति. इसी तरह, डिकोड की गई JWS/JWT नीति का इस्तेमाल करते समय, गलत JWS/JWT नीति के नतीजे में गड़बड़ी का मैसेज दिखेगा स्थिति.
वीडियो
JWT के बारे में जल्दी से जानने के लिए, यह छोटा सा वीडियो देखें. हालांकि, यह वीडियो इनमें से कई सिद्धांत JWS के लिए एक जैसे हैं.
JWT के बारे में ज़्यादा जानकारी वाला छोटा वीडियो.
उपयोग के उदाहरण
JWS/JWT नीतियों का इस्तेमाल इन कामों के लिए किया जा सकता है:
- Edge प्रॉक्सी के प्रॉक्सी या टारगेट एंडपॉइंट साइड में, नया JWS/JWT जनरेट करें. इसके लिए उदाहरण के लिए, एक ऐसा प्रॉक्सी अनुरोध फ़्लो बनाया जा सकता है जो JWS/JWT जनरेट करता है और उसे क्लाइंट को वापस भेजता है. इसके अलावा, आपके पास कोई प्रॉक्सी डिज़ाइन करने का भी विकल्प है, ताकि वह टारगेट रिक्वेस्ट फ़्लो पर JWS/JWT जनरेट करे. इसे टारगेट पर भेजे गए अनुरोध में अटैच कर देता है. इसके बाद, उन दावों को आगे की सुरक्षा प्रोसेस लागू करने के लिए बैकएंड सेवाएं.
- टारगेट से, इनबाउंड क्लाइंट अनुरोधों से मिले JWS/JWT के दावों की पुष्टि करें और उन्हें निकालें सेवा से जुड़े जवाब, सेवा कॉल आउट नीति के जवाबों या दूसरे सोर्स से. एज JWS/JWT पर हस्ताक्षर की पुष्टि की जा सकती है, चाहे JWS/JWT किसी तीसरे पक्ष ने जनरेट किया हो या Edge से बनाया गया हो आरएसए या एचएमएसी एल्गोरिदम का इस्तेमाल करके.
- किसी JWS/JWT डिकोड करें. डिकोड करना तब सबसे ज़्यादा फ़ायदेमंद होता है, जब इनका इस्तेमाल Verify JWS/JWT नीति के साथ कॉन्सर्ट में किया जाता है. ऐसा तब होता है, जब पुष्टि करने से पहले, JWS/JWT में किसी दावे (JWT) या हेडर (JWS/JWT) की वैल्यू का पता चल जाना चाहिए JWS/JWT.
JWS/JWT के हिस्से
हस्ताक्षर किया गया JWS/JWT, जानकारी को तीन हिस्सों में एन्कोड करता है. इन हिस्सों को पीरियड से अलग किया जाता है: हेडर, पेलोड, और हस्ताक्षर:
header.payload.signature
- जनरेट JWS/JWT नीति, तीनों हिस्से बनाती है.
- Verify JWS/JWT नीति, तीनों हिस्सों की जांच करती है.
- Decode JWS/JWT नीति सिर्फ़ हेडर और पेलोड की जांच करती है.
JWS, ऐसे डिटैच किए गए फ़ॉर्मैट के साथ भी काम करता है जो JWS से पेलोड को हटा देता है:
header..signature
डिटैच किए गए JWS की मदद से, पेलोड को JWS से अलग भेजा जाता है. आप
रॉ और कोड में बदले गए JWS पेलोड की जानकारी देने के लिए, 'JWS की पुष्टि करें' नीति का <DetachedContent>
एलिमेंट.
इसके बाद, JWS की पुष्टि करने वाली नीति के तहत, JWS में मौजूद हेडर और हस्ताक्षर और पेलोड का इस्तेमाल करके, JWS की पुष्टि की जाती है
<DetachedContent>
एलिमेंट के ज़रिए तय किया गया.
टोकन के बारे में ज़्यादा जानने और उन्हें कोड में बदलने और हस्ताक्षर करने के तरीके के बारे में जानने के लिए, यहां देखें:
- JWT: आईईटीएफ़ आरएफ़सी7519
- JWS: आईईटीएफ़ आरएफ़सी7515
JWS और JWT के बीच अंतर
कनेक्ट किए गए ऐप्लिकेशन के बीच दावे या दावे शेयर करने के लिए, JWT या JWS का इस्तेमाल किया जा सकता है. इन दोनों के बीच बड़ा अंतर पेलोड को दिखाता है:
- JWT
- पेलोड हमेशा एक JSON ऑब्जेक्ट होता है
- पेलोड हमेशा JWT से जुड़ा रहता है
- टोकन का
typ
हेडर हमेशाJWT
पर सेट रहता है
- JWS
- पेलोड को किसी भी फ़ॉर्मैट में दिखाया जा सकता है. जैसे, JSON ऑब्जेक्ट, बाइट स्ट्रीम, ऑक्टेट स्ट्रीम वगैरह
- पेलोड को JWS के साथ अटैच करने की ज़रूरत नहीं है
JWT फ़ॉर्मैट, पेलोड को दिखाने के लिए हमेशा JSON ऑब्जेक्ट का इस्तेमाल करता है. इसलिए, Edge generate JWT और पुष्टि करें कि JWT की नीतियां, रजिस्टर किए गए दावों के सामान्य नामों को मैनेज करने के लिए काम करती हैं. जैसे, ऑडिट, iss, sub वगैरह शामिल करें. इसका मतलब है कि आप प्रॉपर्टी के एलिमेंट का इस्तेमाल कर सकते हैं पेलोड में इन दावों को सेट करने के लिए, JWT नीति जनरेट करें और अपनी वैल्यू की पुष्टि करने के लिए, Verify JWT नीति के एलिमेंट सेट करें. रजिस्टर किए गए दावों के नाम देखें सेक्शन देखें.
रजिस्टर किए गए कुछ दावों के नामों के साथ-साथ, सीधे JWT जनरेट करने की नीति JWT में आर्बिट्रेरी नामों के साथ दावे जोड़ने का समर्थन करता है. हर दावा एक सामान्य नाम/वैल्यू पेयर होता है, जहां वैल्यू का टाइप नंबर, बूलियन, स्ट्रिंग, मैप या अरे हो सकता है.
JWS, पेलोड के लिए किसी भी डेटा रिप्रज़ेंटेशन का इस्तेमाल कर सकता है, इसलिए पेलोड में दावे नहीं जोड़े जा सकते. JWS जनरेट करने की नीति के तहत, JWS के हेडर में मनचाहे नामों के साथ दावे जोड़े जा सकते हैं. साथ ही, JWS की नीतियां डिटैच किए गए पेलोड के साथ काम करती हैं, जिसमें JWS पेलोड को हटा देता है. डिटैच किए गए पेलोड से आपको JWS और पेलोड अलग-अलग भेजने की सुविधा मिलती है. ऐसा करने के लिए, कई सुरक्षा मानकों की ज़रूरत होती है.
हस्ताक्षर के एल्गोरिदम के बारे में जानकारी
JWS/JWT की पुष्टि और JWS/JWT जनरेशन की नीतियां, SHA2 का इस्तेमाल करके आरएसए, आरएसएएसएसए-पीएसएस, ईसीडीएसए, और एचएमएसी एल्गोरिदम के साथ काम करती हैं बिट ताकत 256, 384 या 512 के चेकसम. JWS/JWT डिकोड नीति एल्गोरिदम का इस्तेमाल किया गया था. इसका इस्तेमाल JWS/JWT पर हस्ताक्षर करने के लिए किया गया था.
एचएमएसी एल्गोरिदम
HMAC एल्गोरिदम एक शेयर किए गए सीक्रेट पर निर्भर करता है, जिसे सीक्रेट कुंजी कहा जाता है. इसकी मदद से, हस्ताक्षर (इसे JWS/JWT पर हस्ताक्षर करना भी कहा जाता है) और हस्ताक्षर की पुष्टि करने के लिए किया जाता है.
सीक्रेट कुंजी की कम से कम लंबाई एल्गोरिदम की बिट क्षमता पर निर्भर करती है:
- HS256: कुंजी की कम से कम लंबाई 32 बाइट
- HS386: कुंजी की कम से कम लंबाई 48 बाइट
- HS512: कुंजी की कम से कम लंबाई 64 बाइट
आरएसए एल्गोरिदम
आरएसए एल्गोरिदम, क्रिप्टोग्राफ़िक हस्ताक्षर के लिए सार्वजनिक/निजी पासकोड का इस्तेमाल करता है. आरएसए के साथ हस्ताक्षर हैं, तो साइनिंग पक्ष 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 वेब पासकोड (JWKs) का सेट दिखाता है. JWK, एक JSON डेटा होता है एक ऐसा स्ट्रक्चर है जो क्रिप्टोग्राफ़िक कुंजी के बारे में बताता है. JWK और JWKS के बारे में RFC7517 में बताया गया है. यहां JKWS के उदाहरण देखें अपेंडिक्स A. JSON वेब कुंजी के सेट का उदाहरण
जेडब्ल्यूकेएस स्ट्रक्चर
RFC7517, जेडब्ल्यूकेएस के मुख्य एलिमेंट के बारे में बताता है जैसे कि "RSA" या "EC" का इस्तेमाल करें. उदाहरण के लिए, कुंजी के टाइप के आधार पर, इन पैरामीटर में ये शामिल हो सकते हैं:
- kty - कुंजी का टाइप, जैसे कि "RSA" या "EC" का इस्तेमाल करें.
- kid (कुंजी आईडी) - कोई भी आर्बिट्रेरी वैल्यू हो सकती है (कुंजी में कोई डुप्लीकेट नहीं होनी चाहिए) सेट). अगर इनबाउंड JWT में एक ऐसा पासकोड आईडी है जो JWKS के सेट में मौजूद है, तो JWS/JWT हस्ताक्षर की पुष्टि करने के लिए सही सार्वजनिक कुंजी का इस्तेमाल किया जाएगा.
यहां वैकल्पिक एलिमेंट और उनकी वैल्यू के उदाहरण दिए गए हैं:
- alg - मुख्य एल्गोरिदम. यह JWS/JWT में मौजूद साइनिंग एल्गोरिदम से मेल खाना चाहिए.
- use - अगर यह मौजूद है, तो हस्ताक्षर करें.
यहां दिए गए 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 में एक कुंजी आईडी (या किड) डालता है हेडर. कुंजी, JWS/JWT के पाने वाले को यह बताती है कि खोज के लिए ज़रूरी सार्वजनिक या सीक्रेट कुंजी कैसे ढूंढी जाए हस्ताक्षर किए गए JWS/JWT पर हस्ताक्षर की पुष्टि करेगा.
उदाहरण के लिए, मान लें कि जारी करने वाला, निजी पासकोड से JWT पर हस्ताक्षर करता है. "कुंजी का आईडी" पहचान करती है ताकि JWT की पुष्टि करने में मदद मिल सके. सार्वजनिक पासकोड की सूची आम तौर पर, यहां दी गई होती है: कुछ मशहूर एंडपॉइंट, उदाहरण के लिए: https://www.googleapis.com/oauth2/v3/certs.
यह वह बेसिक क्रम है जिसे Edge (या JWKS के साथ काम करने वाला कोई भी प्लैटफ़ॉर्म) पूरा करना होता है का इस्तेमाल ऐसे JWS/JWT के साथ किया जा सकता है जिनमें JWKS हो:
- कुंजी आईडी (बच्चा) ढूंढने के लिए, JWS/JWT हेडर की जांच करें.
- RS256 जैसे साइनिंग एल्गोरिदम (alg) को ढूंढने के लिए, JWS/JWT हेडर की जांच करें.
- जारी करने वाले के जाने-माने एंडपॉइंट के JWKS से, कुंजियों और आईडी की सूची फिर से पाएं.
- JWS/JWT हेडर में बताए गए पासकोड आईडी की मदद से, कुंजियों की सूची से सार्वजनिक पासकोड निकालें और मेल खाने वाले एल्गोरिदम के साथ, अगर JWKS कुंजी एल्गोरिदम की जानकारी देती है.
- JWS/JWT पर हस्ताक्षर की पुष्टि करने के लिए, उस सार्वजनिक पासकोड का इस्तेमाल करें.
Edge API के प्रॉक्सी डेवलपर के तौर पर, आपको JWS/JWT की पुष्टि करने के लिए, ये काम करने होंगे:
- जाने-पहचाने एंडपॉइंट से, दिए गए जारी करने वाले के लिए कुंजियों और आईडी की सूची पाएं. आप इस चरण के लिए, सेवा कॉलआउट की नीति का इस्तेमाल करें.
- पुष्टि करें 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 नीति इनके अलावा, ये सभी काम करती है:
- अगर JWT में दावा किए गए, की आईडी (बच्चा) से मेल खाने वाली कुंजी आईडी वाली कुंजी नहीं मिलती है JWKS की पुष्टि होती है, तो पुष्टि करने के लिए JWT नीति गड़बड़ी होती है और JWT की पुष्टि नहीं करती.
- यदि इनबाउंड JWT हेडर में कोई कुंजी आईडी (बच्चा) नहीं देता है, तो keyid-to-verification-key संभव नहीं है.
प्रॉक्सी डिज़ाइनर के तौर पर, इस्तेमाल करने के लिए पासकोड तय करने की ज़िम्मेदारी आपकी है; कुछ मामलों में इसका हो सकता है कि कोई तय और हार्ड कोड की गई कुंजी न हो.