এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

JWS এবং JWT নীতি ওভারভিউ

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

এই বিষয়টিতে JWT (JSON Web Token) ও JWS (JSON Web Signature) এবং Apigee-এর JWS/JWT নীতিমালা সম্পর্কে সাধারণ তথ্য প্রদান করা হয়েছে, যা Apigee প্রক্সি ডেভেলপারদের জন্য আগ্রহের বিষয় হতে পারে।

ভূমিকা

সংযুক্ত অ্যাপ্লিকেশনগুলির মধ্যে ক্লেইম বা অ্যাসারশন শেয়ার করার জন্য JWS এবং JWT উভয়ই সাধারণত ব্যবহৃত হয়। JWS/JWT পলিসিগুলি এজ এপিআই প্রক্সিগুলিকে নিম্নলিখিত কাজগুলো করতে সক্ষম করে:

একটি স্বাক্ষরিত JWT বা JWS তৈরি করুন ।
একটি স্বাক্ষরিত JWT বা JWS এবং এর অন্তর্ভুক্ত দাবিগুলো যাচাই করুন ।
স্বাক্ষর যাচাই না করেই একটি স্বাক্ষরিত JWT বা JWS ডিকোড করুন ।

পরবর্তী দুটি ক্ষেত্রে, পলিসিটি এমন ভেরিয়েবলও নির্ধারণ করে দেয়, যা অতিরিক্ত পলিসিগুলোকে, অথবা স্বয়ং ব্যাকএন্ড সার্ভিসগুলোকেই, যাচাইকৃত দাবিগুলো পরীক্ষা করতে এবং সেই দাবিগুলোর উপর ভিত্তি করে সিদ্ধান্ত নিতে সক্ষম করে।

Verify JWS/JWT পলিসি ব্যবহার করার সময়, একটি অবৈধ JWS/JWT প্রত্যাখ্যাত হবে এবং এর ফলে একটি ত্রুটি দেখা দেবে। একইভাবে, Decode JWS/JWT পলিসি ব্যবহার করার সময়, একটি ত্রুটিপূর্ণ JWS/JWT-এর ফলে একটি ত্রুটি দেখা দেবে।

ভিডিও

JWT সম্পর্কে দ্রুত পরিচিতির জন্য একটি ছোট ভিডিও দেখুন। যদিও এই ভিডিওটি বিশেষভাবে JWT তৈরি করার জন্য, এর অনেক ধারণাই JWS-এর ক্ষেত্রেও একই।

JWT কাঠামো সম্পর্কে আরও জানতে কী চমৎকার একটি সংক্ষিপ্ত ভিডিও।

ব্যবহারের ক্ষেত্র

আপনি JWS/JWT পলিসিগুলো নিম্নলিখিত কাজে ব্যবহার করতে পারেন:

একটি এজ প্রক্সির প্রক্সি অথবা টার্গেট এন্ডপয়েন্ট উভয় দিকেই একটি নতুন JWS/JWT তৈরি করুন। উদাহরণস্বরূপ, আপনি এমন একটি প্রক্সি রিকোয়েস্ট ফ্লো তৈরি করতে পারেন যা একটি JWS/JWT তৈরি করে এবং ক্লায়েন্টের কাছে তা ফেরত পাঠায়। অথবা, আপনি এমনভাবে একটি প্রক্সি ডিজাইন করতে পারেন যাতে এটি টার্গেট রিকোয়েস্ট ফ্লোতে একটি JWS/JWT তৈরি করে এবং টার্গেটে পাঠানো রিকোয়েস্টের সাথে তা সংযুক্ত করে। এরপর সেই ক্লেইমগুলো ব্যাকএন্ড সার্ভিসগুলোকে আরও নিরাপত্তা প্রক্রিয়াকরণ প্রয়োগ করতে সক্ষম করার জন্য উপলব্ধ থাকবে।
ইনবাউন্ড ক্লায়েন্ট অনুরোধ, টার্গেট পরিষেবা প্রতিক্রিয়া, পরিষেবা কলআউট নীতি প্রতিক্রিয়া বা অন্যান্য উৎস থেকে প্রাপ্ত JWS/JWT থেকে ক্লেইম যাচাই এবং নিষ্কাশন করুন। JWS/JWT-টি কোনো তৃতীয় পক্ষ দ্বারা তৈরি হোক বা Edge নিজেই তৈরি করুক, Edge RSA বা HMAC অ্যালগরিদম ব্যবহার করে সেটির সিগনেচার যাচাই করবে।
একটি JWS/JWT ডিকোড করুন। ডিকোডিং সবচেয়ে বেশি কার্যকর হয় যখন এটি 'Verify JWS/JWT' পলিসির সাথে একত্রে ব্যবহার করা হয়, বিশেষত যখন JWS/JWT যাচাই করার আগে এর ভেতর থেকে কোনো ক্লেইম (JWT) বা হেডারের (JWS/JWT) মান জানা আবশ্যক হয়।

