JWT की नीति की पुष्टि करें

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

यह क्या है

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

इस नीति को लागू करने पर, Edge किसी JWT के हस्ताक्षर की पुष्टि करता है. साथ ही, यह पुष्टि करता है कि JWT खत्म होने की तारीख के हिसाब से मान्य है और मौजूद न होने पर उस समय से पहले नहीं. इस नीति का इस्तेमाल करके, JWT पर किए गए खास दावों की वैल्यू की भी पुष्टि की जा सकती है. जैसे, विषय, जारी करने वाला, ऑडियंस या दूसरे दावों की वैल्यू.

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

JWT के हिस्सों के बारे में जानने और उन्हें एन्क्रिप्ट (सुरक्षित) और साइन करने के तरीके के बारे में जानने के लिए, RFC7519 पर जाएं.

वीडियो

JWT पर हस्ताक्षर की पुष्टि करने का तरीका जानने के लिए यह छोटा वीडियो देखें.

सैंपल

• HS256 एल्गोरिदम की मदद से साइन किए गए JWT की पुष्टि करना
• RS256 एल्गोरिदम की मदद से साइन किए गए JWT की पुष्टि करना

HS256 एल्गोरिदम की मदद से साइन किए गए JWT की पुष्टि करें

यह नीति, ऐसे JWT की पुष्टि करती है जिसे HS256 एन्क्रिप्शन एल्गोरिदम, एचएमएसी के साथ साइन किया गया है. इसके लिए, SHA-256 चेकसम का इस्तेमाल किया जाता है. JWT को प्रॉक्सी अनुरोध में पास किया जाता है. ऐसा करने के लिए, jwt नाम के फ़ॉर्म पैरामीटर का इस्तेमाल किया जाता है. यह कुंजी, private.secretkey नाम के वैरिएबल में होती है. पूरा उदाहरण देखने के लिए, ऊपर दिया गया वीडियो देखें. इसमें नीति के लिए अनुरोध करने का तरीका भी बताया गया है.

नीति के कॉन्फ़िगरेशन में वह जानकारी शामिल है जो Edge को JWT को डिकोड और आकलन करने के लिए चाहिए. जैसे, JWT कहां मिलेगा (सोर्स एलिमेंट में बताए गए फ़्लो वैरिएबल में), ज़रूरी साइनिंग एल्गोरिदम, सीक्रेट कुंजी को कहां खोजना है (Edge फ़्लो वैरिएबल में सेव किया गया, जो एज केवीएम से वापस लाया जा सकता हो). उदाहरण के लिए, ज़रूरी दावों और उनकी वैल्यू का सेट.

<VerifyJWT name="JWT-Verify-HS256">
    <DisplayName>JWT Verify HS256</DisplayName>
    <Algorithm>HS256</Algorithm>
    <Source>request.formparam.jwt</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <SecretKey encoding="base64">
        <Value ref="private.secretkey"/>
    </SecretKey>
    <Subject>monty-pythons-flying-circus</Subject>
    <Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
    <Audience>fans</Audience>
    <AdditionalClaims>
        <Claim name="show">And now for something completely different.</Claim>
    </AdditionalClaims>
</VerifyJWT>

नीति अपने आउटपुट को कॉन्टेक्स्ट वैरिएबल पर लिखती है, ताकि एपीआई प्रॉक्सी में बाद की नीतियां या शर्तें उन वैल्यू की जांच कर सकें. इस नीति के ज़रिए सेट किए गए वैरिएबल की सूची के लिए, फ़्लो वैरिएबल देखें.

RS256 एल्गोरिदम की मदद से साइन किए गए JWT की पुष्टि करें

यह नीति, उस JWT की पुष्टि करती है जिसे RS256 एल्गोरिदम की मदद से साइन किया गया था. पुष्टि करने के लिए, आपको सार्वजनिक कुंजी देनी होगी. JWT को प्रॉक्सी अनुरोध में पास किया जा सकता है. इसके लिए, jwt नाम के फ़ॉर्म पैरामीटर का इस्तेमाल किया जाता है. सार्वजनिक कुंजी, public.publickey नाम के वैरिएबल में होती है. पूरा उदाहरण देखने के लिए, ऊपर दिया गया वीडियो देखें. इसमें नीति के लिए अनुरोध करने का तरीका भी बताया गया है.

