স্বাধীন রুট ডোমেইনজুড়ে ক্রস-ডোমেইন SSO কীভাবে তৈরি করবেন

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

গুরুত্বপূর্ণ সীমাবদ্ধতা ছিল—এগুলো স্বাধীন রুট ডোমেইন। একটি রুট ডোমেইন তৈরি করা সেশন কুকিকে সরাসরি কোনো সম্পর্কহীন রুট ডোমেইনের জন্য প্রযোজ্য করা যায় না। সাধারণত একসঙ্গে মিশিয়ে ফেলা হয় এমন দুটি ধারণা আলাদা করার পর ডিজাইনটি বোঝা অনেক সহজ হলো: বৈশ্বিক পরিচয় এবং স্থানীয় ব্রাউজার সেশন।

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

বৈশ্বিক পরিচয়ের জন্য শেয়ার করা কুকি দরকার নেই

ব্রাউজার সেশন স্থানীয় হলেও অ্যাকাউন্ট বৈশ্বিক হতে পারে।

প্রতিটি সাইট একটি হোস্ট-অনলি সেশন কুকি রাখে। একটি রুট ডোমেইন থেকে ইস্যু করা কুকিকে Domain অ্যাট্রিবিউট ব্যবহার করে সম্পর্কহীন অন্য রুট ডোমেইনে বিস্তৃত করা যায় না। ইস্যুকারী হোস্ট যে ডোমেইন হায়ারার্কি ব্যবহারের অনুমতি পায়, ওই অ্যাট্রিবিউট কুকির পরিসর কেবল সেই হায়ারার্কির মধ্যেই বাড়াতে পারে।

যে সেশনকে একটি হোস্টেই আবদ্ধ রাখতে হবে, তার জন্য __Host- প্রিফিক্সযুক্ত কুকি উপযোগী। ধারণাগতভাবে:

Set-Cookie: __Host-<session-cookie>=<opaque-token>; Path=/; Secure; HttpOnly; SameSite=Lax

এখানে সবচেয়ে গুরুত্বপূর্ণ বৈশিষ্ট্য হলো সীমারেখাগুলো:

• Site A, Site B-এর হোস্ট-অনলি সেশন কুকি পড়তে পারে না।
• Site B, Site A-এর হোস্ট-অনলি সেশন কুকি পড়তে পারে না।
• তবুও উভয় সেশন একই ব্যাকএন্ড পরিচয়ে রিজলভ হতে পারে।

তাই ক্রস-ডোমেইন SSO-তে একটি সাইট থেকে অন্য সাইটে কুকি সরানোর চেষ্টা করা উচিত নয়। বরং একটি বিশ্বস্ত উৎস যে ব্যবহারকারীকে ইতিমধ্যে প্রমাণীকরণ করেছে, তার সাময়িক প্রমাণ স্থানান্তর করা উচিত।

একবার-ব্যবহারযোগ্য হ্যান্ডঅফ প্যাটার্ন

প্রমাণীকৃত উৎস একটি ছোট হ্যান্ডঅফ অপারেশন উন্মুক্ত করে। ক্রস-সাইট প্রমাণীকরণ ট্রানজিশন দরকার হলেই কেবল ব্রাউজার সেটি কল করে।

ব্যাকএন্ড ক্রিপ্টোগ্রাফিকভাবে র্যান্ডম একটি টিকিট তৈরি করে, কাঁচা মানটি একবার ব্রাউজারে ফেরত দেয়, এবং ট্রান্সফার যাচাই করতে ন্যূনতম যে তথ্য দরকার তার সঙ্গে শুধু একটি হ্যাশ সংরক্ষণ করে:

{
  tokenHash,
  userId,
  sourceOrigin,
  targetSite,
  returnPath,
  expiresAt
}

টিকিটের আয়ু স্বল্প হওয়া উচিত এবং এটি কেবল একটি টার্গেটের জন্য বৈধ হওয়া উচিত। উৎস-পক্ষের ইস্যু রিকোয়েস্ট আগে থেকেই প্রমাণীকৃত এবং CSRF থেকে সুরক্ষিত হওয়া উচিত। কিছু ইস্যু করার আগেই চাওয়া টার্গেট ও ফেরার গন্তব্য যাচাই করা উচিত।

