ক্রস-ডোমেইন লগইনগুলি ডিফ্র্যাগমেন্ট করুন

Eiji Kitamura

আধুনিক ব্যবসায়িক কাঠামো প্রায়শই একাধিক স্বতন্ত্র ডোমেন জুড়ে বিস্তৃত থাকে। প্রতিষ্ঠানগুলো বিভিন্ন বৈশিষ্ট্যের জন্য নির্দিষ্ট পরিবেশ বজায় রাখে—যেমন মার্কেটিং-এর জন্য brand.example , মূল পণ্যের জন্য service-app.example , এবং গ্রাহক সেবার জন্য support-portal.example । আদর্শগতভাবে, ব্যবহারকারীরা যখন এই প্রপার্টিগুলোর মধ্যে চলাচল করেন, তখন একটি সমন্বিত, একক সাইন-ইন অভিজ্ঞতা প্রদান করা উচিত। তবে, ইঞ্জিনিয়ারিং দলগুলো প্রায়শই অ্যাড-হক কৌশল ব্যবহার করে এই ডোমেনগুলোকে একীভূত করে, যা বিভাজন সৃষ্টি করে। এটি পাসওয়ার্ড ম্যানেজারের অটোফিল প্রবাহ ভেঙে দিয়ে এবং পাসকি ব্যবহারের প্রক্রিয়াকে বাধাগ্রস্ত করে বিল্ট-ইন ব্রাউজার ক্রেডেনশিয়াল ম্যানেজমেন্টকে ব্যাহত করে।

একাধিক ওয়েব প্রপার্টি জুড়ে ক্রস-ডোমেইন আইডেন্টিটি ফ্র্যাগমেন্টেশন।

যদি একই অ্যাকাউন্ট একাধিক ডোমেইনে ব্যবহৃত হয়, তবে ব্যবহারকারীকে অবশ্যই বুঝতে হবে যে ডোমেইনগুলো একই প্রতিষ্ঠানের অন্তর্গত এবং সাইন ইন করার সময় একই ক্রেডেনশিয়াল প্রদান করতে হবে। সবচেয়ে খারাপ পরিস্থিতিতে, ব্যবহারকারী একটি ডুপ্লিকেট অ্যাকাউন্ট তৈরি করে ফেলে অথবা কোনো ফিশিং ওয়েবসাইটে পাসওয়ার্ড দিয়ে দেয়।

ক্রস-ডোমেইন আইডেন্টিটি ফ্র্যাগমেন্টেশন সমাধান করতে এবং একটি নির্বিঘ্ন ইউজার জার্নি নিশ্চিত করতে আর্কিটেকচারাল স্ট্যান্ডার্ড ও সলিউশন (যেমন মেটাডেটা, ক্রস-অরিজিন আইফ্রেম, আইডেন্টিটি ফেডারেশন এবং সাবডোমেইন কনসলিডেশন) কীভাবে ব্যবহার করতে হয় তা শিখুন।

সাধারণ সমাধান

প্রতিষ্ঠানগুলো বিভিন্ন ডোমেনের মধ্যে সংযোগ বজায় রাখতে বেশ কিছু প্রচলিত কৌশল ব্যবহার করে। যদিও এই পদ্ধতিগুলো প্রচলিত, ব্রাউজারগুলো আরও কঠোর গোপনীয়তার সীমা ও নিরাপত্তা মান আরোপ করায় এগুলো কাঠামোগত বাধার সম্মুখীন হয়।

CORS অনুরোধগুলি আনুন

যখন ডোমেইনগুলো স্বাধীনভাবে কাজ করে, তখন ফ্রন্টএন্ডগুলো প্রায়শই একটি কেন্দ্রীভূত অথেনটিকেশন এপিআই-এর উদ্দেশ্যে পাঠানো ক্রস-অরিজিন fetch() রিকোয়েস্টের উপর নির্ভর করে, যা ক্রস-অরিজিন রিসোর্স শেয়ারিং (CORS) ব্যবহার করে নিরাপদে অনুমোদিত করা যায়। যেহেতু ব্রাউজারগুলো প্রায়শই ক্রস-সাইট কুকি ব্লক বা সীমাবদ্ধ করে, তাই ডেভেলপাররা Set-Cookie হেডারের উপর নির্ভর না করে, এই এপিআইগুলোকে JSON পেলোডের মধ্যে JSON ওয়েব টোকেন (JWT)-এর মতো অথেনটিকেশন টোকেন ফেরত দেওয়ার জন্য সুস্পষ্টভাবে ডিজাইন করতে পারেন।