इस सैंपल नीति में, हर एलिमेंट की ज़रूरी शर्तों और विकल्पों के बारे में जानने के लिए, एलिमेंट रेफ़रंस देखें.

<VerifyJWT name="JWT-Verify-RS256">
    <Algorithm>RS256</Algorithm>
    <Source>request.formparam.jwt</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <PublicKey>
        <Value ref="public.publickey"/>
    </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 ...

{
  "typ" : "JWT", 
  "alg" : "RS256"
}

और यह पेलोड ...

{ 
  "sub" : "apigee-seattle-hatrack-montage",
  "iss" : "urn://apigee-edge-JWT-policy-test",
  "aud" : "urn://c60511c0-12a2-473c-80fd-42528eb65a6a",
  "show": "And now for something completely different."
}

... अगर दिए गए सार्वजनिक पासकोड से हस्ताक्षर की पुष्टि की जा सकती है, तो इसे मान्य माना जाएगा.

इसी हेडर वाला JWT, लेकिन इस पेलोड के साथ ...

{ 
  "sub" : "monty-pythons-flying-circus",
  "iss" : "urn://apigee-edge-JWT-policy-test",
  "aud" : "urn://c60511c0-12a2-473c-80fd-42528eb65a6a",
  "show": "And now for something completely different."
}

... को अमान्य माना जाएगा, भले ही हस्ताक्षर की पुष्टि की जा सकती हो. ऐसा इसलिए है, क्योंकि JWT में शामिल "सब" का दावा, "Subject" एलिमेंट की ज़रूरी वैल्यू से मेल नहीं खाता, जैसा कि नीति के कॉन्फ़िगरेशन में बताया गया है.

नीति अपने आउटपुट को कॉन्टेक्स्ट वैरिएबल पर लिखती है, ताकि एपीआई प्रॉक्सी में बाद की नीतियां या शर्तें उन वैल्यू की जांच कर सकें. इस नीति के ज़रिए सेट किए गए वैरिएबल की सूची के लिए, फ़्लो वैरिएबल देखें.

मुख्य एलिमेंट सेट करना

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

<SecretKey encoding="base16|hex|base64|base64url">
  <Value ref="private.secretkey"/>
</SecretKey>

<PublicKey>
  <Value ref="rsa_public_key_or_value"/>
</PublicKey>

<PublicKey>
  <Certificate ref="signed_cert_val_ref"/>
</PublicKey>

<PublicKey>
  <JWKS ref="jwks_val_or_ref"/>
</PublicKey>

एलिमेंट का रेफ़रंस

नीति का रेफ़रंस, पुष्टि वाले JWT नीति के एलिमेंट और एट्रिब्यूट के बारे में बताता है.

ध्यान दें: आपके एन्क्रिप्शन के लिए इस्तेमाल किए जाने वाले एल्गोरिदम के आधार पर, कॉन्फ़िगरेशन कुछ अलग-अलग होगा. इस्तेमाल के कुछ खास उदाहरणों के कॉन्फ़िगरेशन की जानकारी देने वाले उदाहरणों के लिए, सैंपल देखें.

टॉप-लेवल एलिमेंट पर लागू होने वाले एट्रिब्यूट

<VerifyJWT name="JWT" continueOnError="false" enabled="true" async="false">

ये एट्रिब्यूट, नीति के सभी पैरंट एलिमेंट के लिए एक जैसे हैं.

<DisplayName>

<DisplayName>Policy Display Name</DisplayName>

मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) के प्रॉक्सी एडिटर में नीति को, आम भाषा के अलग नाम से लेबल करने के लिए, नाम एट्रिब्यूट के साथ-साथ इसका इस्तेमाल करें.

<एल्गोरिदम>

<Algorithm>HS256</Algorithm>