JWS/JWT এর অংশবিশেষ

একটি স্বাক্ষরিত JWS/JWT ডট (ডট) দ্বারা পৃথক করা তিনটি অংশে তথ্য এনকোড করে: হেডার, পেলোড এবং সিগনেচার।

header.payload.signature

Generate JWS/JWT পলিসিটি তিনটি অংশই তৈরি করে।
JWS/JWT যাচাইকরণ নীতিটি এই তিনটি অংশই পরীক্ষা করে।
ডিকোড JWS/JWT পলিসিটি শুধুমাত্র হেডার এবং পেলোড পরীক্ষা করে।

একটি JWS এমন একটি বিচ্ছিন্ন ফরম্যাটও সমর্থন করে যা JWS থেকে পেলোড বাদ দেয়:

header..signature

একটি ডিটাচড JWS-এর ক্ষেত্রে, পেলোডটি JWS থেকে আলাদাভাবে পাঠানো হয়। আপনি র, আনএনকোডেড JWS পেলোড নির্দিষ্ট করার জন্য ভেরিফাই JWS পলিসির <DetachedContent> এলিমেন্টটি ব্যবহার করেন। এরপর ভেরিফাই JWS পলিসিটি JWS-এর হেডার ও সিগনেচার এবং <DetachedContent> এলিমেন্ট দ্বারা নির্দিষ্ট করা পেলোড ব্যবহার করে JWS-টিকে ভেরিফাই করে।

টোকেন এবং সেগুলি কীভাবে এনকোড ও সাইন করা হয় সে সম্পর্কে আরও জানতে, দেখুন:

JWT : IETF RFC7519
JWS : IETF RFC7515

JWS এবং JWT এর মধ্যে পার্থক্য

সংযুক্ত অ্যাপ্লিকেশনগুলোর মধ্যে ক্লেইম বা অ্যাসারশন শেয়ার করার জন্য আপনি JWT অথবা JWS ব্যবহার করতে পারেন। উভয়ের মধ্যে প্রধান পার্থক্য হলো পেলোডের উপস্থাপনা:

জেডব্লিউটি
- পেলোড সর্বদা একটি JSON অবজেক্ট হয়
- পেলোডটি সর্বদা JWT-এর সাথে সংযুক্ত থাকে।
- টোকেনের typ হেডার সর্বদা JWT তে সেট করা থাকে।
জেডব্লিউএস
- পেলোডকে যেকোনো ফরম্যাটে উপস্থাপন করা যেতে পারে, যেমন JSON অবজেক্ট, বাইট স্ট্রিম, অক্টেট স্ট্রিম এবং অন্যান্য।
- পেলোডটি JWS-এর সাথে সংযুক্ত থাকার প্রয়োজন নেই।