অ্যাকাউন্ট ডেটাবেস শেয়ারিং

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

বিচ্ছিন্ন সাইন-ইন সংক্রান্ত সমস্যা

যদিও প্রযুক্তিগত বিকল্প ব্যবস্থাগুলো ন্যূনতম কার্যকারিতা নিশ্চিত করতে পারে, কিন্তু সেগুলো একটি নির্বিঘ্ন অভিজ্ঞতা দিতে ব্যর্থ হয়। অসংলগ্ন সাইন-ইন প্রক্রিয়া এমন প্রতিবন্ধকতা তৈরি করে যা ব্যবহারযোগ্যতা এবং নিরাপত্তা উভয়কেই বিঘ্নিত করে।

পাসওয়ার্ড ম্যানেজার খণ্ডন

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

যখন কোনো ব্যবহারকারী সংরক্ষিত ক্রেডেনশিয়ালসহ একটি ডোমেইন থেকে আপনার প্রতিষ্ঠানের একটি নতুন ডোমেইনে স্থানান্তরিত হন, তখন পাসওয়ার্ড ম্যানেজার এই সম্পর্কটি শনাক্ত করতে ব্যর্থ হয় এবং অটোফিল প্রম্পটটি চালু করে না। এর ফলে ম্যানুয়ালি পাসওয়ার্ড এন্ট্রি করার ক্ষেত্রে অসুবিধা তৈরি হয়। ব্যবহারকারীদের হয় তাদের ক্রেডেনশিয়াল খুঁজে বের করতে হয়, পাসওয়ার্ড রিসেট করতে হয়, অথবা একটি ডুপ্লিকেট অ্যাকাউন্ট তৈরি করতে হয়।

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

ফিশিং গেটওয়ে

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

পাসকি রোডব্লক

পাসকি ব্যবহার করলে জটিলতা বাড়ে। WebAuthn-এর মূল নিরাপত্তা কাঠামো ক্রিপ্টোগ্রাফিকভাবে পাসকিগুলোকে একটি নির্দিষ্ট রিলায়িং পার্টি আইডি (RP ID)- এর সাথে কঠোরভাবে সংযুক্ত করে।

এর ফলে একটি "আরপি আইডি ট্র্যাপ" তৈরি হয়। brand.example এ রেজিস্টার করা একটি পাসকি service-app.example এ ব্যবহার করা যায় না, কারণ ব্রাউজার ক্রস-ডোমেইন অ্যাক্সেস প্রত্যাখ্যান করে। ব্যবহারকারীদের প্রতিটি সাইটের জন্য আলাদা পাসকি রেজিস্টার করতে বলার ঝামেলা এড়াতে, আপনাকে অবশ্যই এই প্রোপার্টিগুলোকে একটিমাত্র আরপি আইডিতে একীভূত করতে হবে।

সুপারিশকৃত পদ্ধতি

পরিচয়ের ধারাবাহিকতা প্রতিষ্ঠা করতে, আপনাকে অ্যাড-হক সাইন-ইন ইন্টিগ্রেশন থেকে সরে এসে স্বীকৃত আর্কিটেকচারাল স্ট্যান্ডার্ড গ্রহণ করতে হবে:

