JWS ও JWT নীতি এক নজরে

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য

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

ভূমিকা

কানেক্ট করা অ্যাপ্লিকেশনগুলির মধ্যে দাবি বা অ্যাসার্শন শেয়ার করার জন্য JWS ও JWT, দুটিই সাধারণত ব্যবহার করা হয়। JWS/JWT নীতি Edge API প্রক্সিগুলিকে এগুলি করতে দেয়:

  • স্বাক্ষর করা JWT অথবা JWS জেনারেট করুন।
  • স্বাক্ষরিত JWT বা JWS এবং JWS/JWT-এর মধ্যে দাবি যাচাই করুন।
  • সিগনেচার যাচাই না করেই সাইন করা JWT বা JWS ডিকোড করুন।

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

Verify JWS/JWT নীতি ব্যবহার করার সময়, কোনও ভুল JWS/JWT বাতিল করা হবে এবং এর ফলে error কন্ডিশন তৈরি হবে। একইভাবে, Decode JWS/JWT নীতি ব্যবহার করার সময়, কোনও ভুল JWS/JWT থাকলে, তার ফলে সমস্যা হবে।

ভিডিও

JWT সম্পর্কে দ্রুত জানতে একটি ছোট ভিডিও দেখুন। এই ভিডিওটি JWT জেনারেট করার জন্য নির্দিষ্ট হলেও, JWS-এর জন্য অনেক কনসেপ্ট একই।

JWT স্ট্রাকচার সম্পর্কে আরও জানতে এই ছোট ভিডিওটি দেখুন।

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

আপনি এইসব কাজের জন্য JWS/JWT নীতি ব্যবহার করতে পারবেন:

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

JWS/JWT-এর অংশ

স্বাক্ষরিত JWS/JWT-তে পিরিয়ড দিয়ে আলাদা করা তিনটি অংশে তথ্য এনকোড করা থাকে: হেডার, পেলোড ও সিগনেচার:

header.payload.signature
  • Generate JWS/JWT নীতি এই তিনটি অংশই তৈরি করে।
  • Verify JWS/JWT নীতি এই তিনটি অংশই পরীক্ষা করে দেখে।
  • Decode JWS/JWT নীতি শুধুমাত্র হেডার ও পেলোড পরীক্ষা করে।

এছাড়াও, JWS-এ আলাদা করা ফর্ম্যাট কাজ করে যা JWS থেকে পেলোড বাদ দেয়:

header..signature

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

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

JWS ও JWT-এর মধ্যে পার্থক্য

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

  • JWT
    • পেলোড সবসময় JSON অবজেক্ট হয়
    • পে-লোড সবসময় JWT-এর সাথে অ্যাটাচ করা থাকে
    • টোকেনের typ হেডার সবসময় JWT হিসেবে সেট করা থাকে
  • JWS
    • পে-লোডকে JSON অবজেক্ট, বাইট স্ট্রিম, অক্টেট স্ট্রিম ও অন্যান্য ফর্ম্যাটের মাধ্যমে দেখানো যেতে পারে
    • JWS-এর সাথে পেলোড অ্যাটাচ করার প্রয়োজন নেই

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

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

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

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

অননুমোদিত ডেটা ডিসক্লোজার আটকাতে, GenerateJWT বা GenerateJWS নীতি ব্যবহার করার সময় এইসব নির্দেশিকা মেনে চলুন:

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

সিগনেচার অ্যালগরিদম সম্পর্কে

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

HMAC অ্যালগরিদম

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

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

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

RSA অ্যালগরিদম

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

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

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

ECDSA অ্যালগরিদম

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

অ্যালগরিদম বক্র গুরুত্বপূর্ণ প্রয়োজনীয়তা
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 ওয়েব কী (JWK)-এর একটি সেটকে উপস্থাপন করে। JWK হল একটি JSON ডেটা স্ট্রাকচার যা ক্রিপ্টোগ্রাফিক কীকে উপস্থাপন করে। JWK এবং JWKS-এর বিবরণ RFC7517-এ দেওয়া আছে। JKWS-এর উদাহরণ পরিশিষ্ট 'ক'-তে দেখুন। JSON ওয়েব কী সেটের উদাহরণ

JWKS স্ট্রাকচার

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

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

ঐচ্ছিক এলিমেন্ট ও তার ভ্যালুর উদাহরণ নিচে দেওয়া হল:

  • alg - কী অ্যালগরিদম। এটি অবশ্যই JWS/JWT-এর সাইনিং অ্যালগরিদমের সাথে মিলতে হবে।
  • use - উপস্থিত থাকলে, অবশ্যই sig হতে হবে।

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

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

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

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

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

  1. কোনও নির্দিষ্ট ইস্যুকারীর জন্য সুপরিচিত এন্ডপয়েন্ট থেকে কী ও আইডির তালিকা রিট্রিভ করুন। এই ধাপের জন্য আপনি পরিষেবা কলআউট নীতি ব্যবহার করতে পারেন।
  2. 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-তে দাবি করা কী আইডির (kid) সাথে ম্যাচ করা কী আইডির কোনও কী JWKS-এ না পাওয়া গেলে, যাচাই JWT নীতি একটি সমস্যা দেখায় এবং JWT যাচাই করে না।
  • ইনবাউন্ড JWT-এর হেডার অংশে কোনও কী আইডি (kid) না থাকলে, তাহলে এই keyid-to-verification-key ম্যাপিং সম্ভব নয়।

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