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

Maud Nalpas

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

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

যদিও RP আইডিগুলি সর্বত্র প্রমাণীকরণের জন্য পাসকিগুলিকে একক শংসাপত্র হিসাবে ব্যবহার করা থেকে বিরত রাখে, তারা নিম্নলিখিত সমস্যাগুলি তৈরি করে:

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

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

সমাধান

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

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

সম্পর্কিত অরিজিন অনুরোধ ব্যবহার করার জন্য, আপনাকে একটি নির্দিষ্ট 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"
  ]
}

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

যদি ব্রাউজারটি Related Origin Requests সমর্থন না করে, তাহলে এটি একটি SecurityError নিক্ষেপ করে।

ব্রাউজার সাপোর্ট

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

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

ডেমো

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

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

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

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

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

ধাপ ৩: সাইট-১-এ আপনার .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' ); সেট করে;

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

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

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

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

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

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

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

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

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

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

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

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