• মেটাডেটা কনফিগারেশন ফাইল ব্যবহার করুন : একটি ক্রিপ্টোগ্রাফিক ট্রাস্ট চেইন স্থাপন করতে ডিজিটাল অ্যাসেট লিঙ্ক এবং রিলেটেড অরিজিন রিকোয়েস্টের মতো মেটাডেটা ফাইল হোস্ট করুন। এটি বিভিন্ন ডোমেইন এবং মোবাইল অ্যাপ জুড়ে নির্বিঘ্নে ক্রেডেনশিয়াল এবং পাসকি শেয়ার করতে সক্ষম করে। এই পদ্ধতিটি আইডেন্টিটি ফ্র্যাগমেন্টেশনের জন্য একটি স্বল্প-ব্যয়ী ও নীরব সমাধান, যার জন্য বিদ্যমান ওয়েব পরিকাঠামোর কোনো জটিল পুনর্গঠনের প্রয়োজন হয় না।
• ক্রস-অরিজিন আইফ্রেম ব্যবহার করুন : বিভিন্ন সাইটের মধ্যে সংরক্ষিত ক্রেডেনশিয়াল এবং পাসকি সংযোগ স্থাপন করতে একটি রিলায়িং পার্টির মধ্যে একটি কেন্দ্রীভূত প্রমাণীকরণ অরিজিনকে আইফ্রেম হিসেবে এম্বেড করুন। এই পদ্ধতিটি পারমিশন পলিসি এবং পার্টিশনড কুকিজ ব্যবহার করে একটি নির্বিঘ্ন, প্রাসঙ্গিক সাইন-ইন অভিজ্ঞতা প্রদান করে এবং একই সাথে CSP ও ক্রস-ডকুমেন্ট মেসেজিংয়ের মাধ্যমে কঠোর নিরাপত্তা সীমা বজায় রাখে।
• স্ট্যান্ডার্ড আইডেন্টিটি ফেডারেশন অনুসরণ করুন : একটি ডেডিকেটেড আইডেন্টিটি প্রোভাইডার (IdP) ডোমেনে অথেনটিকেশন কেন্দ্রীভূত করতে OpenID Connect-এর মতো ইন্ডাস্ট্রি-স্ট্যান্ডার্ড প্রোটোকল গ্রহণ করুন। এটি সুরক্ষিত রিডাইরেক্টের মাধ্যমে লগইন প্রক্রিয়াকে আনুষ্ঠানিক রূপ দেয় এবং ভঙ্গুর ইন্টিগ্রেশনকে একটি নির্ভরযোগ্য ও স্কেলেবল ফার্স্ট-পার্টি সলিউশন দ্বারা প্রতিস্থাপন করে।
• সাবডোমেইন একীভূত করুন : সাবডোমেইনগুলোকে একটি সাধারণ রুটের অধীনে নিয়ে আসুন। এর ফলে ওয়াইল্ডকার্ড কুকির মাধ্যমে নির্বিঘ্ন সেশন শেয়ারিং এবং সম্পূর্ণ রেজিস্টারযোগ্য ডোমেইন জুড়ে পাসকির ধারাবাহিকতা বজায় থাকে। অনেক পাসওয়ার্ড ম্যানেজার এই শেয়ার করা রুট ডোমেইনটি শনাক্ত করতে পারে এবং সম্পর্কিত সাবডোমেইনগুলোতে স্বয়ংক্রিয়ভাবে সংরক্ষিত ক্রেডেনশিয়াল ব্যবহারের পরামর্শ দেয়।

মেটাডেটা কনফিগারেশন ফাইল ব্যবহার করুন

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

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

বিভিন্ন প্ল্যাটফর্ম ও ইকোসিস্টেম অন্তর্ভুক্ত করতে দুটি ভিন্ন কনফিগারেশন ফাইল ব্যবহার করুন:

• অ্যান্ড্রয়েড এবং ক্রোমে গুগল পাসওয়ার্ড ম্যানেজার : কোনো প্রতিষ্ঠানের সংশ্লিষ্ট অ্যাপ এবং ওয়েবসাইটগুলির মধ্যে একটি যাচাইযোগ্য বিশ্বস্ত সম্পর্ক স্থাপন করতে /.well-known/assetlinks.json এ একটি ডিজিটাল অ্যাসেট লিঙ্কস (DAL) JSON ফাইল হোস্ট করুন। এই বিশ্বস্ততা অ্যাপগুলিতে ডিপ লিঙ্ক এবং সিমলেস ক্রেডেনশিয়াল শেয়ারিং সক্ষম করে, যেখানে ওয়েবে সংরক্ষিত পাসওয়ার্ডগুলি স্বয়ংক্রিয়ভাবে সংশ্লিষ্ট ওয়েবসাইটগুলি অটোফিল করে (যদিও একাধিক ওয়েব ডোমেনের মধ্যে পাসকি শেয়ার করার জন্য এখনও রিলেটেড অরিজিন রিকোয়েস্টের প্রয়োজন হয়)। সিমলেস ক্রেডেনশিয়াল শেয়ারিং গাইডে আরও জানুন।