এরপর ব্রাউজার টার্গেটে একটি টপ-লেভেল POST করে। টার্গেট টিকিটটি ব্যবহার করে, শেয়ার করা ব্যবহারকারী পরিচয় রিজলভ করে, নিজের স্থানীয় সেশন তৈরি করে, এবং ব্রাউজারকে নির্ধারিত পাথে রিডাইরেক্ট করে।

ধারণাগতভাবে:

record = consumeOnce({
  tokenHash: hash(ticket),
  targetSite: currentSite,
  sourceOrigin: requestOrigin,
  notExpired: true
})

if (!record) deny()

user = loadSharedUser(record.userId)
createLocalSession(user)
redirect(record.returnPath)

টিকিটটি টার্গেট সেশন নয়। এটি ওই টার্গেট সেশন একবার তৈরি করার অনুমোদন।

অ্যাটমিক কনজাম্পশন রিপ্লে উইন্ডো বন্ধ করে

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

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

এতে টার্গেট একই অপারেশনের সঙ্গে একাধিক শর্তও বেঁধে দিতে পারে: প্রত্যাশিত টার্গেট, প্রত্যাশিত উৎস অরিজিন, টোকেন হ্যাশ এবং মেয়াদ।

অরিজিন যাচাই ফেইল-ক্লোজড হওয়া উচিত

অরিজিন বাইন্ডিং আরেকটি উপকারী বৈশিষ্ট্য যোগ করে: একটি বিশ্বস্ত উৎস দিয়ে ইস্যু করা টিকিট যেন সম্পর্কহীন কোনো অরিজিন থেকে ব্যবহার করা না যায়।

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

এখানে একটি গুরুত্বপূর্ণ সতর্কতা আছে: প্রতিটি ব্রাউজার কনটেক্সটে Origin হেডারে স্বাভাবিক অরিজিন স্ট্রিং থাকবে—এমন নিশ্চয়তা নেই। কিছু রিকোয়েস্ট ব্যবহারযোগ্য মান ছাড়াই আসতে পারে, আর অস্বচ্ছ কনটেক্সট Origin: null তৈরি করতে পারে।

আমার নিয়ম হলো, অ্যাপ্লিকেশনে স্পষ্ট বিকল্প যাচাই ব্যবস্থা না থাকলে অনুপস্থিত বা অস্বচ্ছ Origin-কে ব্যর্থ অরিজিন পরীক্ষা হিসেবে ধরা। শুধু সামঞ্জস্যের জন্য আক্ষরিক null মানকে বিশ্বস্ত অরিজিন বানানো উচিত নয়।

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

হ্যান্ডঅফ ক্রেডেনশিয়াল URL-এর বাইরে রাখুন

সাময়িক টিকিটটি কোয়েরি স্ট্রিংয়ে রাখার বদলে টপ-লেভেল ফর্ম POST-এ পাঠাতেই আমি পছন্দ করি।

একটি সাধারণীকৃত ক্লায়েন্ট-সাইড সংস্করণ হলো:

const form = document.createElement('form');
form.method = 'POST';
form.action = targetOrigin + '/auth/consume';

const input = document.createElement('input');
input.type = 'hidden';
input.name = 'ticket';
input.value = ticket;

form.append(input);
document.body.append(form);
form.submit();

টার্গেট প্রত্যাশিত POST বডি থেকে টিকিট গ্রহণ করে এবং URL-এর মাধ্যমে একই জিনিস দেওয়ার সমতুল্য চেষ্টা প্রত্যাখ্যান করে।

এতে ক্রেডেনশিয়ালটি ক্ষতিহীন হয়ে যায় না, তবে এটি সাধারণ নেভিগেশন URL-এর বাইরে থাকে এবং URL হিস্ট্রি, কপি করা লিংক, রেফারার ও URL-কেন্দ্রিক লগিংয়ের মাধ্যমে দুর্ঘটনাজনিত প্রকাশের ঝুঁকি কমে।

