خط‌مشی VerifyJWT

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

چه

امضای JWT دریافتی از کارخواه‌ها یا سیستم‌های دیگر را تأیید می‌کند. این خط‌مشی همچنین ادعاها را در متغیرهای زمینه‌ای استخراج می‌کند تا خط‌مشی‌ها یا شرایط بعدی بتوانند آن مقادیر را بررسی کنند و تصمیمات مربوط به مجوز یا مسیریابی را اتخاذ کنند. برای آشنایی دقیق‌تر، نمای کلی خط‌مشی‌های JWS و JWT را ببینید.

وقتی این خط‌مشی اجرا می‌شود، Edge امضای JWT را درستی‌سنجی می‌کند و درستی‌سنجی می‌کند که JWT براساس زمان‌های انقضا و قبل‌از آن معتبر باشد (درصورت وجود). خط‌مشی می‌تواند به‌صورت اختیاری مقادیر ادعاهای خاص در JWT را نیز تأیید کند، مانند موضوع، صادرکننده، مخاطب، یا مقدار ادعاهای اضافی.

اگر JWT تأیید و معتبر باشد، همه ادعاهای موجود در JWT به متغیرهای زمینه‌ای برای استفاده توسط خط‌مشی‌ها یا شرایط بعدی استخراج می‌شوند و درخواست اجازه می‌یابد ادامه یابد. اگر امضای JWT قابل‌تأیید نباشد یا اگر JWT به‌دلیل یکی از مُهر زمان‌ها نامعتبر باشد، همه پردازش‌ها متوقف می‌شود و خطایی در پاسخ برگردانده می‌شود.

برای آشنایی با بخش‌های JWT و نحوه رمزگذاری و امضای آن‌ها، به RFC7519 مراجعه کنید.

ویدیو

برای آشنایی با نحوه درستی‌سنجی امضا در JWT، یک ویدیو کوتاه تماشا کنید.

نمونه‌ها

• درستی‌سنجی JWT امضاشده با الگوریتم HS256
• درستی‌سنجی JWT امضاشده با الگوریتم RS256

درستی‌سنجی کردن JWT امضاشده با الگوریتم HS256

این خط‌مشی نمونه یک 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>

این خط‌مشی برونداد خود را در متغیرهای زمینه‌ای می‌نویسد تا خط‌مشی‌ها یا شرایط بعدی در پراکسی API بتوانند آن مقادیر را بررسی کنند. برای فهرست متغیرهای تنظیم‌شده توسط این خط‌مشی، متغیرهای جاری‌سازی را ببینید.

درستی‌سنجی کردن JWT امضاشده با الگوریتم RS256

این خط‌مشی نمونه یک 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."
}

… نامعتبر تشخیص داده می‌شود، حتی اگر امضا قابل‌تأیید باشد، زیرا ادعای «sub» که در JWT گنجانده شده است با مقدار موردنیاز عنصر «Subject» که در پیکربندی خط‌مشی مشخص شده است مطابقت ندارد.

این خط‌مشی برونداد خود را در متغیرهای زمینه‌ای می‌نویسد تا خط‌مشی‌ها یا شرایط بعدی در پراکسی API بتوانند آن مقادیر را بررسی کنند. برای فهرست متغیرهای تنظیم‌شده توسط این خط‌مشی، متغیرهای جاری‌سازی را ببینید.

تنظیم عناصر کلیدی

عناصری که برای مشخص کردن کلید استفاده‌شده برای درستی‌سنجی 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». بااین‌حال، نمی‌توانید الگوریتم‌های HS* را با الگوریتم‌های دیگر یا الگوریتم‌های 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> این مشخصه‌ها را می‌پذیرد:

• نام - (الزامی) نام دعوی.
• ref - (اختیاری) نام متغیر جاری. اگر وجود داشته باشد، خط‌مشی از مقدار این متغیر به‌عنوان ادعا استفاده خواهد کرد. اگر هم مشخصه ref و هم مقدار ادعای صریح مشخص شده باشد، مقدار صریح مقدار پیش‌فرض است و اگر متغیر جاری‌سازی ارجاع‌داده‌شده حل‌نشده باشد، استفاده می‌شود.
• نوع - (اختیاری) یکی از این موارد: رشته (پیش‌فرض)، عدد، مقدار منطقی، یا نقشه
• آرایه - (اختیاری) برای نشان دادن اینکه مقدار آرایه‌ای از انواع است، روی درست تنظیم کنید. پیش‌فرض: نادرست.

وقتی عنصر <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> این مشخصه‌ها را می‌پذیرد:

• نام - (الزامی) نام دعوی.
• ref - (اختیاری) نام متغیر جاری. اگر وجود داشته باشد، خط‌مشی از مقدار این متغیر به‌عنوان ادعا استفاده خواهد کرد. اگر هم مشخصه ref و هم مقدار ادعای صریح مشخص شده باشد، مقدار صریح مقدار پیش‌فرض است و اگر متغیر جاری‌سازی ارجاع‌داده‌شده حل‌نشده باشد، استفاده می‌شود.
• نوع - (اختیاری) یکی از این موارد: رشته (پیش‌فرض)، عدد، مقدار منطقی، یا نقشه
• آرایه - (اختیاری) برای نشان دادن اینکه مقدار آرایه‌ای از انواع است، روی درست تنظیم کنید. پیش‌فرض: نادرست.

<CustomClaims>