• iOS এবং Safari-তে Apple Passwords : iOS অ্যাপ এবং Safari জুড়ে Apple Passwords-এর অবস্থাগুলোর মধ্যে সংযোগ স্থাপনের জন্য প্রয়োজনীয় ক্রিপ্টোগ্রাফিক ট্রাস্ট চেইন প্রতিষ্ঠা করতে /.well-known/apple-app-site-association এ একটি Apple App Site Association (AASA) ফাইল হোস্ট করুন। থার্ড-পার্টি ইকোসিস্টেম সমর্থন করার জন্য, আপনি একটি ক্রাউডসোর্সড রিপোজিটরি ব্যবহার করে কেন্দ্রীয়ভাবে এই অ্যাসোসিয়েটেড ডোমেইনগুলো ঘোষণা করতে পারেন। এটি নিশ্চিত করে যে স্বাধীন টুলগুলোও (যেমন 1Password, যা স্পষ্টভাবে এই রিপোজিটরিটি গ্রহণ করে) শেয়ার করা আইডেন্টিটি কনটেক্সটকে চিনতে পারে। Apple App Site Association সম্পর্কে আরও জানতে, Supporting associated domains পড়ুন।

বিভিন্ন ওয়েব ডোমেনে পাসকি সক্রিয় করতে এবং পাসকি সংক্রান্ত প্রতিবন্ধকতা দূর করতে, ডেভেলপাররা /.well-known/webauthn এ একটি রিলেটেড অরিজিন রিকোয়েস্টস (ROR) ফাইল হোস্ট করতে পারেন। ROR স্পষ্টভাবে সেইসব অনুমোদিত ডোমেনকে ঘোষণা করে, যাদের একই পাসকি RP ID নিরাপদে শেয়ার করার অনুমতি রয়েছে। রিলেটেড অরিজিন রিকোয়েস্টস সম্পর্কে আরও জানতে, “রিলেটেড অরিজিন রিকোয়েস্টস-এর মাধ্যমে আপনার সাইট জুড়ে পাসকি পুনঃব্যবহারের অনুমতি দিন” পড়ুন।

• সুবিধা:
  • ব্যবহারকারীদের জন্য ব্যাকগ্রাউন্ড সমাধান: এটি সম্পূর্ণরূপে ব্যাকগ্রাউন্ডে কাজ করে, যা ইউজার এক্সপেরিয়েন্সে (UX) কোনো দৃশ্যমান পরিবর্তন ছাড়াই স্বয়ংক্রিয়ভাবে অটোফিল ফ্র্যাগমেন্টেশন সমাধান করে এবং অপারেটিং সিস্টেম বা ব্রাউজার পর্যায়ে পাসকি-র ধারাবাহিকতা স্থাপন করে।
  • সহজ বাস্তবায়ন: এটি একটি স্বল্প খরচের সমাধান, যার জন্য শুধুমাত্র স্ট্যাটিক JSON ফাইল হোস্ট করার প্রয়োজন হয়। এর জন্য ব্যাকএন্ডের পুনর্গঠন বা জটিল টোকেন বিনিময় লজিকের প্রয়োজন হয় না।
  • বিদ্যমান পরিকাঠামো অক্ষুণ্ণ রাখে: আপনি আপনার ব্র্যান্ড পরিবর্তন না করে বা ডোমেইনগুলোকে একত্রিত না করেই ক্রস-ডোমেইন অভিজ্ঞতাকে উল্লেখযোগ্যভাবে উন্নত করতে পারেন।
• অসুবিধা:
  • প্ল্যাটফর্মের সীমাবদ্ধতা: প্ল্যাটফর্মগুলো সাধারণত ROR-এর উপর কঠোর সীমা আরোপ করে। উদাহরণস্বরূপ, Chrome একটি একক RP ID-কে সর্বোচ্চ ৫টি সংশ্লিষ্ট eTLD+1 লেবেলের মধ্যে সীমাবদ্ধ রাখে। যেমন, example.co.uk এবং example.de একই example eTLD+1 লেবেল ব্যবহার করে; কিন্তু example-rewards.com একটি আলাদা example-rewards লেবেল ব্যবহার করে। আপনি যদি একটি বিস্তৃত বা বৈচিত্র্যময় ডোমেইন পোর্টফোলিও পরিচালনা করেন, তবে এই সীমাগুলো অপর্যাপ্ত হতে পারে।
  • বর্ধিত অপারেশনাল ল্যাটেন্সি: মেটাডেটা ফাইল রিজলভ করার জন্য একটি অতিরিক্ত নেটওয়ার্ক রাউন্ডট্রিপের প্রয়োজন হয়, যা ব্রাউজার কর্তৃক অথেনটিকেশন প্রক্রিয়াকরণের সময় ল্যাটেন্সি বাড়িয়ে দেয়।