यह नीति, टोकन पर हस्ताक्षर करने के लिए एन्क्रिप्ट (सुरक्षित) करने का एल्गोरिदम तय करती है. RS*/PS*/ES* एल्गोरिदम, सार्वजनिक/सीक्रेट कुंजी के जोड़े का इस्तेमाल करते हैं, जबकि एचएस* एल्गोरिदम, शेयर किए गए सीक्रेट कोड का इस्तेमाल करते हैं. सिग्नेचर एन्क्रिप्ट (सुरक्षित) करने के एल्गोरिदम के बारे में जानकारी भी देखें.

एक से ज़्यादा वैल्यू दी जा सकती हैं, जिन्हें कॉमा लगाकर अलग किया जा सकता है. उदाहरण के लिए, "HS256, HS512" या "RS256, PS256". हालांकि, HS* एल्गोरिदम को किसी दूसरे या ES* एल्गोरिदम के साथ नहीं जोड़ा जा सकता, क्योंकि इसके लिए खास तरह की कुंजी की ज़रूरत होती है. RS* और PS* एल्गोरिदम, दोनों को एक साथ शामिल किए जा सकते हैं.

<ऑडियंस>

<Audience>audience-here</Audience>

or:

<Audience ref='variable-name-here'/>

इस नीति से यह पुष्टि की जाती है कि JWT में ऑडियंस का दावा, कॉन्फ़िगरेशन में बताई गई वैल्यू से मेल खाता है या नहीं. अगर कोई मैच नहीं होता है, तो नीति गड़बड़ी दिखाती है. इस दावे से उन लोगों की पहचान हो जाती है जिनके लिए JWT बनाया गया. यह उन रजिस्टर किए गए दावों में से एक है जिनके बारे में RFC7519 में बताया गया है.

<अतिरिक्त दावे/दावा>

<AdditionalClaims>
    <Claim name='claim1'>explicit-value-of-claim-here</Claim>
    <Claim name='claim2' ref='variable-name-here'/>
    <Claim name='claim3' ref='variable-name-here' type='boolean'/>
 </AdditionalClaims>

or:

<AdditionalClaims ref='claim_payload'/>

यह पुष्टि करता है कि JWT पेलोड में कुछ और दावे शामिल हैं या नहीं और दावा किए गए दावे की वैल्यू मेल खाती हैं या नहीं.

एक अन्य दावे में ऐसे नाम का इस्तेमाल किया जाता है जो JWT के रजिस्टर किए गए स्टैंडर्ड दावों में से एक नहीं है. अतिरिक्त दावे की वैल्यू कोई स्ट्रिंग, संख्या, बूलियन, मैप या ऐरे हो सकती है. मैप बस नाम/वैल्यू पेयर का सेट होता है. इनमें से किसी भी तरह के दावे की वैल्यू को, साफ़ तौर पर नीति के कॉन्फ़िगरेशन में बताया जा सकता है. इसके अलावा, किसी फ़्लो वैरिएबल के रेफ़रंस से भी ऐसा किया जा सकता है.

<Claim> एलिमेंट में ये एट्रिब्यूट शामिल होते हैं:

• name - (ज़रूरी है) दावे का नाम.
• ref - (ज़रूरी नहीं) फ़्लो वैरिएबल का नाम. मौजूद होने पर, नीति इस वैरिएबल की वैल्यू का इस्तेमाल दावे के तौर पर करेगी. अगर ref एट्रिब्यूट और साफ़ तौर पर दावा की गई वैल्यू, दोनों के बारे में बताया गया है, तो साफ़ तौर पर दिखने वाली वैल्यू को डिफ़ॉल्ट माना जाता है. इसका इस्तेमाल तब किया जाता है, जब रेफ़र किए गए फ़्लो वैरिएबल की समस्या हल न हो.
• type - (ज़रूरी नहीं) इनमें से एक: स्ट्रिंग (डिफ़ॉल्ट), संख्या, बूलियन या मैप
• array - (ज़रूरी नहीं) यह बताने के लिए कि वैल्यू, टाइप का ऐरे है या नहीं, true पर सेट करें. डिफ़ॉल्ट: false.