যেহেতু JWT ফরম্যাট পেলোডকে উপস্থাপন করার জন্য সর্বদা একটি JSON অবজেক্ট ব্যবহার করে, তাই Edge Generate JWT এবং Verify JWT পলিসিগুলোতে aud , iss , sub এবং অন্যান্য সাধারণ Registered Claim Name-গুলো পরিচালনা করার জন্য অন্তর্নির্মিত সমর্থন রয়েছে। এর মানে হলো, আপনি এই ক্লেইমগুলোকে পেলোডে সেট করার জন্য Generate JWT পলিসির উপাদানগুলো ব্যবহার করতে পারেন এবং এদের মান যাচাই করার জন্য Verify JWT পলিসির উপাদানগুলো ব্যবহার করতে পারেন। আরও তথ্যের জন্য JWT স্পেসিফিকেশনের Registered Claim Names বিভাগটি দেখুন।

নির্দিষ্ট কিছু রেজিস্টার্ড ক্লেইম নেম সমর্থন করার পাশাপাশি, জেনারেট JWT পলিসিটি সরাসরি JWT-তে যথেচ্ছ নামের ক্লেইম যোগ করা সমর্থন করে। প্রতিটি ক্লেইম হলো একটি সাধারণ নাম/মান জোড়া, যেখানে মানটি সংখ্যা, বুলিয়ান, স্ট্রিং, ম্যাপ বা অ্যারে টাইপের হতে পারে।

যেহেতু একটি JWS পেলোডের জন্য যেকোনো ডেটা রিপ্রেজেন্টেশন ব্যবহার করতে পারে, তাই আপনি পেলোডে ক্লেইম যোগ করতে পারবেন না। তবে, 'জেনারেট JWS' পলিসিটি JWS-এর হেডারে যথেচ্ছ নামের ক্লেইম যোগ করা সমর্থন করে। এছাড়াও, JWS পলিসিগুলো একটি ডিটাচড পেলোড সমর্থন করে, যেখানে JWS পেলোডটি বাদ দেয়। একটি ডিটাচড পেলোড আপনাকে JWS এবং পেলোড আলাদাভাবে পাঠাতে দেয় এবং এটি বেশ কিছু নিরাপত্তা স্ট্যান্ডার্ডের জন্য আবশ্যক।

JWS এবং JWT ব্যবহার করার সময় টেমপ্লেট ইনজেকশন প্রতিরোধ করুন।

অননুমোদিত ডেটা প্রকাশ রোধ করতে, GenerateJWT বা GenerateJWS পলিসি ব্যবহার করার সময় এই নির্দেশিকাগুলি অনুসরণ করুন:

ব্যবহারকারীর ইনপুটের সরাসরি উল্লেখ পরিহার করুন: টেমপ্লেটিং সমর্থন করে এমন কোনো ref অ্যাট্রিবিউটে কখনও সরাসরি অবিশ্বস্ত ইনপুট (যেমন request.queryparam.* বা request.header.* ) ব্যবহার করবেন না।
ইনপুট পরিশুদ্ধ করুন: যদি আপনাকে কোনো JWT/JWS ক্লেইমে বাহ্যিক ডেটা ব্যবহার করতেই হয়, তবে সেটিকে রেফারেন্স করার আগে প্রথমে একটি AssignMessage পলিসি ব্যবহার করে ইনপুট থেকে যেকোনো কার্লি ব্রেস ( { } ) বা অন্যান্য টেমপ্লেট ক্যারেক্টার বাদ দিন।
স্ট্রিং-এর জন্য সুস্পষ্ট ক্লেইম ব্যবহার করুন: সাধারণ স্ট্রিং ক্লেইমের ক্ষেত্রে type="map" করা থেকে বিরত থাকুন। ডিফল্ট type="string" ব্যবহার করলে রেফারেন্সকৃত ভ্যালুটির অন্তর্নিহিত টেমপ্লেটিং প্রতিরোধ করা হয়।
ভেরিফাই এবং জেনারেট পলিসিগুলোর আচরণগত অসামঞ্জস্যটি লক্ষ্য করুন: টেমপ্লেটিংয়ের ক্ষেত্রে JWS এবং JWT জেনারেশন পলিসিগুলো ভেরিফাই পলিসিগুলোর থেকে ভিন্নভাবে কাজ করে।
গুরুত্বপূর্ণ: যদিও VerifyJWS এবং VerifyJWT পলিসিগুলো ref অ্যাট্রিবিউটের মাধ্যমে কোনো ভ্যারিয়েবল রিজলভ করার সময় মেসেজ টেমপ্লেটিং প্রয়োগ করে না, GenerateJWT এবং GenerateJWS পলিসিগুলো নির্দিষ্ট কনফিগারেশনে টেমপ্লেটিং প্রয়োগ করে। নিরাপত্তা ঝুঁকি এড়াতে আপনার প্রক্সি লজিক যেন এই পার্থক্যটি বিবেচনা করে, তা নিশ্চিত করুন।