ক্রেডেনশিয়াল শেয়ারিং সক্ষম করতে মেটাডেটা কনফিগারেশন ফাইল ব্যবহার করা।

ক্রস-অরিজিন আইফ্রেম ব্যবহার করুন

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

একটি রিলায়িং পার্টির (যেমন, brand.example ) মধ্যে একটি আইফ্রেম হিসেবে একটি কেন্দ্রীভূত প্রমাণীকরণ উৎস (যেমন, auth.brand.example ) এম্বেড করার মাধ্যমে, আপনি সাধারণ ফর্ম ফিল্ড এবং আধুনিক এপিআই উভয়ের সাথেই ইন্টারঅ্যাক্ট করতে পারেন। পাসওয়ার্ডের ক্ষেত্রে, ব্রাউজারের ক্রেডেনশিয়াল ম্যানেজার আইফ্রেমের উৎসের ( auth.example ) সাথে অটোফিল অ্যাকশনগুলোকে যুক্ত করে। এর ফলে ব্যবহারকারীরা বিভিন্ন সাইট জুড়ে নির্বিঘ্নে তাদের কেন্দ্রীভূত ক্রেডেনশিয়াল অ্যাক্সেস করতে পারেন।

পাসকি-এর জন্য, প্যারেন্ট উইন্ডোকে অবশ্যই পারমিশন পলিসি ফ্রেমওয়ার্ক ব্যবহার করে আইফ্রেমটিকে অ্যাক্সেস দিতে হবে, যা আইফ্রেমটিকে তার নিজস্ব অরিজিনের আরপি আইডি (RP ID)-র বিপরীতে প্রমাণীকরণের জন্য ওয়েবঅথন (WebAuthn) ব্যবহার করতে সক্ষম করে। উভয় ফ্লোতেই, ব্যবহারকারীদের ক্লিকজ্যাকিং এবং ক্রস-সাইট স্ক্রিপ্টিং-এর মতো আক্রমণ থেকে রক্ষা করার জন্য সিএসপি (কন্টেন্ট সিকিউরিটি পলিসি) কার্যকর। প্রমাণীকরণ সফল হলে, একটি পার্টিশনড কুকির মাধ্যমে সেশনটি প্রতিষ্ঠিত হয় এবং postMessage() ব্যবহার করে টোকেনটি নিরাপদে প্যারেন্ট উইন্ডোতে ফেরত পাঠানো হয়।

• সুবিধা:
  • কেন্দ্রীভূত ক্রেডেনশিয়াল: ক্রেডেনশিয়াল ফ্র্যাগমেন্টেশন এড়িয়ে চলে। একটি একক, কেন্দ্রীভূত অরিজিন সংরক্ষিত পাসওয়ার্ড এবং একটি সমন্বিত পাসকি আরপি আইডি উভয়ই পরিচালনা করে, যা স্বতন্ত্র ডোমেইনগুলোকে ডোমেইন একীভূত করার প্রয়োজন ছাড়াই এই ক্রেডেনশিয়ালগুলো শেয়ার করার সুযোগ দেয়।
  • প্রাসঙ্গিক প্রমাণীকরণ: সম্পূর্ণ সাইন-ইন প্রক্রিয়াটি—তা পাসওয়ার্ড স্বয়ংক্রিয়ভাবে পূরণ করা হোক বা পাসকি দিয়ে যাচাইকরণ হোক—মূল পৃষ্ঠার মধ্যেই নির্বিঘ্নে ও প্রাসঙ্গিকভাবে সম্পন্ন হয়, যা বিঘ্ন সৃষ্টিকারী ফেডারেটেড রিডাইরেক্ট এড়িয়ে চলে।
  • ট্র্যাকিং সুরক্ষা ব্যবস্থার প্রতিরোধ ক্ষমতা: এই পদ্ধতিটি পার্টিশন করা কুকি ব্যবহার করে কঠোর ক্রস-সাইট ট্র্যাকিং সুরক্ষা ব্যবস্থার অধীনেও সঠিকভাবে কাজ করে।
