سنجیدہ سیکیورٹی: OAuth 2 اور آخر مائیکروسافٹ آپ کو اس میں کیوں مجبور کر رہا ہے۔

کسی بھی مقام پر جانے کے لیے نیچے دی گئی ساؤنڈ ویوز پر کلک کریں اور ڈریگ کریں۔ آپ بھی براہ راست سنیں ساؤنڈ کلاؤڈ پر۔

[میوزیکل موڈیم]

بطخ.  سب کوسلام.

ایک اور ننگے سیکیورٹی پوڈ کاسٹ منی سوڈ میں خوش آمدید!

میں پال ڈکلن ہوں، ہمیشہ کی طرح وینکوور سے میرے دوست اور ساتھی چیسٹر وسنیوسکی نے شمولیت اختیار کی۔

ہیلو، چیٹ.

---

چیٹ  ارے بطخ، واپس آنا اچھا ہے!

---

بطخ.  اب، میں نے اس موضوع کا انتخاب کیا ہے کیونکہ یہ صرف اتفاق سے ہوا، اگر آپ چاہیں تو نادانستہ طور پر، ProxyNotShell/ExchangeDoubleZeroDay مسئلہ کے ساتھ جو مائیکروسافٹ نے اکتوبر 2022 کے آغاز میں پیش آیا…

اور اس لیے کہ اس میں ایک چیز شامل ہے جسے کہا جاتا ہے۔ OAuth 2، جس کے بارے میں میں جانتا ہوں کہ آپ [A] کے بارے میں اچھی طرح سے باخبر ہیں، اور [B] کے خواہشمند ہیں۔

تو میں نے سوچا، "مسائل کا اس سے بہتر سنگم اور کیا ہوگا؟"

ایکسچینج آن لائن آخر کار لوگوں کو مائیکروسافٹ کے نام سے تبدیل کرنے پر مجبور کر رہا ہے۔ بنیادی تصدیق ماڈرن اوتھ نامی چیز کے لیے۔

لہذا، ہمیں اس تبدیلی کے بارے میں بتائیں، اور یہ کیوں اہم ہے۔

---

چیٹ  ٹھیک ہے، مجھے یہ لفظ پسند ہے۔ جدید, اس حقیقت کے باوجود کہ RFC جس پر ہم بحث کر رہے ہیں وہ اب دس سال پرانا ہے… ناقابل یقین حد تک جدید محسوس نہیں کرتا! [ہنسی]

لیکن HTTP توثیق کے مقابلے میں، جو 1990 کی دہائی میں ابتدائی براؤزر کے دنوں میں ایجاد ہوئی تھی، میرا اندازہ ہے کہ اس کے مقابلے میں یہ *کیا* جدید محسوس ہوتا ہے۔

جیسا کہ آپ کہتے ہیں، OAuth میں، "Auth" نہیں ہے۔ تصدیقبلکہ یہ ہے اجازت.

اس میں بہت سی پیچیدگیاں ہیں، لیکن اس کے ساتھ بہت سے فوائد بھی ہیں۔

اور اس لیے اگر ہم HTTP توثیق کو دیکھ رہے ہیں، تو ہم جس چیز کے بارے میں بات کر رہے ہیں وہ آپ سے ایک سند پیش کرنے کے لیے کہہ رہے ہیں، جو کہ ہم میں سے اکثر کے لیے، کسی چیز تک رسائی حاصل کرنے کے لیے صارف نام اور پاس ورڈ ہے۔

---

بطخ.  اور، لفظی طور پر، آپ صرف یوزر نیم لیتے ہیں، پھر بڑی آنت ڈالتے ہیں (لہذا آپ اپنے صارف نام میں بڑی آنت نہ رکھیں)، ہین آپ اپنا اصل پاس ورڈ ڈالتے ہیں، پھر آپ اسے بیس 64…

…اور آپ اسے HTTP درخواست کے ساتھ بھیجتے ہیں اور اچھی طرح سے امید کرتے ہیں کہ یہ TLS استعمال کر رہا ہے اور یہ کہ یہ انکرپٹڈ ہے، کیونکہ آپ کا پاس ورڈ درحقیقت ہر بار درخواست میں ہوتا ہے۔