जब <Claim> एलिमेंट शामिल किया जाता है, तब नीति को कॉन्फ़िगर करने पर, दावे के नाम स्टैटिक रूप से सेट हो जाते हैं. इसके अलावा, दावे के नाम बताने के लिए, JSON ऑब्जेक्ट को पास किया जा सकता है. JSON ऑब्जेक्ट, वैरिएबल के तौर पर पास होता है. इसलिए, दावे के नाम रनटाइम के दौरान तय किए जाते हैं.

उदाहरण के लिए:

<AdditionalClaims ref='json_claims'/>

जहां वैरिएबल json_claims के फ़ॉर्म में JSON ऑब्जेक्ट शामिल होता है:

{
  "sub" : "person@example.com",
  "iss" : "urn://secure-issuer@example.com",
  "non-registered-claim" : {
    "This-is-a-thing" : 817,
    "https://example.com/foobar" : { "p": 42, "q": false }
  }
}

<अतिरिक्तहेडर/दावा>

<AdditionalHeaders>
    <Claim name='claim1'>explicit-value-of-claim-here</Claim>
    <Claim name='claim2' ref='variable-name-here'/>
    <Claim name='claim3' ref='variable-name-here' type='boolean'/>
    <Claim name='claim4' ref='variable-name' type='string' array='true'/>
 </AdditionalHeaders>

यह पुष्टि करता है कि JWT हेडर में एक से ज़्यादा दावे के नाम/वैल्यू के जोड़े हैं और दावा किए गए दावे की वैल्यू मेल खाती हैं.

अतिरिक्त दावे में, ऐसे नाम का इस्तेमाल किया जाता है जो JWT के रजिस्टर किए गए स्टैंडर्ड दावों में से एक नहीं है. अतिरिक्त दावे की वैल्यू, कोई स्ट्रिंग, संख्या, बूलियन, मैप या ऐरे हो सकती है. मैप बस नाम/वैल्यू पेयर का सेट होता है. इनमें से किसी भी तरह के दावे की वैल्यू को, साफ़ तौर पर नीति के कॉन्फ़िगरेशन में बताया जा सकता है. इसके अलावा, किसी फ़्लो वैरिएबल के रेफ़रंस से भी ऐसा किया जा सकता है.

<Claim> एलिमेंट में ये एट्रिब्यूट शामिल होते हैं:

• name - (ज़रूरी है) दावे का नाम.
• ref - (ज़रूरी नहीं) फ़्लो वैरिएबल का नाम. मौजूद होने पर, नीति इस वैरिएबल की वैल्यू का इस्तेमाल दावे के तौर पर करेगी. अगर ref एट्रिब्यूट और साफ़ तौर पर दावा की गई वैल्यू, दोनों के बारे में बताया गया है, तो साफ़ तौर पर दिखने वाली वैल्यू को डिफ़ॉल्ट माना जाता है. इसका इस्तेमाल तब किया जाता है, जब रेफ़र किए गए फ़्लो वैरिएबल की समस्या हल न हो.
• type - (ज़रूरी नहीं) इनमें से एक: स्ट्रिंग (डिफ़ॉल्ट), संख्या, बूलियन या मैप
• array - (ज़रूरी नहीं) यह बताने के लिए कि वैल्यू, टाइप का ऐरे है या नहीं, true पर सेट करें. डिफ़ॉल्ट: false.

<कस्टम दावे>

अहम जानकारी: फ़िलहाल, जब यूज़र इंटरफ़ेस (यूआई) से नई generateJWT नीति जोड़ी जाती है, तो Customclaims एलिमेंट शामिल किया जाता है. यह एलिमेंट काम नहीं करता है और इसे अनदेखा किया जाता है. इसके बजाय इस्तेमाल करने के लिए सही एलिमेंट <AdditionalClaims> है. सही एलिमेंट डालने के लिए, यूज़र इंटरफ़ेस को बाद में अपडेट किया जाएगा.

<आईडी>

<Id>explicit-jti-value-here</Id>
 -or-
<Id ref='variable-name-here'/>
 -or-
<Id/>

