সম্পর্কিত মূল অনুরোধের সাথে আপনার সাইট জুড়ে পাসকি পুনরায় ব্যবহারের অনুমতি দিন

Maud Nalpas

পাসকিগুলো একটি নির্দিষ্ট ওয়েবসাইটের সাথে সংযুক্ত থাকে এবং সেগুলো শুধুমাত্র সেই ওয়েবসাইটে সাইন ইন করার জন্যই ব্যবহার করা যায়, যেটির জন্য সেগুলো তৈরি করা হয়েছে।

এটি রিলায়িং পার্টি আইডি (RP ID)-তে নির্দিষ্ট করা থাকে, যা example.com ডোমেনের জন্য তৈরি করা পাসকিগুলোর ক্ষেত্রে www.example.com বা example.com হতে পারে।

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

• একাধিক ডোমেইনযুক্ত সাইট : ব্যবহারকারীরা একই কোম্পানির দ্বারা পরিচালিত বিভিন্ন দেশ-ভিত্তিক ডোমেইনে (যেমন example.com এবং example.co.uk ) সাইন ইন করার জন্য একই পাসকি ব্যবহার করতে পারবেন না।
• ব্র্যান্ডেড ডোমেইন : ব্যবহারকারীরা একই ব্র্যান্ডের ব্যবহৃত বিভিন্ন ডোমেইনে (যেমন acme.com এবং acmerewards.com ) একই ক্রেডেনশিয়াল ব্যবহার করতে পারবেন না।
• মোবাইল অ্যাপ : মোবাইল অ্যাপগুলোর প্রায়শই নিজস্ব ডোমেইন থাকে না, যার ফলে ক্রেডেনশিয়াল ম্যানেজমেন্ট বেশ কঠিন হয়ে পড়ে।

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

সমাধান

রিলেটেড অরিজিন রিকোয়েস্টের মাধ্যমে, একটি ওয়েবসাইট তার আরপি আইডি ব্যবহারের জন্য অনুমোদিত অরিজিনগুলো নির্দিষ্ট করে দিতে পারে।

এর ফলে ব্যবহারকারীরা আপনার পরিচালিত একাধিক সাইটে একই পাসকি পুনরায় ব্যবহার করতে পারেন।

রিলেটেড অরিজিন রিকোয়েস্ট ব্যবহার করতে, আপনাকে একটি নির্দিষ্ট URL https://{RP ID}/.well-known/webauthn এ একটি বিশেষ JSON ফাইল সার্ভ করতে হবে। যদি example.com অতিরিক্ত অরিজিনগুলোকে এটিকে RP ID হিসেবে ব্যবহার করার অনুমতি দিতে চায়, তবে এটিকে https://example.com/.well-known/webauthn:

{
  "origins": [
    "https://example.co.uk",
    "https://example.de",
    "https://example-rewards.com"
  ]
}

পরবর্তী সময়ে যখন এই সাইটগুলির কোনোটি example.com RP ID হিসেবে ব্যবহার করে পাসকি তৈরি ( navigator.credentials.create ) বা অথেনটিকেশনের ( navigator.credentials.get ) জন্য অনুরোধ করবে, তখন ব্রাউজারটি অনুরোধকারী অরিজিনের সাথে অমিল থাকা একটি RP ID লক্ষ্য করবে। যদি ব্রাউজারটি রিলেটেড অরিজিন রিকোয়েস্ট (Related Origin Requests) সমর্থন করে, তবে এটি প্রথমে https://{RP ID}/.well-known/webauthn ঠিকানায় একটি webauthn ফাইল খোঁজে। ফাইলটি বিদ্যমান থাকলে, ব্রাউজারটি পরীক্ষা করে দেখে যে অনুরোধকারী অরিজিনটি allowlist এ আছে কি না। যদি থাকে, তবে এটি পাসকি তৈরি বা অথেনটিকেশনের ধাপে এগিয়ে যায়।

যদি ব্রাউজারটি রিলেটেড অরিজিন রিকোয়েস্ট সমর্থন না করে, তাহলে এটি একটি SecurityError দেখায়।

ব্রাউজার সমর্থন

ক্রোম এবং সাফারিতে রিলেটেড অরিজিন রিকোয়েস্ট সমর্থিত। ২০২৬ সালের জানুয়ারি পর্যন্ত ফায়ারফক্স এই ফিচারটি চালুর বিষয়টি বিবেচনা করছে। আপনি মোজিলা স্ট্যান্ডার্ডস পজিশন ইস্যু- তে এর অবস্থা জানতে পারবেন।