---

چیٹ  بالکل ٹھیک.

اور یہ ہر طرح کی وجوہات کی بناء پر پریشانی کا باعث ہے، اس کا ذکر نہ کرنا، جیسا کہ آپ کہتے ہیں، کہ اگر کوئی ٹریفک کو ڈکرپٹ کرنے کے قابل ہے تو وہ بنیادی طور پر آپ کے پاس ورڈ تک رسائی رکھتا ہے۔

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

لہذا اس طرح [پاس ورڈ] کو منتقل کرنا ایک بہت زیادہ خطرہ والا عمل ہے۔

OAuth ان سب کو تھوڑا سا ڈیکپل کرتا ہے، اور کہتا ہے، "ہم آپ کو تصدیق کرنے کا طریقہ نہیں بتائیں گے، لیکن آپ کو شاید صارف نام اور پاس ورڈ مانگنے کے بجائے کچھ زیادہ سخت کرنا چاہیے۔ ہم اسے نافذ کرنے والے پر چھوڑ دیں گے۔"

کیونکہ، جیسا کہ ہم نے بہت سے دوسرے پوڈ کاسٹس کے بارے میں بات کی ہے، ملٹی فیکٹر کی توثیق کی بہت سی اقسام ہیں - ٹیکسٹ میسجز، ایپس جو آپ کو چھ ہندسوں کے کوڈز، پش ایپس، پل ایپس، ٹوکنز دکھاتی ہیں…

..یہاں کرنے کے لیے بہت سی مختلف چیزیں ہیں۔

"ہم آپ کو یہ نہیں بتانے جا رہے ہیں کہ اسے کیسے کرنا ہے۔ ہم یہ کہنے جا رہے ہیں کہ آپ کو تصدیق کے ان مضبوط طریقوں میں سے کوئی ایک طریقہ اختیار کرنا چاہیے، اور پھر، ایک بار جب آپ کو معلوم ہو جائے گا کہ آپ کس سے بات کر رہے ہیں، تو ہم آپ کو ایک ٹوکن فراہم کرنے کے لیے OAuth کا استعمال کریں گے جو آپ کی شناخت کے ثبوت سے آزاد ہے، جو کہ کیا کہتا ہے۔ آپ کے پاس کس قسم کی رسائی ہونی چاہیے، اور یہ آپ کے پاس کتنی دیر تک ہونی چاہیے۔

اور مجھے لگتا ہے کہ یہاں واقعی کلیدی حصہ ہے۔

امید ہے کہ جب آپ عام طور پر تصدیق کرتے ہیں تو آپ کا پاس ورڈ کبھی ختم نہیں ہوتا، جبکہ اس معاملے میں آپ کی کچھ میعاد ختم ہو سکتی ہے، آپ حدیں مقرر کر سکتے ہیں، اور آپ ہر اس چیز تک رسائی بھی نہیں دے سکتے ہیں جس تک صارف کی رسائی ہو۔

بلکہ، آپ کہہ سکتے ہیں، "میں صرف سب سیٹ یا اجازتوں کے مخصوص سیٹ تک رسائی دینا چاہتا ہوں۔"

اور یہ واقعی ہے جہاں اجازت سے مختلف ہے۔ تصدیق.

---

بطخ.  اگر آپ Basic Auth کے ساتھ بھی ایسا ہی کرنے کی کوشش کر رہے تھے…

…اگر آپ ای میل سسٹم تک رسائی کے دو طریقے چاہتے ہیں ایک جہاں آپ صرف پیغامات پڑھ سکتے ہیں، اور دوسرا جہاں آپ پیغامات پڑھ اور بھیج سکتے ہیں، یا تیسرا طریقہ جہاں آپ پڑھ سکتے ہیں، لکھ سکتے ہیں، اور جا کر پرانے پیغامات کو حذف کر سکتے ہیں۔ .

Basic Auth کے ساتھ، آپ کو بنیادی طور پر تین الگ الگ صارف ناموں اور پاس ورڈز کی ضرورت ہوگی، کیا آپ نہیں کریں گے؟