স্বাক্ষর অ্যালগরিদম সম্পর্কে

JWS/JWT ভেরিফিকেশন এবং JWS/JWT জেনারেশন পলিসিগুলো ২৫৬, ৩৮৪ বা ৫১২ বিট স্ট্রেংথের SHA2 চেকসাম ব্যবহার করে RSA, RSASSA-PSS, ECDSA এবং HMAC অ্যালগরিদম সমর্থন করে। JWS/JWT-তে স্বাক্ষর করার জন্য কোন অ্যালগরিদম ব্যবহার করা হয়েছে তা নির্বিশেষে JWS/JWT ডিকোড পলিসিটি কাজ করে।

HMAC অ্যালগরিদম

HMAC অ্যালগরিদম সিগনেচার তৈরি (যা JWS/JWT-তে স্বাক্ষর করা নামেও পরিচিত) এবং সিগনেচার যাচাই করার জন্য সিক্রেট কী নামে পরিচিত একটি শেয়ার্ড সিক্রেটের উপর নির্ভর করে।

গোপন কী-এর সর্বনিম্ন দৈর্ঘ্য অ্যালগরিদমের বিট শক্তির উপর নির্ভর করে:

HS256: সর্বনিম্ন কী-দৈর্ঘ্য ৩২ বাইট
HS386: সর্বনিম্ন কী-দৈর্ঘ্য ৪৮ বাইট
HS512: সর্বনিম্ন কী-দৈর্ঘ্য ৬৪ বাইট

আরএসএ অ্যালগরিদম

RSA অ্যালগরিদম ক্রিপ্টোগ্রাফিক স্বাক্ষরের জন্য একটি পাবলিক/প্রাইভেট কী জোড়া ব্যবহার করে। RSA স্বাক্ষরের ক্ষেত্রে, স্বাক্ষরকারী পক্ষ JWS/JWT-তে স্বাক্ষর করার জন্য একটি RSA প্রাইভেট কী ব্যবহার করে এবং যাচাইকারী পক্ষ JWS/JWT-এর স্বাক্ষরটি যাচাই করার জন্য সংশ্লিষ্ট RSA পাবলিক কী ব্যবহার করে। কীগুলোর আকারের উপর কোনো বাধ্যবাধকতা নেই।

RSASSA-PSS অ্যালগরিদম

RSASSA-PSS অ্যালগরিদম হলো RSA অ্যালগরিদমের একটি আপডেট সংস্করণ। RSS-এর মতোই, RSASSA-PSS ক্রিপ্টোগ্রাফিক স্বাক্ষরের জন্য একটি RSA পাবলিক/প্রাইভেট কী পেয়ার ব্যবহার করে। কী-টির ফরম্যাট RSS-এর মতোই। স্বাক্ষরকারী পক্ষ JWS/JWT-তে স্বাক্ষর করার জন্য একটি প্রাইভেট কী ব্যবহার করে, এবং যাচাইকারী পক্ষ JWS/JWT-এর স্বাক্ষরটি যাচাই করার জন্য সংশ্লিষ্ট পাবলিক কী ব্যবহার করে। কী-গুলোর আকারের উপর কোনো বাধ্যবাধকতা নেই।

ECDSA অ্যালগরিদম