সম্পর্কিত অরিজিন অনুরোধ সেট আপ করুন

নিম্নলিখিত ডেমোটিতে https://ror-1.glitch.me এবং https://ror-2.glitch.me এই দুটি সাইট ব্যবহার করা হয়েছে। ব্যবহারকারীরা যাতে উভয় সাইটে একই পাসকি দিয়ে সাইন ইন করতে পারেন, সেজন্য এটি রিলেটেড অরিজিন রিকোয়েস্ট (Related Origin Requests) ব্যবহার করে ror-2.glitch.me তার RP ID হিসেবে ror-1.glitch.me ব্যবহার করার অনুমতি দেয়।

ডেমো

https://ror-2.glitch.me, ror-1.glitch.me-কে একটি RP ID হিসেবে ব্যবহার করার জন্য ‘রিলেটেড অরিজিন রিকোয়েস্ট’ (Related Origin Requests) প্রয়োগ করে। ফলে, পাসকি তৈরি করার সময় বা এটি দিয়ে প্রমাণীকরণের সময় ror-1 এবং ror-2 উভয়ই ror- ror-1.glitch.me RP ID হিসেবে ব্যবহার করে। আমরা এই সাইটগুলোর জন্য একটি শেয়ার্ড পাসকি ডেটাবেসও তৈরি করেছি।

নিম্নলিখিত ব্যবহারকারীর অভিজ্ঞতা পর্যবেক্ষণ করুন:

• আপনি ror-2 তে সফলভাবে একটি পাসকি তৈরি করতে এবং এর মাধ্যমে প্রমাণীকরণ করতে পারবেন—যদিও এর RP ID হলো ror-1 ( ror-2 নয়)।
• একবার আপনি ror-1 বা ror-2 তে একটি পাসকি তৈরি করলে, আপনি সেটি দিয়ে ror-1 এবং ror-2 উভয় স্থানেই প্রমাণীকরণ করতে পারবেন। যেহেতু ror-2 ror-1 একটি RP ID হিসেবে নির্দিষ্ট করে, তাই এই সাইটগুলোর যেকোনো একটি থেকে পাসকি তৈরি বা প্রমাণীকরণের জন্য অনুরোধ করা, ror-1-এ অনুরোধ করার মতোই। RP ID-ই একমাত্র জিনিস যা একটি অনুরোধকে কোনো অরিজিনের সাথে সংযুক্ত করে।
• একবার আপনি ror-1 অথবা ror-2 তে একটি পাসকি তৈরি করলে, Chrome সেটি ror-1 এবং ror-2 উভয় জায়গাতেই স্বয়ংক্রিয়ভাবে পূরণ করে দেবে।
• এই সাইটগুলির যেকোনো একটিতে তৈরি করা ক্রেডেনশিয়ালের RP ID হবে ror-1 ।

কোডটি দেখুন:

• ror-1 কোডবেসে সেট আপ করা /.well-known/webauthn ফাইলটি দেখুন।
• ror-2 কোডবেসে RP_ID_ROR উপস্থিতিগুলো দেখুন।

ধাপ ১: একটি শেয়ার্ড অ্যাকাউন্ট ডেটাবেস বাস্তবায়ন করুন

আপনি যদি চান আপনার ব্যবহারকারীরা site-1 এবং site-2 উভয় স্থানেই একই পাসকি দিয়ে সাইন ইন করতে পারুক, তাহলে এমন একটি অ্যাকাউন্ট ডেটাবেস তৈরি করুন যা এই দুটি সাইটে শেয়ার করা হবে।

ধাপ ২: সাইট-১ এ আপনার .well-known/webauthn JSON ফাইলটি সেট আপ করুন।

প্রথমে, site-1.com এমনভাবে কনফিগার করুন যাতে site-2.com এটিকে একটি RP ID হিসেবে ব্যবহার করতে পারে। এটি করার জন্য, আপনার webauthn JSON ফাইলটি তৈরি করুন:

{
    "origins": [
        "https://site-2.com"
    ]
}

JSON অবজেক্টটিতে অবশ্যই 'origins' নামের একটি কী থাকতে হবে, যার ভ্যালু হবে এক বা একাধিক স্ট্রিং-এর একটি অ্যারে, যেগুলোতে ওয়েব অরিজিনগুলো থাকবে।

গুরুত্বপূর্ণ সীমাবদ্ধতা: সর্বোচ্চ ৫টি লেবেল