آپ کو ایک کی ضرورت ہوگی۔ duck-read, duck-readwrite، اور ایک duck-dothelot.

---

چیٹ  قطعی طور پر۔

اور ہم میں سے بہت سے لوگوں نے سوشل میڈیا ایپس یا سروسز جیسے Google یا Yahoo یا دیگر چیزوں کا استعمال کرتے ہوئے اس کا تجربہ کیا ہے، جہاں آپ OAuth کے استعمال کی توثیق کر سکتے ہیں، اور آپ کو اپنے براؤزر میں ایک پاپ اپ ملے گا جس میں لکھا ہوگا، "یہ ایپلی کیشن آپ کے پڑھنے کے لیے رسائی چاہتی ہے۔ ٹویٹس کریں، لیکن اپنی ٹویٹس نہ لکھیں۔

یا، "یہ ایپلیکیشن آپ کی طرح ٹویٹس بھیجنے اور آپ کی ایڈریس بک تک رسائی حاصل کرنا چاہتی ہے۔"

یہ بنیادی طور پر، لفظی طور پر، تمام مختلف اجازتوں کی فہرست بنانا یا شمار کرنا ہے جن سے آپ اتفاق کر رہے ہیں کہ آپ چاہتے ہیں کہ یہ تیسرا فریق آپ کی طرف سے کرنے کے قابل ہو۔

اور یہ واقعی وہی ہے جس کے بارے میں یہ سب کچھ ہے: مختلف پروگراموں کو چیزوں تک مختلف رسائی فراہم کرنے کے قابل ہونا، ایک محدود وقت میں بھی۔

"میں چاہتا ہوں کہ ان کے پاس صرف سات دن، یا 1 گھنٹہ، یا ہمیشہ کے لیے رسائی ہو، جب تک کہ میں آپ کو اسے منسوخ کرنے کے لیے نہ کہوں۔"

---

بطخ.  تو یہ تقریباً ایسا ہی ہے جیسے اجازت دو طرفہ طور پر کام کرنے کے لیے بنائی گئی ہے، ہے نا؟

جو Basic Auth سے بہت مختلف ہے، جہاں آپ لاگ ان ہوتے ہیں اور دوسرے سرے پر کہتا ہے، "آپ کو یہ ثابت کرنے کی ضرورت ہے کہ آپ کون ہیں، اپنا صارف نام اور پاس ورڈ ڈالیں"، اور پھر آپ داخل ہو گئے۔

یہاں، OAuth کے ساتھ، خیال یہ ہے کہ سرور آپ کو، کلائنٹ کو، یہ فیصلہ کرنے کا موقع دے رہا ہے کہ آیا آپ اس قسم کی رسائی سے متفق ہیں جو آپ چاہیں گے کہ اس سرور کو، ممکنہ طور پر کسی اور کو دیا جائے۔

لہذا، یہ کسی دوسرے سرور پر چلنے والی فیس بک ایپ ہوسکتی ہے، یا یہ کسی تیسرے فریق کو آپ کے ڈیٹا کے ساتھ کچھ چیزیں کرنے کی اجازت دے سکتی ہے، لیکن "سب یا کچھ نہیں" نہیں۔

آپ کو کسی کو *ہر چیز* تک رسائی دینے کی ضرورت نہیں ہے تاکہ انہیں *کچھ* تک رسائی فراہم کی جاسکے۔

---

چیٹ  بالکل.

وہ "اجازت کی تقسیم" واقعی اہم ہے۔

پوڈ کاسٹ کے بہت سے سامعین شاید ایڈمنسٹریٹر ہوتے ہیں، اس لیے وہ اس بات سے واقف ہیں کہ انتظامی کام کرنے کے لیے اپنے ڈومین ایڈمن اکاؤنٹ میں لاگ ان کرنا پڑتا ہے، اور پھر لاگ آؤٹ کرتے ہیں اور دوسرے کام کرنے کے لیے اپنے باقاعدہ صارف کے طور پر واپس لاگ ان ہوتے ہیں۔ کہ وہ زیادہ مراعات یافتہ نہیں ہیں۔