এলিপটিক কার্ভ ডিজিটাল সিগনেচার অ্যালগরিদম (ECDSA) হলো একটি এলিপটিক-কার্ভ ক্রিপ্টোগ্রাফি অ্যালগরিদম যা P-256, P-384, এবং P-521 কার্ভ অনুসরণ করে। যখন আপনি ECDSA অ্যালগরিদম ব্যবহার করেন, তখন এই অ্যালগরিদমই নির্ধারণ করে দেয় যে আপনাকে কোন ধরনের পাবলিক এবং প্রাইভেট কী নির্দিষ্ট করতে হবে।

অ্যালগরিদম	বক্ররেখা	মূল প্রয়োজনীয়তা
ES256	পি-২৫৬	P-256 কার্ভ (যা secp256r1 বা prime256v1 নামেও পরিচিত) থেকে তৈরি একটি কী।
ES384	পি-৩৮৪	P-384 কার্ভ (secp384r1 নামেও পরিচিত) থেকে তৈরি একটি কী
ES512	পি-৫২১	P-521 কার্ভ (যা secp521r1 নামেও পরিচিত) থেকে তৈরি একটি কী

কী এনক্রিপশন অ্যালগরিদম

JWS/JWT পলিসিগুলো OpenSSL দ্বারা সমর্থিত সকল কী এনক্রিপশন অ্যালগরিদমকে সাপোর্ট করে।

একটি JWS/JWT যাচাই করার জন্য JSON ওয়েব কী সেট (JWKS) ব্যবহার করা

যখন আপনি একটি স্বাক্ষরিত JWS/JWT যাচাই করেন, তখন টোকেনটি স্বাক্ষর করতে ব্যবহৃত প্রাইভেট কী-এর সাথে যুক্ত পাবলিক কী-টি আপনাকে প্রদান করতে হবে। JWS/JWT পলিসিগুলো যাচাই করার জন্য পাবলিক কী প্রদান করতে আপনার কাছে দুটি বিকল্প রয়েছে:

প্রকৃত পাবলিক কী মান ব্যবহার করুন (যা সাধারণত একটি ফ্লো ভেরিয়েবলে সরবরাহ করা হয়), অথবা
JWKS-এ মোড়ানো একটি পাবলিক কী ব্যবহার করুন।

JWKS সম্পর্কে

একটি JWKS হলো একটি JSON কাঠামো যা এক সেট JSON ওয়েব কী (JWK) উপস্থাপন করে। একটি JWK হলো একটি JSON ডেটা কাঠামো যা একটি ক্রিপ্টোগ্রাফিক কী উপস্থাপন করে। JWK এবং JWKS সম্পর্কে RFC7517- এ বর্ণনা করা হয়েছে। পরিশিষ্ট A-তে JKWS-এর উদাহরণ দেখুন। JSON ওয়েব কী সেটের উদাহরণ।

JWKS কাঠামো

RFC7517 প্রতিটি কী টাইপের (যেমন "RSA" বা "EC") জন্য JWKS কী এলিমেন্টগুলো বর্ণনা করে। উদাহরণস্বরূপ, কী টাইপের উপর নির্ভর করে, এই প্যারামিটারগুলোর মধ্যে অন্তর্ভুক্ত থাকতে পারে:

kty - কী-এর ধরন, যেমন "RSA" বা "EC"।
kid (কী আইডি) - এটি যেকোনো যথেচ্ছ মান হতে পারে (একটি কী সেটের মধ্যে কোনো সদৃশ মান থাকতে পারবে না)। যদি আগত JWT-তে এমন একটি কী আইডি থাকে যা JWKS সেটে উপস্থিত, তাহলে পলিসিটি JWS/JWT স্বাক্ষর যাচাই করার জন্য সঠিক পাবলিক কী ব্যবহার করবে।

নিচে ঐচ্ছিক উপাদান এবং তাদের মানের উদাহরণ দেওয়া হলো:

alg - মূল অ্যালগরিদম। এটি অবশ্যই JWS/JWT-তে থাকা স্বাক্ষরকারী অ্যালগরিদমের সাথে মিলতে হবে।
ব্যবহার - যদি থাকে, তবে অবশ্যই বিশেষ্য হতে হবে।