• অসুবিধা:
  • বাস্তবায়নের সীমাবদ্ধতা: এই আর্কিটেকচারের জন্য বিশেষায়িত ইঞ্জিনিয়ারিং প্রয়োজন। বিশ্বস্ত প্যারেন্ট ডোমেইনে এমবেডিং সীমাবদ্ধ করতে এবং ক্লিকজ্যাকিং প্রতিরোধ করতে এর জন্য কঠোর CSP ( frame-ancestors ), WebAuthn API সক্রিয় করার জন্য HTTP পারমিশন পলিসি কনফিগারেশন, এবং অরিজিন-স্পুফিং ও CSRF আক্রমণ প্রশমিত করার জন্য সুরক্ষিত, যাচাইকৃত ক্রস-ডকুমেন্ট মেসেজিং ( postMessage() ) প্রয়োজন। iframe-এর মধ্যে পাসকি (Passkeys ) থেকে সেরা অনুশীলনগুলো জানুন।

ক্রস-অরিজিন আইফ্রেম প্রমাণীকরণ প্রবাহ।

স্ট্যান্ডার্ড পরিচয় ফেডারেশন অনুসরণ করুন

আপনার অ্যাকাউন্ট সিস্টেম রক্ষণাবেক্ষণের জন্য ওপেনআইডি কানেক্ট (OpenID Connect)-এর মতো স্ট্যান্ডার্ড আইডেন্টিটি ফেডারেশন গ্রহণ করা একটি শক্তিশালী এবং টেকসই পদ্ধতি। এই পদ্ধতিটি প্রমাণীকরণ প্রক্রিয়াকে একটি একক, নির্দিষ্ট আইডেন্টিটি প্রোভাইডার (IdP) ডোমেইনে, যেমন auth.brand.example , একীভূত করে আনুষ্ঠানিক রূপ দেয়। একটি প্রতিষ্ঠিত প্রোটোকলের মাধ্যমে, অ্যাপ্লিকেশনগুলো ব্যবহারকারীদের প্রমাণীকরণের জন্য এই কেন্দ্রীয় হাবে পাঠায় এবং এরপর টার্গেট ডোমেইনে লগইন সম্পন্ন করার জন্য নিরাপদে একটি টোকেন গ্রহণ করে। যদিও এটি প্রায়শই থার্ড-পার্টি লগইনের (যেমন সাইন-ইন উইথ গুগল ) সাথে যুক্ত, স্ট্যান্ডার্ড ফেডারেশন ভঙ্গুর বিকল্প সমাধানগুলোকে প্রতিস্থাপন করার জন্য একটি ফার্স্ট-পার্টি সমাধান হিসেবে সম্পূর্ণ বৈধ এবং ব্যাপকভাবে ব্যবহৃত হয়।

• সুবিধা:
  • সাধারণ ইঞ্জিনিয়ারিং ভাষা: ডেভেলপারদের কোনো নির্দিষ্ট, বিশেষভাবে তৈরি প্রোটোকল শিখতে বা রক্ষণাবেক্ষণ করতে হয় না; তারা প্রতিষ্ঠিত শিল্প জ্ঞান এবং ব্যাপক লাইব্রেরির উপর নির্ভর করতে পারেন। প্যাকেজড সমাধানও রয়েছে।
  • পরীক্ষিত নির্ভরযোগ্যতা: প্রমিত প্রোটোকলগুলো প্রমাণিত, নিরাপদ এবং তাৎক্ষণিক বাস্তবায়নের তুলনায় অনেক কম ভঙ্গুর।
  • সহজে সম্প্রসারণযোগ্য: যদি প্রতিষ্ঠানটিকে পরবর্তীতে কোনো নতুন তৃতীয়-পক্ষ পরিষেবার সাথে সংযুক্ত হতে বা কোনো অধিগ্রহণকে একীভূত করতে হয়, তবে পরিচয় পরিকাঠামোটি ক্রেডেনশিয়াল সরবরাহ করার জন্য আগে থেকেই প্রস্তুত থাকে।
  • সামঞ্জস্যপূর্ণ ইউএক্স: ব্যবহারকারীরা কেন্দ্রীভূত IdP পেজটিকে ব্র্যান্ডের জন্য প্রামাণিক উৎস হিসেবে স্বীকৃতি দেয়, যা কখন এবং কোথায় ক্রেডেনশিয়াল প্রয়োজন তা স্পষ্টভাবে জানিয়ে দেয়।