اور مجھے لگتا ہے کہ زیادہ استحقاق کے ساتھ ایک حقیقی مسئلہ ہے، اور جب ہم صرف صارف نام اور پاس ورڈ استعمال کر رہے ہیں، تو آپ پہلے سے طے شدہ طور پر حد سے زیادہ مراعات یافتہ ہیں۔

اور OAuth کا مقصد اس کو حل کرنا ہے، لہذا میرے خیال میں جب آپ ایکسچینج جیسی کسی چیز کے بارے میں بھی سوچ رہے ہوں تو یہ واقعی اہم ہے۔

واضح طور پر، جب آپ آؤٹ لک سے بطور صارف لاگ ان ہوتے ہیں، تو آپ میل کو پڑھنے، میل بھیجنے وغیرہ کے قابل ہونا چاہتے ہیں۔

لیکن ایک فرانزک تفتیش میں، کہتے ہیں کہ وکلاء نے کسی کی ای میل کو پیش کیا، آپ لوگوں کے میل کو پڑھنے کے لیے اکاؤنٹ تک رسائی دے سکتے ہیں لیکن اس کے ساتھ چھیڑ چھاڑ نہیں کر سکتے۔

یا آپ اس طرح کی مختلف چیزیں کر سکتے ہیں جو آپ کو بہت زیادہ گرانولریٹی کی اجازت دیتے ہیں۔

---

بطخ.  اور میرا اندازہ ہے کہ ایک اور خاص فائدہ ہے، کیونکہ اجازت اس رسائی ٹوکن کے ذریعے دی جاتی ہے، اس کا مطلب ہے کہ جس کو بھی یہ رسائی ٹوکن ملا ہے اسے آپ کا پاس ورڈ جاننے کی ضرورت نہیں ہے۔

اس کا مطلب یہ بھی ہے کہ رسائی ٹوکن کو منسوخ کیا جا سکتا ہے، یا اس کی میعاد ختم ہو سکتی ہے۔

اور جب اس کی میعاد ختم ہو جاتی ہے، تو یہ ایک ہی وقت میں آپ کے پاس ورڈ کو زبردستی دوبارہ ترتیب نہیں دیتا… جو کہ بنیادی سند کے ساتھ ایسا کرنے کا واحد طریقہ ہوگا، کیا ایسا نہیں ہوگا؟

---

چیٹ  ہاں، اور یہ بالکل مخالف سمت بھی کام کرتا ہے۔

ہو سکتا ہے آپ نے اپنے فون پر موجود ایپ کو اپنے ای میل یا اپنے ٹوئٹر جیسی کسی چیز تک رسائی دی ہو، لیکن آپ کو کسی وجہ سے اپنا ٹوئٹر پاس ورڈ تبدیل کرنا ہوگا…

…اب آپ ان ٹوکنز کی میعاد ختم ہونے سے آزادانہ طور پر اپنا پاس ورڈ تبدیل کر سکتے ہیں، اس لیے ضروری نہیں کہ آپ خود بخود ہر چیز سے لاگ آؤٹ ہو جائیں کیونکہ آپ نے اپنا پاس ورڈ تبدیل کر دیا ہے۔

تاکہ چاقو دونوں طرح سے کاٹ سکے۔

---

بطخ.  اور ایک اور خصوصیت، Chester، جو OAuth 2 کے پاس ہے وہ ایک چیز کا آئیڈیا ہے جسے "ریفریش ٹوکن" کہا جاتا ہے، جہاں آپ کو ایسے ٹوکنز تک رسائی حاصل ہو سکتی ہے جو صرف ایک محدود وقت کے لیے درست ہیں، صرف اس صورت میں کہ کچھ غلط ہو جائے۔

لیکن ان کی تجدید کرنے کے لیے، ممکنہ طور پر مستقل بنیادوں پر بھی، صارف کو پاس ورڈ پاپ اپ یا "ارے، اپنی یوبیکی کو دوبارہ سے چپک کر رکھو" پرامپٹ سے نمٹنے کی ضرورت نہیں ہے۔

اس سے نمٹنے کا ایک محفوظ طریقہ بھی ہے، ہے نا؟

---

چیٹ  جی ہاں.

