آزاد روٹ ڈومینز کے درمیان کراس ڈومین 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 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 ہینڈ آف کی ناکامی نہیں۔

نظام مقامی لاگ آؤٹ، عالمی لاگ آؤٹ یا واضح سیشن مینجمنٹ میں سے انتخاب کر سکتا ہے۔ اس فیصلے کو ہینڈ آف سے الگ رکھنے سے دونوں طریقۂ کار سمجھنا آسان ہو جاتا ہے۔

وہ ماڈل جو میں استعمال کرتا ہوں

جب میں نے مسئلے کو “ڈومینز کے درمیان لاگ اِن کوکیز شیئر کرنا” کہنا چھوڑ دیا تو آرکیٹیکچر زیادہ سادہ ہو گیا۔

ایک عالمی شناخت ہے، ہر ڈومین اپنے براؤزر سیشن کا مالک ہے، اور مختصر مدت کا یک بار استعمال ہونے والا ہینڈ آف کسی تصدیق شدہ قابلِ اعتماد اوریجن کو دوسرے مقامی سیشن کی تخلیق کی اجازت دینے دیتا ہے۔

کسی غیر تصدیق شدہ سائٹ پر براہِ راست داخل ہونے کے لیے ایک اضافی اصول اہم ہے: براؤزر کو ایسے جاری کنندہ کے پاس بھیجنا ہوگا جو واقعی صارف کا موجودہ سیشن دیکھ سکتا ہو۔ اگر صارف نے پہلے اسی جاری کنندہ پر سائن اِن کیا تھا تو آنا جانا تقریباً نظر نہ آنے جتنا تیز ہو سکتا ہے۔ اگر جاری کنندہ کے پاس معتبر سیشن نہیں تو اسے معمول کی تصدیق پر واپس جانا چاہیے، نہ کہ یہ دکھاوا کرنا چاہیے کہ کسی دوسرے غیر متعلق ڈومین کا سیشن نظر آ رہا ہے۔

یہ ماڈل براؤزر کی ڈومین حدود برقرار رکھتا ہے، عوامی وزیٹرز کے لیے غیر ضروری تصدیقی ری ڈائریکٹس سے بچتا ہے، اور پھر بھی مطلوبہ تجربہ دیتا ہے: جاری کنندہ پر سائن اِن کریں، بعد میں دوسری قابلِ اعتماد سائٹ کھولیں، لاگ اِن پر کلک کریں، اور دوبارہ پاس ورڈ دیے بغیر نئے مقامی سیشن کے ساتھ واپس آ جائیں۔