প্রমাণীকৃত ক্রস-সাইট লিংক নিজে থেকেই হ্যান্ডঅফ ব্যবহার করতে পারে

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

লিংকে তবুও একটি বাস্তব href থাকা উচিত। SSO স্বাভাবিক নেভিগেশনের উন্নতি, তার বিকল্প নয়।

সংক্ষিপ্ত ক্লায়েন্ট ফ্লোটি এমন:

if (session.status !== 'authenticated') {
  return; // ordinary browser navigation
}

if (!isTrustedTarget(destination)) {
  return;
}

event.preventDefault();

const ticket = await requestHandoff({
  targetSite,
  returnPath: destinationPath
});

postTicketToTarget(ticket);

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

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

দ্বিতীয় সাইটের লগইন বাটনের জন্য পরিচিত ইস্যুকারী দরকার

কঠিন কেসটি শুরু হয় যখন ব্যবহারকারী সরাসরি Site B খোলে। Site B-তে কোনো স্থানীয় সেশন নেই, তাই ব্রাউজারে Site A-এর বৈধ সেশন এখনও থাকলেও এটি যথার্থভাবেই ভিজিটরকে অপ্রমাণীকৃত হিসেবে ধরে।

Site B, Site A-এর হোস্ট-অনলি কুকি পরীক্ষা করতে পারে না। আবার এটি ইচ্ছামতো Site C-তে রিডাইরেক্ট করে আশা করতে পারে না যে সেই সাইট সিস্টেমের বাকি অংশের সেশন খুঁজে পাবে। সম্পর্কহীন প্রতিটি রুট ডোমেইন কেবল তার নিজের কুকিগুলোই দেখতে পারে।

এর মানে অপ্রমাণীকৃত লগইন ফ্লোর জন্য একটি পরিচিত ইস্যুকারী দরকার: হয় একটি ক্যানোনিক্যাল প্রমাণীকরণ অরিজিন, নয়তো বিশেষভাবে নির্বাচিত এমন বিশ্বস্ত সাইট, যেখানে পুনর্ব্যবহারযোগ্য লগইন সেশন থাকার কথা।

সহজ Site A → Site B কেসে ক্রমটি হলো:

1. ব্যবহারকারী Site A-তে সাইন ইন করে।
2. পরে ব্যবহারকারী সরাসরি Site B খোলে।
3. Site B-তে সেশন নেই, তাই এটি লগ ইন দেখায়।
4. ব্যবহারকারী লগ ইন ক্লিক করে।
5. ব্রাউজার টপ-লেভেল নেভিগেশনে নির্বাচিত ইস্যুকারী Site A-তে যায়।
6. Site A নিজের বিদ্যমান হোস্ট-অনলি সেশন কুকি পড়তে পারে।
7. সেশনটি এখনও বৈধ হওয়ায় Site A সঙ্গে সঙ্গে Site B-এর জন্য একবার-ব্যবহারযোগ্য হ্যান্ডঅফ ইস্যু করে।
8. ব্রাউজার টিকিটটি POST করে Site B-তে পাঠায়।
9. Site B নিজের স্থানীয় সেশন তৈরি করে এবং ব্যবহারকারীকে চাওয়া পেজে ফিরিয়ে দেয়।

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

সীমাবদ্ধতাটিও সমান গুরুত্বপূর্ণ: ব্যবহারকারী যদি শুধু Site C-তে লগ ইন করা থাকে, তবে Site B-কে Site A-তে রিডাইরেক্ট করে লাভ নেই—যদি না Site A সত্যিকারের কেন্দ্রীয় প্রমাণীকরণ ব্রোকার হয় এবং লগইন অবস্থা সম্পর্কে তার নিজস্ব স্বাধীন জ্ঞান থাকে। শেয়ার করা ব্যবহারকারী ডেটাবেস ব্রাউজার সেশনকে শেয়ার করা বানায় না।