آپ مختصراً کہہ سکتے ہیں، "ہر آدھے گھنٹے بعد، میں آپ کے پاس موجود ٹوکن کی میعاد ختم کرنا چاہتا ہوں، اور آپ ایک نئے کی درخواست کر سکتے ہیں۔"

لیکن اس کا مطلب یہ بھی ہے کہ اگر کچھ گڑبڑ ہو رہی ہے اور آپ کو شبہ ہے کہ آپ میں کچھ غلط ہو سکتا ہے، تو آپ ان ٹوکنز کو باطل کر سکتے ہیں اور جان بوجھ کر کسی کو دوبارہ تصدیق کرنے پر مجبور کر سکتے ہیں، صرف اس صورت میں۔

---

بطخ.  لہذا آپ کے پاس طویل یا درمیانی مدت تک رسائی حاصل کرنے کا ایک طریقہ کار ہے جسے میرے خیال میں آپ "فریکشنلیس" کہیں گے، لیکن اس حد تک نہیں کہ آپ فیصلہ کریں کہ، "ٹھیک ہے، ایک بار جب میں نے اس شخص کا پاس ورڈ دیکھ لیا ہے، یہ اس وقت تک درست رہے گا جب تک کہ وہ لاگ آؤٹ کرنے کا فیصلہ کریں، مستقبل کے کسی ممکنہ وقت پر۔

---

چیٹ  جی ہاں، پروٹوکول اسی کا مطالبہ کرتا ہے۔

اب، یہ یاد رکھنا ضروری ہے کہ ان میں سے کچھ تفصیلات لاگو کرنے والے پر منحصر ہیں… اس لیے بعض اوقات ان ٹوکنز پر دستخط ہوتے ہیں، بعض اوقات وہ نہیں ہوتے۔

یہ واقعی اس بات پر منحصر ہے کہ اسے کیسے نافذ کیا جاتا ہے۔

کچھ نئے معیارات ہیں جن کی طرف وہ آگے بڑھ رہے ہیں، جن کے بارے میں مجھے یقین ہے کہ اسے OAuth 2.1 کہا جائے گا، اور اس کا مقصد یہ ہے کہ ان میں سے مزید "عملی تفصیلات" کو باہر نکالا جائے، اور ان میں سے مزید کو بنانے کے لیے تفصیلات میں شامل کیا جائے۔ یہ زیادہ وردی ہے.

وہ تمام چیزیں جن کے بارے میں ہم بات کر رہے ہیں ضروری نہیں کہ ہر OAuth لین دین میں استعمال کیا جائے: کچھ کے پاس ریفریش ٹوکن ہوں گے، کچھ کے نہیں ہوں گے۔ کچھ ڈیجیٹل طور پر ٹوکن پر دستخط کر سکتے ہیں، دوسرے نہیں کر سکتے ہیں۔

اور، ظاہر ہے، وہ تمام چیزیں سیکیورٹی اور لچک کی مختلف سطحوں کا باعث بنتی ہیں۔

لیکن یہ سب کچھ تصریح کے اندر ہے، اور اس میں سے زیادہ تر ان مثالوں میں لاگو ہوتا ہے جو ہم آج استعمال کر رہے ہیں، خاص طور پر Microsoft، اور سوشل میڈیا نیٹ ورکس، اور Google وغیرہ کے حوالے سے۔

---

بطخ.  میرا اندازہ ہے کہ اس طرح کی تبدیلیوں میں کافی وقت لگتا ہے، اور یہ متنازعہ ہو سکتا ہے، یہ ہے کہ Basic Auth *واقعی* بنیادی ہے؛ یہ واقعی آسان ہے.

یہ ایک RFC ہے – ایک بار جب آپ اسے پڑھ لیتے ہیں، تو آپ جانتے ہیں کہ اسے کیسے کرنا ہے۔ ایک بار جب آپ اسے لاگو کر لیتے ہیں، تو یہ ہر جگہ کام کرے گا۔

جبکہ OAuth 2 واقعی کافی پیچیدہ ہے، ہے نا؟