• অসুবিধা:
  • উচ্চ ইন্টিগ্রেশন ওভারহেড: একটি কেন্দ্রীভূত IdP তৈরি করা বা তাতে স্থানান্তরিত হওয়ার ফলে উচ্চ ইন্টিগ্রেশন ওভারহেড তৈরি হয় এবং এর জন্য বিশেষায়িত নিরাপত্তা দক্ষতার প্রয়োজন হয়। নিরাপদ রিডাইরেক্ট-ভিত্তিক প্যাটার্ন সমর্থন করার জন্য সংস্থাগুলিকে অবশ্যই সমস্ত সংযুক্ত অ্যাপ্লিকেশন নিরাপদে রিফ্যাক্টর করার জন্য বিনিয়োগ করতে হবে।
  • বিঘ্ন সৃষ্টিকারী পুনঃনির্দেশ: প্রমাণীকরণ প্রক্রিয়ার জন্য ব্যবহারকারীদের মূল সাইট থেকে একটি কেন্দ্রীভূত আইডেন্টিটি প্রোভাইডার পৃষ্ঠায় পুনঃনির্দেশিত করতে হয়, যা একটি নির্বিঘ্ন ও প্রাসঙ্গিক সাইন-ইন অভিজ্ঞতাকে বাধাগ্রস্ত করে।

প্রমিত পরিচয় ফেডারেশন প্রবাহ।

উপ-ডোমেনগুলিকে একত্রিত করুন

আরেকটি কাঠামোগত পদ্ধতি হলো বিভিন্ন ডিজিটাল সম্পত্তিকে একটি সাধারণ নিবন্ধনযোগ্য রুট ডোমেইনের (eTLD+1) অধীনে এনে সমস্ত ডোমেইনকে একীভূত করা। এর জন্য brand.example এবং service-app.example এর মতো পৃথক ডোমেইনগুলোকে www.brand.example এবং service.brand.example এর মতো সাবডোমেইনে রূপান্তরিত করতে হয়।

• সুবিধা:
  • সমন্বিত ক্রেডেনশিয়াল ব্যবস্থাপনা: পাসওয়ার্ড ম্যানেজারগুলো রুট ডোমেইনকে শনাক্ত করতে পারে এবং সমস্ত সাবডোমেইনকে একটি একক এন্ট্রি হিসেবে গণ্য করে, যার ফলে পাসওয়ার্ডের জন্য বারবার প্রম্পট আসা এবং হাতে লিখে প্রবেশ করানোর প্রয়োজন হয় না।
  • পাসকি ধারাবাহিকতা: ডেভেলপাররা রেজিস্টারযোগ্য ডোমেইনে একটি পাসকি আরপি আইডিকে নেটিভভাবে স্কোপ করতে পারেন, যার ফলে তাৎক্ষণিকভাবে সমস্ত সংশ্লিষ্ট সাবডোমেইনে পাসকি সাপোর্ট প্রসারিত হয়। এই ক্ষেত্রে, brand.example এর একটি আরপি আইডি www.brand.example এবং service.brand.example উভয় ক্ষেত্রেই কাজ করবে।
  • অনায়াস সেশন শেয়ারিং: ডোমেইন কাঠামোকে একীভূত করার মাধ্যমে ওয়াইল্ডকার্ড কুকি ব্যবহার করে একটি একক সেশন শেয়ার করা সম্ভব হয় (উদাহরণস্বরূপ, একটি কুকিকে Domain=brand.example এর আওতায় আনা)।
• অসুবিধা:
  • ব্র্যান্ডিং এবং মাইগ্রেশন সংক্রান্ত সীমাবদ্ধতা: আপনার সংস্থা যদি স্বতন্ত্র টপ-লেভেল ডোমেইন বাধ্যতামূলক করে, তবে এই পদ্ধতিটি সম্ভাব্য ব্র্যান্ডিং সীমাবদ্ধতা তৈরি করতে পারে। এই মাইগ্রেশন প্রক্রিয়াটি জটিল এবং এর জন্য HTTP রিডাইরেক্টের সতর্ক ব্যবস্থাপনা এবং পুরোনো ক্রস-অরিজিন কনফিগারেশনগুলোর ব্যাপক সংশোধন প্রয়োজন।

একটি সাধারণ মূলের অধীনে উপ-ডোমেনগুলিকে একত্রিত করা।

উপসংহার

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

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