এই তালিকার প্রতিটি উপাদান থেকে eTLD + 1 লেবেলটি বের করার জন্য সেটিকে প্রসেস করা হবে। উদাহরণস্বরূপ, example.co.uk এবং example.de উভয়েরই eTLD + 1 লেবেল হলো example । কিন্তু example- example-rewards.com এর eTLD + 1 লেবেল হলো example-rewards । ক্রোমে, লেবেলের সর্বোচ্চ সংখ্যা হলো ৫।

ধাপ ৩: সাইট-১ এ আপনার .well-known/webauthn JSON পরিবেশন করুন।

এরপর, আপনার JSON ফাইলটি site-1.com/.well-known/webauthn ফোল্ডারে পরিবেশন করুন।

উদাহরণস্বরূপ, এক্সপ্রেসে:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

এখানে, আমরা express res.json ব্যবহার করছি, যা আগে থেকেই সঠিক content-type ( 'application/json' ) সেট করে রাখে;

ধাপ ৪: সাইট-২ এ আরপি আইডি উল্লেখ করুন

আপনার site-2 কোডবেসে, যেখানে যেখানে প্রয়োজন, সেখানে RP ID হিসেবে site-1.com সেট করুন:

• পরিচয়পত্র তৈরির পর:
  • navigator.credentials.create ফ্রন্টএন্ড কলে পাঠানো ক্রেডেনশিয়াল তৈরির options site-1.com RP ID হিসেবে সেট করুন, যা সাধারণত সার্ভার-সাইডে তৈরি হয়।
  • আপনার ডেটাবেসে সংরক্ষণ করার আগে ক্রেডেনশিয়াল ভেরিফিকেশন চালানোর সময়, site-1.com প্রত্যাশিত RP ID হিসেবে সেট করুন।
• প্রমাণীকরণের পর:
  • navigator.credentials.get ফ্রন্টএন্ড কলে পাঠানো অথেনটিকেশন options site-1.com RP ID হিসেবে সেট করুন, যা সাধারণত সার্ভার-সাইডে তৈরি হয়।
  • ব্যবহারকারীকে প্রমাণীকরণের আগে পরিচয়পত্র যাচাই করার সময়, সার্ভারে যাচাই করার জন্য প্রত্যাশিত RP ID হিসেবে site-1.com সেট করুন।

সমস্যা সমাধান

অন্যান্য বিবেচ্য বিষয়

বিভিন্ন সাইট এবং মোবাইল অ্যাপে পাসকি শেয়ার করুন

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

• ক্রোমে: ডিজিটাল অ্যাসেট লিঙ্ক । ডিজিটাল অ্যাসেট লিঙ্কের জন্য সমর্থন যোগ করুন -এ আরও জানুন।
• সাফারিতে: সংশ্লিষ্ট ডোমেইনসমূহ ।

বিভিন্ন সাইটে পাসওয়ার্ড শেয়ার করুন

সম্পর্কিত অরিজিন রিকোয়েস্ট আপনার ব্যবহারকারীদের বিভিন্ন সাইটে একটি পাসকি পুনরায় ব্যবহার করার সুযোগ দেয়। বিভিন্ন পাসওয়ার্ড ম্যানেজারের ক্ষেত্রে সাইটজুড়ে পাসওয়ার্ড শেয়ার করার সমাধান ভিন্ন ভিন্ন হয়ে থাকে। গুগল পাসওয়ার্ড ম্যানেজারের জন্য ডিজিটাল অ্যাসেট লিঙ্ক ব্যবহার করুন। সাফারির সিস্টেমটি ভিন্ন ।

ক্রেডেনশিয়াল ম্যানেজার এবং ইউজার এজেন্টের ভূমিকা

একজন সাইট ডেভেলপার হিসেবে এটি আপনার আওতার বাইরে, কিন্তু মনে রাখবেন যে দীর্ঘমেয়াদে, আপনার ব্যবহারকারীরা যে ইউজার এজেন্ট বা ক্রেডেনশিয়াল ম্যানেজার ব্যবহার করছেন, সেখানে RP ID ব্যবহারকারীর কাছে দৃশ্যমান কোনো বিষয় হওয়া উচিত নয়। এর পরিবর্তে, ইউজার এজেন্ট এবং ক্রেডেনশিয়াল ম্যানেজার ব্যবহারকারীদের দেখানো উচিত যে তাদের ক্রেডেনশিয়ালগুলো কোথায় ব্যবহার করা হয়েছে। এই পরিবর্তনটি বাস্তবায়ন করতে সময় লাগবে। একটি অস্থায়ী সমাধান হতে পারে বর্তমান ওয়েবসাইট এবং মূল রেজিস্ট্রেশন সাইট উভয়ই প্রদর্শন করা।