ক্যানোনিক্যাল ইস্যুকারী কেন সিস্টেমকে সহজ করে

স্বাধীন সাইটের সংখ্যা বাড়লে ক্যানোনিক্যাল ইস্যুকারী ইচ্ছামতো বিভিন্ন ডোমেইনে সেশন অনুসন্ধান করার প্রয়োজন সরিয়ে দেয়।

এটি না থাকলে অপ্রমাণীকৃত Site B-কে কোনোভাবে ঠিক করতে হতো, অন্য কোন সাইটে বর্তমানে কার্যকর কুকি থাকতে পারে। Site A, Site C-এর কুকি পরীক্ষা করতে পারে না; Site C, Site A-এর কুকি পরীক্ষা করতে পারে না; আর Site B কোনোটিই পরীক্ষা করতে পারে না।

ক্যানোনিক্যাল ইস্যুকারী প্রতিটি অপ্রমাণীকৃত লগইন প্রচেষ্টাকে একটি পূর্বানুমেয় পথে পাঠায়:

Site B
  → authentication issuer
  → issuer session exists?
      yes → create one-time handoff
      no  → show normal login
  → Site B consumes handoff
  → Site B creates local session

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

ছোট সিস্টেমে বিদ্যমান কোনো সাইট এই ভূমিকা নিতে পারে। বড় আর্কিটেকচারে একটি নির্দিষ্ট প্রমাণীকরণ অরিজিন ট্রাস্ট মডেল বোঝা সহজ করতে পারে।

প্রতিটি ভিজিটরকে ইস্যুকারীর মধ্য দিয়ে ঘুরিয়ে দেবেন না

প্রতিটি অপ্রমাণীকৃত পেজ ভিউতে ইস্যুকারী ফ্লো স্বয়ংক্রিয়ভাবে চালানো উচিত নয়।

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

সর্বজনীন, SEO-সংবেদনশীল পেজের জন্যও এটি খারাপ মানানসই। কোনো ক্রলার বা সাধারণ ভিজিটর সর্বজনীন URL চাইলে প্রথমে প্রমাণীকরণ ঘুরপথে বাধ্য না হয়ে সরাসরি সেই সর্বজনীন পেজই পাওয়া উচিত।

আমি যে নিয়ম ব্যবহার করি:

পেজ লোডের সময় ইস্যুকারী প্রোব করবেন না। শুধু স্পষ্ট লগইন অ্যাকশন বা ইচ্ছাকৃত প্রমাণীকৃত ক্রস-সাইট নেভিগেশনের পরেই ক্রস-ডোমেইন প্রমাণীকরণ শুরু করুন।

এতে সর্বজনীন ট্রাফিক সরল থাকে, কিন্তু নির্বাচিত ইস্যুকারীতে ইতিমধ্যে বৈধ সেশন থাকা ব্যবহারকারীর জন্য প্রমাণীকরণ তবুও দ্রুত হয়।

ফেরার পাথ যাচাইয়ে প্রিফিক্স পরীক্ষার চেয়ে বেশি যত্ন দরকার

হ্যান্ডঅফে সাধারণত মনে রাখতে হয় পরে ব্রাউজার কোথায় যাবে। মানটিকে ইচ্ছামতো ক্লায়েন্ট-নিয়ন্ত্রিত URL হিসেবে ধরলে এটি ওপেন রিডাইরেক্ট হয়ে উঠতে পারে।

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

রিলেটিভ পাথ গ্রহণ করতেই হলে সেটি সতর্কভাবে যাচাই করুন এবং টার্গেট সাইটের মধ্যেই সীমাবদ্ধ রাখুন।

ইচ্ছাকৃতভাবে সংক্ষিপ্ত একটি উদাহরণ—সম্পূর্ণ রিডাইরেক্ট-যাচাই রুটিন নয়—হলো:

function isSafeReturnPath(value) {
  if (!value.startsWith('/')) return false;
  if (value.startsWith('//')) return false;
  if (value.includes('\\\\')) return false;

  const base = 'https://example.invalid';
  const parsed = new URL(value, base);

  return parsed.origin === base;
}