میں دیکھ رہا ہوں۔ oauth.net ابھی سائٹ، رسائی ٹوکن کے ساتھ صفحہ پر…

…اور میرے پاس ایک آر ایف سی کے بارے میں ایک صفحہ ہے، چار دیگر آر ایف سی کا حوالہ، اور پھر تین دیگر مضامین جو میں پڑھ سکتا ہوں وہ یہ ہیں، "یہ آپ پر منحصر ہیں، ہم آپ کو یہ نہیں بتا رہے ہیں کہ یہ کیسے کریں"۔

تو یہ بہت زیادہ پیچیدہ ہے!

---

چیٹ  میرے خیال میں اچھی خبر ہے، کیونکہ OAuth 2 اب دس سال کا ہو چکا ہے، کلاؤڈ فراہم کرنے والے اسے کچھ عرصے سے استعمال کر رہے ہیں۔

انھوں نے غلطیاں کی ہیں، انھوں نے کمزوریاں پائی ہیں، انھوں نے ان طریقوں کا تعین کیا ہے جو انھیں اچھے لگتے تھے جو کہ اتنے اچھے نہیں ہیں، اور وہ تمام چیزیں ان RFCs میں چلی گئی ہیں جن کا آپ حوالہ دے رہے ہیں جو اس بہترین عمل کو مستحکم کرتے ہیں اس انتہائی لچکدار پروٹوکول کے ذریعے سیکھا۔

میرے خیال میں یہاں مائیکروسافٹ کے لیے دوسرا مسئلہ یہ ہے کہ مائیکروسافٹ کے تمام کلائنٹس Modern Auth کے ساتھ اچھا برتاؤ نہیں کرتے، اس پر منحصر ہے کہ ان کی عمر کتنی ہے، اور آپ کی ترتیب پر منحصر ہے۔

اور یہ بہت سارے ماحول کے لئے بھی مشکل ہوسکتا ہے۔

آفس 2010 نے Modern Auth کو بالکل بھی سپورٹ نہیں کیا۔

Office 2013 Modern Auth کو سپورٹ کرتا ہے، لیکن اسے بند کر دیا گیا ہے، لہذا آپ کو گروپ پالیسی یا کسی اور طریقے کو استعمال کرنے کی ضرورت ہے تاکہ اسے فعال کرنے کے لیے تمام کمپیوٹرز میں رجسٹری کی تبدیلیوں کو آگے بڑھایا جا سکے۔

آفس 2016 میں یہ موجود ہے، لیکن یہ اسے بطور ڈیفالٹ استعمال نہیں کرتا ہے، اس لیے مجھے پوری طرح یقین نہیں ہے کہ وہاں سوچنے کا عمل کیا تھا۔ [ہنسی]

لہذا آپ کو اب بھی ایک اور رجسٹری کلید کو دھکیلنا ہوگا جو کہتا ہے، "اسے پہلے استعمال کریں"، یا "اسے بطور ڈیفالٹ استعمال کریں"، بجائے اس میں ناکام ہونے کے۔

اور آخر کار، Office 2019 میں Office 365 میں، ہم دیکھتے ہیں کہ اسے بطور ڈیفالٹ فعال اور آن ہے۔

اگر آپ کو ان رجسٹری کیز کو آگے بڑھانا ہے تو، یہ Microsoft Office کی دوسری پالیسیوں کا جائزہ لینے کے لیے ایک اچھا وقت ہو سکتا ہے جن میں آپ ترمیم کرنا چاہتے ہیں۔

ہمارے پاس ابھی تک اس پر کوئی پوڈ کاسٹ نہیں ہے، بتھ، لیکن ہوسکتا ہے کہ یہ اگلا منی سوڈ ہو: میکروز کو منظم کرنے جیسی چیزوں کے بارے میں بات کرنا، اور آفس میں ان کو کیسے اور کب انجام دیا جاسکتا ہے۔

لہذا یہ ان پالیسیوں پر نظرثانی کرنے کا ایک اچھا وقت ہو سکتا ہے اگر آپ کو رجسٹری کی کچھ کلیدیں نکالنے کی ضرورت ہے، اگر آپ ابھی بھی آفس 2016 یا اس سے پہلے پر ہیں۔