यह पुष्टि करता है कि JWT में कोई खास jti दावा है या नहीं. अगर टेक्स्ट वैल्यू और रेफ़रंस एट्रिब्यूट, दोनों खाली हैं, तो नीति एक रैंडम यूयूआईडी वाली जेटीआई जनरेट करेगी. JWT आईडी (jti) दावा, JWT का एक यूनीक आइडेंटिफ़ायर है. जेटीआई के बारे में ज़्यादा जानकारी के लिए, आरएफ़सी7519 देखें.

<अनदेखाक्रिटिकलहेडर>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

अगर JWT के क्रिट हेडर में मौजूद किसी हेडर को <KnownHeaders> एलिमेंट में शामिल नहीं किया जाता, तो नीति से गड़बड़ी का पता लगाने के लिए, नीति को 'गलत है' पर सेट करें. 'सही है' पर सेट करें, ताकि ConfirmJWT नीति की मदद से crit हेडर को अनदेखा किया जा सके.

इस एलिमेंट को 'सही' पर सेट करने की एक वजह यह है कि अगर आप टेस्टिंग एनवायरमेंट में हैं और अब तक हेडर के मौजूद न होने की स्थिति के लिए तैयार नहीं हैं.

<ignoreIssuedAt>

<IgnoreIssuedAt>true|false</IgnoreIssuedAt>

अगर आपको यह नीति चाहिए कि JWT में ऐसा iat (जारी किया गया) दावा शामिल होने पर गड़बड़ी दिखे जो आने वाले समय के बारे में बताता है, तो नीति को 'गलत' (डिफ़ॉल्ट) पर सेट करें. 'सही है' पर सेट करें, ताकि पुष्टि के दौरान नीति iat को अनदेखा कर सके.

<ignoreUnresolvedVariables>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

अगर नीति में बताए गए किसी भी वैरिएबल को ठीक नहीं किया जा सकता, तो नीति के ज़रिए गड़बड़ी का पता चलने पर, 'गलत' पर सेट करें. किसी भी रिज़ॉल्व न किए जा सकने वाले वैरिएबल को खाली स्ट्रिंग (शून्य) के तौर पर ट्रीट करने के लिए, 'सही' पर सेट करें.

<जारी करने वाला>

<Issuer ref='variable-name-here'/>
<Issuer>issuer-string-here</Issuer>

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

<knownHeaders>

<KnownHeaders>a,b,c</KnownHeaders>

or:

<KnownHeaders ref=’variable_containing_headers’/>

GenerateJWT नीति, JWT में क्रिट हेडर को भरने के लिए <CriticalHeaders> एलिमेंट का इस्तेमाल करती है. उदाहरण के लिए:

{
  “typ: “...”,
  “alg” : “...”,
  “crit” : [ “a”, “b”, “c” ],
}

अगर JWT में क्रिट हेडर मौजूद है, तो इस नीति की मदद से उसकी जांच की जाती है. साथ ही, सूची में दिए गए हर हेडर के लिए यह जांच की जाती है कि <KnownHeaders> एलिमेंट में भी उस हेडर की सूची दी गई है या नहीं. <KnownHeaders> एलिमेंट में, क्रिट में दिए गए आइटम का सुपरसेट हो सकता है. सिर्फ़ यह ज़रूरी है कि क्रिट में दिए गए सभी हेडर, <KnownHeaders> एलिमेंट में शामिल हों. नीति को crit में ऐसा कोई भी हेडर मिलता है जो <KnownHeaders> में भी शामिल नहीं है. इस वजह से, VerificationJWT नीति लागू नहीं हो पाएगी.

विकल्प के तौर पर, क्रिट हेडर को अनदेखा करने के लिए, ConfirmJWT नीति को कॉन्फ़िगर किया जा सकता है. ऐसा करने के लिए, <IgnoreCriticalHeaders> एलिमेंट को true पर सेट किया जा सकता है.

<PublicKey/सर्टिफ़िकेट>

<PublicKey>
   <Certificate ref="signed_public.cert"/>