বাস্তবায়নে ডিকোডিং আচরণ, ত্রুটিপূর্ণ ইনপুট, কন্ট্রোল ক্যারেক্টার, নরমালাইজেশন, অ্যাপ্লিকেশন রাউটিং নিয়ম এবং রিডাইরেক্ট তৈরি হওয়ার আগে প্রক্সি বা ফ্রেমওয়ার্ক যেসব রূপান্তর করে সেগুলোও বিবেচনা করতে হয়।

পার্সারের খুঁটিনাটির চেয়ে নিরাপত্তা ইনভেরিয়্যান্ট সহজ: হ্যান্ডঅফ টার্গেট অ্যাপ্লিকেশনের মধ্যে অনুমোদিত অবস্থান বেছে নিতে পারে, কিন্তু কখনো ইচ্ছামতো বাহ্যিক গন্তব্য নয়।

সফল পথের চেয়ে ব্যর্থতার কেস বেশি গুরুত্বপূর্ণ

সফল লগইন শুধু প্রমাণ করে যে মৌলিক পাথ কাজ করে। বেশি কার্যকর টেস্ট হলো ট্রাস্ট সীমারেখাগুলো পরীক্ষা করা।

আমি এ ধরনের কেসে আচরণ যাচাই করেছি:

• প্রমাণীকরণহীন উৎস হ্যান্ডঅফ ইস্যু করার চেষ্টা করছে;
• CSRF সুরক্ষা অনুপস্থিত;
• অনুপস্থিত, অস্বচ্ছ বা অপ্রত্যাশিত অরিজিন;
• অবিশ্বস্ত টার্গেট;
• অনিরাপদ ফেরার গন্তব্য;
• ভুল টার্গেটে টিকিট উপস্থাপন;
• ভুল অরিজিন থেকে কনজিউম করার চেষ্টা;
• টিকিট রিপ্লে;
• টিকিট মেয়াদোত্তীর্ণ হওয়া;
• যে ব্যবহারকারী আর বিদ্যমান নেই;
• প্রত্যাশিত POST বডির বদলে URL দিয়ে টিকিট পাঠানো।

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

জোড়াভিত্তিক ইন্টিগ্রেশন ছাড়াই প্রোটোকল স্কেল করে

আরও সাইট যোগ হলেও হ্যান্ডঅফ ডিজাইন মৌলিকভাবে বদলায় না।

প্রতিটি অংশগ্রহণকারী সাইটের একই ছোট চুক্তি দরকার:

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

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

এভাবে সিস্টেমটি ক্রমশ বড় হওয়া বিশেষ-কেস ম্যাট্রিক্সের বদলে একটি প্রোটোকলের ওপর ভিত্তি করে থাকে।

লগইন স্থানান্তরযোগ্যতা আর লগআউট প্রসারণ আলাদা বিষয়

স্বাধীন, হোস্টে আবদ্ধ সেশন আরেকটি গুরুত্বপূর্ণ পার্থক্য তৈরি করে: লগইন স্থানান্তরযোগ্য করলেই বৈশ্বিক লগআউট স্বয়ংক্রিয়ভাবে সংজ্ঞায়িত হয় না।

ব্যবহারকারী Site A থেকে সাইন আউট করলে ব্যাকএন্ড ইচ্ছাকৃতভাবে বাতিল না করা পর্যন্ত অন্য সাইটের স্থানীয় সেশন বৈধ থাকতে পারে। এটি সেশন-ম্যানেজমেন্ট নীতি, SSO হ্যান্ডঅফের ব্যর্থতা নয়।

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

আমি যে মডেল ব্যবহার করি

সমস্যাটিকে “ডোমেইনগুলোর মধ্যে লগইন কুকি ভাগ করা” হিসেবে বর্ণনা করা বন্ধ করার পর আর্কিটেকচারটি অনেক সহজ হয়ে যায়।

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

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

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