---

بطخ.  یہ ایک بہت اچھا نقطہ اور بہت اچھا خیال ہے، چیسٹر! (لہذا مجھے لگتا ہے کہ مجھے مستقبل قریب میں آنے والی چیزوں کے بارے میں ایک اچھا خیال ملا ہے۔)

میں جلدی سے ایک چیز کا ذکر کرنا چاہوں گا جس کا نام OATH ہے، O-A-T-H، یہ سب دارالحکومت ہیں۔

OAuth دارالحکومت ہے۔ O، سرمایہ A، تھوڑا u، تھوڑا t، تھوڑا h.

دونوں کو الجھاؤ مت!

میری سمجھ یہ ہے کہ OATH… یہ اس سے کچھ زیادہ ہی معاملہ کرتا ہے، لیکن بنیادی طور پر یہ ایک تصریح ہے جو تصدیق کے طریقہ کار کی وضاحت کرتی ہے جسے ہم TOTP [وقت پر مبنی ون ٹائم پاس ورڈ] کے نام سے جانتے ہیں۔

یہ چھ ہندسوں کا ہیشڈ-سیکرٹ-مکسڈ-ان-دی-ٹائم ہے۔

لہذا OATH کو OAuth کے ساتھ الجھائیں نہیں۔

آپ اپنے حصے کے طور پر TOTP دو عنصر کی توثیق کا استعمال کر سکتے ہیں۔ تصدیق جب آپ اوپن کو لاگو کر رہے ہیں۔ اجازت.

لیکن وہ دو مکمل طور پر مختلف جسم ہیں، دو بالکل مختلف گروپس ہیں، اور مکمل طور پر مختلف RFCs سے ڈھکے ہوئے ہیں۔

---

چیٹ  ایکسچینج آن لائن کے بارے میں غور کرنے کے لیے ایک اور چیز، اگر آپ اس پر جاتے ہیں…

…*جب* آپ منتقل ہوتے ہیں (مجھے "اگر" نہیں کہنا چاہئے)، کیونکہ آپ کے پاس زیادہ انتخاب نہیں ہے – آپ *موڈرن آتھ* میں جا رہے ہیں۔ [ہنسی]

اس اقدام سے ممکنہ طور پر تھرڈ پارٹی ای میل پروگراموں کو منقطع کر دیا جائے گا جو صرف بنیادی توثیق کو سپورٹ کرتے ہیں۔

لہذا لینکس، میک اور ونڈوز کے لیے کئی ایپس موجود ہیں جو لوگوں کو مائیکروسافٹ آؤٹ لک استعمال کیے بغیر اپنے آؤٹ لک میل باکسز تک رسائی کی اجازت دیتی ہیں، لیکن ان میں سے زیادہ تر OAuth کو سپورٹ نہیں کرتی ہیں۔

ان میں سے اکثر صرف HTTP بنیادی توثیق کرتے ہیں۔

لہذا جب آپ حرکت کرتے ہیں تو وہ ایپس ٹوٹ جائیں گی۔

آپ کے پاس بھی چیلنج ہے، اگر آپ اب بھی IMAP یا POP کو فعال کر رہے ہیں، کہ آپ نے واقعی کوئی پیش رفت نہیں کی ہے۔

میں جتنا IMAP کا پرستار ہوں (میں IMAP کا پرانا اسکول ہوں)، اب آگے بڑھنے کا وقت ہے، خاص طور پر اگر آپ Exchange آن لائن ماحول میں ہوں۔

اور میرے خیال میں آپ کو ماڈرن اوتھ کو اپنانا چاہیے!

---

بطخ.  میرا اندازہ ہے کہ اس قسم کا شخص جو ان وقت کے اعزاز والے لینکس اور یونکس ٹولز پر قائم رہنا پسند کرتا ہے - وہ لوگ جو ہم میں سے اب بھی ہیں elms اور pines اور mutts [ہنسی]، اور اس جیسا سافٹ ویئر…

…بدقسمتی سے وہ لوگ ہیں جو ان ایپس کو برقرار رکھنے کے بارے میں شاید سب سے زیادہ پرجوش ہیں۔