</PublicKey>
-or-
<PublicKey>
    <Certificate>
    -----BEGIN CERTIFICATE-----
    cert data
    -----END CERTIFICATE-----
    </Certificate>
</PublicKey>

यह, JWT पर हस्ताक्षर की पुष्टि करने के लिए इस्तेमाल किए गए हस्ताक्षर किए गए सर्टिफ़िकेट को तय करता है. हस्ताक्षर किए गए सर्टिफ़िकेट को फ़्लो वैरिएबल में पास करने के लिए, रेफ़रंस एट्रिब्यूट का इस्तेमाल करें या सीधे PEM में कोड में बदले गए सर्टिफ़िकेट के बारे में बताएं. सिर्फ़ तब इस्तेमाल करें, जब एल्गोरिदम RS256/RS384/RS512, PS256/PS384/PS512 या ES256/ES384/ES512 में से एक हो.

<PublicKey/JWKS>

<!-- Specify the JWKS. -->
<PublicKey>
   <JWKS>jwks-value-here</JWKS>
</PublicKey>

or:

<!-- Specify a variable containing the JWKS. -->
<PublicKey>
   <JWKS ref="public.jwks"/>
</PublicKey>

or:

<!-- Specify a public URL that returns the JWKS.
The URL is static, meaning you cannot set it using a variable. -->
<PublicKey>
   <JWKS uri="jwks-url"/>
</PublicKey>

यह JWKS फ़ॉर्मैट (RFC 7517) में ऐसी वैल्यू बताता है जिसमें सार्वजनिक कुंजियों का सेट होता है. सिर्फ़ तब इस्तेमाल करें, जब एल्गोरिदम RS256/RS384/RS512, PS256/PS384/PS512 या ES256/ES384/ES512 में से एक हो.

अगर इनबाउंड JWT में एक कुंजी आईडी है, जो JWKS के सेट में मौजूद है, तो नीति में JWT हस्ताक्षर की पुष्टि करने के लिए सही सार्वजनिक कुंजी का इस्तेमाल किया जाएगा. इस सुविधा के बारे में ज़्यादा जानने के लिए, JWT की पुष्टि करने के लिए JSON वेब कुंजी सेट (JWKS) इस्तेमाल करना लेख पढ़ें.

सार्वजनिक यूआरएल से वैल्यू फ़ेच करने पर, Edge JWKS को 300 सेकंड तक कैश मेमोरी में सेव रखता है. कैश मेमोरी की समयसीमा खत्म होने पर Edge, JWKS को फिर से फ़ेच कर लेता है.

<PublicKey/वैल्यू>

<PublicKey>
   <Value ref="public.publickeyorcert"/>
</PublicKey>
-or-
<PublicKey>
    <Value>
    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw2kPrRzcufvUNHvTH/WW
    Q0UrCw5c0+Y707KX3PpXkZGbtTT4nvU1jC0d1lHV8MfUyRXmpmnNxJHAC2F73IyN
    C5TBtXMORc+us7A2cTtC4gZV256bT4h3sIEMsDl0Joz9K9MPzVPFxa1i0RgNt06n
    Xn/Bs2UbbLlKP5Q1HPxewUDEh0gVMqz9wdIGwH1pPxKvd3NltYGfPsUQovlof3l2
    ALvO7i5Yrm96kknfFEWf1EjmCCKvz2vjVbBb6mp1ZpYfc9MOTZVpQcXSbzb/BWUo
    ZmkDb/DRW5onclGzxQITBFP3S6JXd4LNESJcTp705ec1cQ9Wp2Kl+nKrKyv1E5Xx
    DQIDAQAB
    -----END PUBLIC KEY-----
    </Value>
</PublicKey>

JWT पर हस्ताक्षर की पुष्टि करने के लिए इस्तेमाल किए जाने वाले सार्वजनिक कुंजी या सार्वजनिक प्रमाणपत्र के बारे में बताता है. फ़्लो वैरिएबल में कुंजी/सर्टिफ़िकेट पास करने के लिए, ref एट्रिब्यूट का इस्तेमाल करें या सीधे PEM से कोड में बदली गई कुंजी के बारे में बताएं. इसका इस्तेमाल सिर्फ़ तब करें, जब एल्गोरिदम RS256/RS384/RS512, PS256/PS384/PS512 या ES256/ES384/ES512 में से कोई एक हो.