توجه: درحال‌حاضر، وقتی خط‌مشی GenerateJWT جدیدی را ازطریق رابط کاربری اضافه می‌کنید، عنصر CustomClaims درج می‌شود. این عنصر عملکردی نیست و نادیده گرفته می‌شود. عنصر صحیح برای استفاده به‌جای آن <AdditionalClaims> است. رابط کاربری در زمان دیگری به‌روز خواهد شد تا عناصر صحیح را درج کند.

<Id>

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

تأیید می‌کند که JWT ادعای jti خاص را دارد. وقتی مقدار نوشتاری و مشخصه ref هر دو خالی باشند، خط‌مشی یک jti حاوی UUID تصادفی تولید می‌کند. ادعای شناسه JWT (jti) یک شناسه یکتا برای JWT است. برای کسب اطلاعات بیشتر درباره jti، به RFC7519 مراجعه کنید.

<IgnoreCriticalHeaders>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

اگر می‌خواهید وقتی هریک از سرایندهای فهرست‌شده در سرایند crit مربوط به JWT در عنصر <KnownHeaders> فهرست نشده است، خط‌مشی خطا ایجاد کند، روی false تنظیم کنید. برای اینکه خط‌مشی VerifyJWT سرصفحه crit را نادیده بگیرد، روی درست تنظیم کنید.

یکی از دلایل تنظیم این عنصر روی درست این است که اگر در محیط آزمایشی هستید و هنوز آماده نیستید باعث ایجاد خطا در سرایند ازدست‌رفته شوید.

<IgnoreIssuedAt>

<IgnoreIssuedAt>true|false</IgnoreIssuedAt>

اگر می‌خواهید خط‌مشی درصورتی‌که JWT حاوی ادعای iat (صادرشده در) باشد که زمان آینده را مشخص می‌کند، خطا ایجاد کند، آن را روی false (پیش‌فرض) تنظیم کنید. برای اینکه خط‌مشی باعث شود 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> برای پر کردن سرصفحه crit در JWT استفاده می‌کند. برای مثال:

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

خط‌مشی VerifyJWT سرصفحه crit را در JWT بررسی می‌کند، درصورت وجود، و برای هر سرصفحه فهرست‌شده، بررسی می‌کند که عنصر <KnownHeaders> نیز آن سرصفحه را فهرست کرده باشد. عنصر <KnownHeaders> می‌تواند شامل مجموعه‌ای از موارد فهرست‌شده در crit باشد. فقط لازم است که همه سرایندهای فهرست‌شده در crit در عنصر <KnownHeaders> فهرست شده باشند. هر سرصفحه‌ای که خط‌مشی در crit پیدا کند و در <KnownHeaders> فهرست نشده باشد باعث می‌شود خط‌مشی VerifyJWT ناموفق باشد.

می‌توانید خط‌مشی VerifyJWT را به‌صورت اختیاری پیکربندی کنید تا سرصفحه crit را با تنظیم عنصر <IgnoreCriticalHeaders> روی true نادیده بگیرد.

<PublicKey/Certificate>

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

گواهی امضاشده‌ای را که برای درستی‌سنجی امضای JWT استفاده می‌شود مشخص می‌کند. از مشخصه ref برای گذراندن گواهینامه امضاشده در متغیر جاری، یا مشخص کردن مستقیم گواهینامه کدبندی‌شده 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 استفاده خواهد کرد. برای جزئیات بیشتر درباره این ویژگی، استفاده از مجموعه کلید وب JSON (JWKS) برای تأیید JWT را ببینید.

اگر مقدار را از نشانی وب عمومی واکشی کنید، Edge مقدار 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>

کلید عمومی یا گواهی عمومی مورداستفاده برای درستی‌سنجی امضای JWT را مشخص می‌کند. از مشخصه ref برای گذراندن کلید/گواهینامه در متغیر جاری‌سازی، یا مشخص کردن مستقیم کلید کدبندی‌شده با 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>

کلید رمزی را که برای درستی‌سنجی یا امضا کردن نشان‌ها با الگوریتم HMAC استفاده می‌شود ارائه می‌دهد. فقط زمانی استفاده کنید که الگوریتم یکی از HS256،‏ HS384،‏ HS512 باشد..

<Source>

<Source>jwt-variable</Source>

درصورت وجود، متغیر جریانی را مشخص می‌کند که خط‌مشی انتظار دارد JWT را در آن پیدا کند تا درستی‌سنجی کند.

<Subject>

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

خط‌مشی تأیید می‌کند که موضوع در JWT با رشته مشخص‌شده در پیکربندی خط‌مشی مطابقت دارد. این ادعا موضوع JWT را شناسایی می‌کند یا بیانیه‌ای درباره آن ارائه می‌دهد. این یکی از مجموعه استاندارد ادعاهای ذکرشده در RFC7519 است.

<TimeAllowance>

<TimeAllowance>120s</TimeAllowance>

«مهلت ارفاقی» برای زمان‌ها. برای مثال، اگر زمان مجاز روی ۶۰ ثانیه پیکربندی شده باشد، ‫JWT منقضی‌شده تا ۶۰ ثانیه پس‌از انقضای ادعاشده همچنان معتبر درنظر گرفته می‌شود. زمان not-before-time به همین شکل ارزیابی خواهد شد. به‌طور پیش‌فرض روی ۰ ثانیه (بدون دوره ارفاق) تنظیم می‌شود.

متغیرهای جریان

پس از موفقیت، سیاست های 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>