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 एन्क्रिप्शन एल्गोरिदम, HMAC की मदद से साइन किया गया था SHA-256 चेकसम का इस्तेमाल करके. JWT को jwt. कुंजी private.secretkey नाम वाले वैरिएबल में मौजूद होती है. पूरा उदाहरण देखने के लिए ऊपर दिया गया वीडियो देखें. इसमें नीति के लिए अनुरोध करने का तरीका भी बताया गया है.

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

<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 में शामिल दावा "विषय" के आवश्यक मान से मेल नहीं खाता इस रूप में एलिमेंट नीति कॉन्फ़िगरेशन में बताया गया है.

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

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

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>

<Algorithm>HS256</Algorithm>

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

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

<Audience>

<Audience>audience-here</Audience>

or:

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

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

<AdditionalClaims/Claim>

<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 पर सेट करके बताएं कि वैल्यू, अलग-अलग टाइप के कलेक्शन में से एक है या नहीं. डिफ़ॉल्ट: गलत.

<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>

<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 पर सेट करके बताएं कि वैल्यू, अलग-अलग टाइप के कलेक्शन में से एक है या नहीं. डिफ़ॉल्ट: गलत.

<CustomClaims>

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

<Id>

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

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

<IgnoreCriticalHeaders>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

अगर आप चाहते हैं कि नीति की वजह से, 'गलत' पर सेट हो, तो JWT का crit हेडर, <KnownHeaders> एलिमेंट में शामिल नहीं है. 'सही' पर सेट करें, ताकि VerifyJWT नीति crit हेडर को अनदेखा कर सके.

इस एलिमेंट को सही पर सेट करने की एक वजह यह है कि अगर आप टेस्टिंग एनवायरमेंट में हैं और आपने अब तक छूटी हुई हेडर की गड़बड़ी को ठीक करने के लिए तैयार है.

<IgnoreIssuedAt>

<IgnoreIssuedAt>true|false</IgnoreIssuedAt>

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

<IgnoreUnresolvedVariables>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

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

<Issuer>

<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 नीति <CriticalHeaders> एलिमेंट का इस्तेमाल करती है किसी JWT में crit हेडर. उदाहरण के लिए:

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

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

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

<PublicKey/Certificate>

<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 Web Key सेट (JWKS) का इस्तेमाल करना.

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

<PublicKey/Value>

<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>

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

<SecretKey/Value>

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

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

<Source>

<Source>jwt-variable</Source>

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

<Subject>

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

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

<TimeAllowance>

<TimeAllowance>120s</TimeAllowance>

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

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

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

jwt.{policy_name}.{variable_name}

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

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

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

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

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

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

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

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

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

गड़बड़ी के रिस्पॉन्स का उदाहरण

गड़बड़ी ठीक करने के लिए, सबसे सही तरीका यह है कि गड़बड़ी के 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>