<SecretKey/वैल्यू>

<SecretKey encoding="base16|hex|base64|base64url">
  <Value ref="private.your-variable-name"/>
</SecretKey>

एचएमएसी एल्गोरिदम की मदद से, टोकन की पुष्टि करने या उन पर हस्ताक्षर करने के लिए इस्तेमाल की जाने वाली सीक्रेट कुंजी देता है. सिर्फ़ तब इस्तेमाल करें, जब एल्गोरिदम HS256, HS384, HS512 में से कोई एक हो..

<सोर्स>

<Source>jwt-variable</Source>

यह मौजूद होने पर, उस फ़्लो वैरिएबल के बारे में बताया जाता है जिसमें नीति को, पुष्टि करने के लिए JWT मिलना चाहिए.

<विषय>

<Subject>subject-string-here</Subject>

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

<TimeAllowance>

<TimeAllowance>120s</TimeAllowance>

समय के लिए "ग्रेस पीरियड". उदाहरण के लिए, अगर समयसीमा को 60 सेकंड के लिए कॉन्फ़िगर किया गया है, तो जिस JWT की समयसीमा खत्म हो चुकी है उसे भी समयसीमा खत्म होने के बाद 60 सेकंड के लिए मान्य माना जाएगा. पहले के समय का आकलन भी इसी तरह किया जाएगा. डिफ़ॉल्ट तौर पर 0 सेकंड होता है (ग्रेस पीरियड नहीं).

फ़्लो वैरिएबल

सफल होने पर, JWT की पुष्टि करें और JWT की पुष्टि करें नीतियां, इस पैटर्न के हिसाब से कॉन्टेक्स्ट वैरिएबल को सेट करती हैं:

jwt.{policy_name}.{variable_name}

उदाहरण के लिए, अगर नीति का नाम jwt-parse-token है , तो यह नीति JWT में बताए गए विषय को jwt.jwt-parse-token.decoded.claim.sub नाम के कॉन्टेक्स्ट वैरिएबल में सेव करेगी. (पुराने सिस्टम के साथ काम करने की सुविधा के लिए, यह jwt.jwt-parse-token.claim.subject में भी उपलब्ध होगा)

गड़बड़ी का रेफ़रंस

इस सेक्शन में उन गड़बड़ी कोड और लौटाए गए गड़बड़ी के मैसेज के बारे में बताया गया है जो गड़बड़ी सेट करते हैं. ये मैसेज तब ट्रिगर होते हैं, जब इस नीति से गड़बड़ी होती है. यह जानकारी होना ज़रूरी है, ताकि यह पता लगाया जा सके कि आप गड़बड़ी ठीक करने के लिए नियम बना रहे हैं या नहीं. ज़्यादा जानने के लिए, नीति से जुड़ी गड़बड़ियों के बारे में ज़रूरी जानकारी और गड़बड़ी ठीक करना देखें.

रनटाइम से जुड़ी गड़बड़ियां

नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.

डिप्लॉयमेंट से जुड़ी गड़बड़ियां

ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाला प्रॉक्सी डिप्लॉय किया जाता है.

गड़बड़ी वाले वैरिएबल

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

गड़बड़ी के जवाब का उदाहरण

गड़बड़ी को ठीक करने के लिए, सबसे सही तरीका है कि आप गड़बड़ी के जवाब के errorcode हिस्से का इस्तेमाल करें. faultstring के टेक्स्ट पर भरोसा न करें, क्योंकि यह बदल सकता है.

गड़बड़ी के नियम का उदाहरण

    <FaultRules>
        <FaultRule name="JWT Policy Errors">
            <Step>
                <Name>JavaScript-1</Name>
                <Condition>(fault.name Matches "TokenExpired")</Condition>
            </Step>
            <Condition>JWT.failed=true</Condition>
        </FaultRule>
    </FaultRules>