নিম্নলিখিত 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 হেডারে একটি Key ID (বা kid) যুক্ত করে দেয়। এই কী-টি JWS/JWT-এর প্রাপককে বলে দেয় যে, স্বাক্ষরিত JWS/JWT-এর স্বাক্ষর যাচাই করার জন্য প্রয়োজনীয় পাবলিক বা সিক্রেট কী কীভাবে খুঁজে পাওয়া যাবে।

উদাহরণস্বরূপ, ধরা যাক একজন ইস্যুকারী একটি প্রাইভেট কী ব্যবহার করে একটি JWT-তে স্বাক্ষর করেন। "কী আইডি" (Key ID) JWT-টি যাচাই করার জন্য ব্যবহারযোগ্য সংশ্লিষ্ট পাবলিক কী-টিকে শনাক্ত করে। পাবলিক কী-গুলোর তালিকা সাধারণত কোনো সুপরিচিত এন্ডপয়েন্টে পাওয়া যায়, যেমন: https://www.googleapis.com/oauth2/v3/certs ।

JWKS যুক্ত একটি JWS/JWT-এর সাথে কাজ করার জন্য Edge (বা JWKS নিয়ে কাজ করে এমন যেকোনো প্ল্যাটফর্ম)-কে এই মৌলিক অনুক্রমটি অনুসরণ করতে হয়:

কী আইডি (kid) খুঁজে বের করার জন্য JWS/JWT হেডারটি পরীক্ষা করুন।
স্বাক্ষর অ্যালগরিদম (alg), যেমন RS256, খুঁজে বের করার জন্য JWS/JWT হেডারটি পরীক্ষা করুন।
প্রদত্ত কোনো ইস্যুকারীর জন্য সুপরিচিত এন্ডপয়েন্টের JWKS থেকে কী এবং আইডি-গুলির তালিকা পুনরুদ্ধার করুন।
যদি JWKS কী-তে অ্যালগরিদম নির্দিষ্ট করা থাকে, তবে JWS/JWT হেডারে উল্লিখিত কী আইডি এবং মিলে যাওয়া অ্যালগরিদমযুক্ত কী-গুলোর তালিকা থেকে পাবলিক কী-টি বের করুন।
JWS/JWT-এর স্বাক্ষর যাচাই করতে সেই পাবলিক কী ব্যবহার করুন।
দ্রষ্টব্য: Verify JWS/JWT পলিসিগুলো স্বয়ংক্রিয়ভাবে কী-এর জন্য কী-আইডি অনুসন্ধান করে থাকে।

একজন Edge API প্রক্সি ডেভেলপার হিসেবে JWS/JWT ভেরিফিকেশন করার জন্য আপনাকে নিম্নলিখিত কাজগুলো করতে হবে:

প্রদত্ত ইস্যুয়ারের জন্য সুপরিচিত এন্ডপয়েন্ট থেকে কী এবং আইডি-গুলির তালিকা পুনরুদ্ধার করুন। এই ধাপটির জন্য আপনি একটি সার্ভিস কলআউট পলিসি ব্যবহার করতে পারেন।
দ্রষ্টব্য: প্রতিটি অনুরোধে সার্ভিস কলআউট এড়ানোর জন্য JWKS ক্যাশ করে রাখা একটি ভালো অভ্যাস।

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 পলিসি বাকি সবকিছু করে:

যদি JWT-তে উল্লিখিত Key ID (kid)-এর সাথে মেলে এমন Key ID সহ কোনো কী JWKS-এ খুঁজে না পাওয়া যায়, তাহলে Verify JWT পলিসিটি একটি ত্রুটি দেখায় এবং JWT-টিকে যাচাই করে না।
যদি আগত JWT-এর হেডারে কোনো কী আইডি (kid) না থাকে, তাহলে কী আইডি থেকে ভেরিফিকেশন কী-এর এই ম্যাপিং সম্ভব নয়।

প্রক্সি ডিজাইনার হিসেবে, কোন কী ব্যবহার করা হবে তা নির্ধারণ করার দায়িত্ব আপনার; কিছু ক্ষেত্রে এটি একটি নির্দিষ্ট, হার্ড-কোডেড কী হতে পারে।