لیکن یہ صرف ممکن نہیں ہونے والا ہے۔

یہ صرف آپ کو سائبرسیکیوریٹی لچک، اجازت کی لچک نہیں لاتا، جس کی آپ کو واقعی صفر اعتماد کے دور میں ضرورت ہے۔

---

چیٹ  میں نے آپ کو میرے بارے میں بات کرتے ہوئے سنا ہے… کیونکہ میں ان لوگوں میں سے ایک تھا۔

اور جب سوفوس چند سال پہلے ماڈرن توثیق کی طرف چلا گیا تو اس نے میرے میل تک رسائی کے لیے میرے پاس موجود حل کو توڑ دیا جس طرح میں ایکسچینج ماحول میں اپنے میل تک رسائی حاصل کرنا چاہتا تھا۔

جب کہ مجھے افسوس تھا کہ میں نے اپنے ای میل کو پڑھنے کا اپنا پسندیدہ طریقہ استعمال کرتے ہوئے رسائی کھو دی، میں اپنی ٹیم کے اس اقدام کا مکمل طور پر حامی تھا کیونکہ میں جانتا تھا کہ پروڈکٹ کے صارفین کے طور پر یہ ہمیں کتنی زیادہ سیکیورٹی فراہم کرنے والا ہے۔

اور یہ میرے آؤٹ لک میل میں تھنڈر برڈ کے ساتھ کھیلنے کے کسی بھی سہولت کے عنصر سے کہیں زیادہ ہے۔

---

بطخ.  تھنڈر برڈ؟! یہ بالکل نیا ہے، ہے نا، چیسٹر؟

کے مقابلے elm [ہنسی]، یا mailx… یا mail، یہاں تک کہ.

تو، چیسٹر، یہ مائیکروسافٹ کے لیے جدید ہو سکتا ہے۔ یہ شاید زیادہ تر IT محکموں میں درمیانی عمر کا ہے…

…لیکن، آپ جو بھی کریں، پیچھے نہ ہٹیں، کیونکہ اجازت دینے میں یہ لچک واقعی نام نہاد زیرو ٹرسٹ دنیا کی کلید ہے جس کی طرف ہمیں کافی حد تک آگے بڑھنا ہے، اس بات کے پیش نظر کہ ان دنوں ہر چیز آن لائن ہے۔

کیا آپ اس سے اتفاق کریں گے؟

---

چیٹ  بالکل!

ہم لوگوں کی اجازتوں کو کس طرح منظم کرتے ہیں اس میں لچک، اور ان کی توثیق کرنے کے طریقے میں لچک، جو یقیناً OAuth سے الگ ہے، جیسا کہ ہم نے بات کی…

…وہ چیزیں واقعی اہم ہیں تاکہ ہم اس بہترین عمل کو جاری رکھ سکیں جو ہمارے ڈیٹا کو محفوظ رکھنے والا ہے۔

---

بطخ.  تو یہ اس طرح کی پرانی دلیل کے ایک بڑے ورژن کی طرح ہے جو ہم نے آخر کار XP دنوں میں جیت لیا، "اپنے تمام صارفین کو منتظم نہ بنائیں۔"

یہ واقعی آسان ہے، کیونکہ اس کا مطلب ہے کہ وہ ہمیشہ سب کچھ کر سکتے ہیں…

…لیکن اس کا مطلب ہے *وہ ہمیشہ سب کچھ کر سکتے ہیں*، اور یہ بہت کم ہی ہوتا ہے جو آپ اصل میں چاہتے ہیں۔

تو، چیسٹر، میرے خیال میں یہ ایک بہت اچھا نقطہ ہے جس پر ختم ہونا ہے۔

اپنی مہارت کا اشتراک کرنے کے لیے آپ کا بہت بہت شکریہ، اور شاید، زیادہ اہم بات، آن لائن اجازت کے اس پورے معاملے کے لیے آپ کا جذبہ، جیسا کہ تصدیق سے الگ ہے۔

سننے کے لیے سب کا شکریہ۔

اور اگلی بار تک…

---

چیٹ  محفوظ رہو!

[میوزیکل موڈیم]