Authentication کیا ہے؟ Logins، Sessions اور OAuth کی وضاحت

Authentication وہ طریقہ ہے جس سے ایپ تصدیق کرتی ہے کہ صارف کون ہے، عموماً کسی ایسی چیز کو جانچ کر جو وہ جانتا ہے (پاس ورڈ)، کسی ایسی چیز کو جو اس کے پاس ہے (فون یا ای میل پر بھیجا گیا کوڈ)، یا کسی بھروسے مند دوسری سروس کی شناخت (جیسے “Google سے سائن اِن کریں”)۔ ایک بار صارف کی تصدیق ہو جائے تو ایپ اسے session یا token کے ذریعے یاد رکھتی ہے، تاکہ اسے ہر صفحے پر دوبارہ لاگ اِن نہ کرنا پڑے۔ یہ طے کرنا کہ وہ معلوم صارف کیا کر سکتا ہے، ایک الگ مرحلہ ہے جسے authorization کہتے ہیں۔

AI سے بنانے میں یہ کیوں اہم ہے

لاگ اِن شامل کرنا ان سب سے عام درخواستوں میں سے ہے جو لوگ AI بلڈر سے کرتے ہیں، اور یہ غلط ہونا بھی آسان ہے۔ لاگ اِن کا صفحہ بنانا سادہ ہے۔ اصل مشکل وہ سب کچھ ہے جو اس کے گرد ہے:

• کیا پاس ورڈ محفوظ طریقے سے محفوظ ہیں؟
• کیا ہر نجی صفحہ اور ہر API endpoint واقعی جانچتا ہے کہ کون درخواست کر رہا ہے؟
• کیا لاگ اِن کیا ہوا کسٹمر URL میں ایک نمبر بدل کر کسی دوسرے کسٹمر کا ڈیٹا دیکھ سکتا ہے؟
• جب کوئی پاس ورڈ بھول جائے تو کیا ہوتا ہے؟

ایک ایپ مکمل محفوظ نظر آ سکتی ہے اور پھر بھی ان میں سے ہر ایک میں ناکام ہو۔ ان حصوں کو سمجھنے سے آپ درست سوال پوچھ سکتے ہیں اور درست چیزیں جانچ سکتے ہیں۔

روزمرہ کی ایک مثال

تصور کریں ایک ہوٹل میں چیک اِن کر رہے ہیں۔

فرنٹ ڈیسک پر آپ شناختی کارڈ دکھاتے ہیں۔ یہ authentication ہے: یہ ثابت کرنا کہ آپ کون ہیں۔ پھر استقبالیہ آپ کو ایک کی کارڈ دیتا ہے۔ یہ کارڈ آپ کا session ہے: قیام کے باقی حصے میں آپ دوبارہ شناختی کارڈ نہیں دکھاتے، بس کارڈ لگاتے ہیں۔

کارڈ آپ کے کمرے، جم اور آپ کی منزل کی لفٹ کو کھولتا ہے، مگر دوسرے مہمانوں کے کمروں یا عملے کے دفتر کو نہیں۔ یہ authorization ہے: آپ کی شناخت کس چیز تک رسائی رکھتی ہے۔ اگر کارڈ گم ہو جائے تو ہوٹل اسے ڈیسک پر غیر فعال کر سکتا ہے (session منسوخ کرنا)۔ چیک آؤٹ پر وہ کام کرنا بند کر دیتا ہے (لاگ آؤٹ، یا میعاد ختم ہونا)۔

“Google سے سائن اِن کریں” ایسا ہے جیسے ہوٹل کسی بھروسے مند شراکت دار کا خط قبول کر لے جو کہتا ہو “یہ یہی شخص ہے”، بجائے اس کے کہ خود آپ کا شناختی کارڈ چیک کرے۔

اہم لاگ اِن طریقے

پاس ورڈز کیسے محفوظ ہونے چاہئیں

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

دو تفصیلات اسے محفوظ بناتی ہیں:

• Salt: ہر پاس ورڈ کے ساتھ hash سے پہلے ملایا جانے والا بے ترتیب مان، تاکہ دو لوگوں کا ایک ہی پاس ورڈ ہو تب بھی ان کے hashes مختلف ہوں، اور پہلے سے بنی lookup tables بے کار ہو جائیں۔
• پاس ورڈز کے لیے بنایا گیا سست الگورتھم: جیسے Argon2، bcrypt یا scrypt۔ عام مقصد کے hashes جیسے MD5 یا SHA-256 اپنی ذات میں بہت تیز ہیں؛ حملہ آور اربوں اندازے آزما سکتے ہیں۔

Hashing اور encryption ایک چیز نہیں ہیں۔ encrypt کیا ہوا ڈیٹا key سے واپس decrypt ہو سکتا ہے؛ پاس ورڈ کا hash اس طرح بنایا گیا ہے کہ واپس بدلا ہی نہ جا سکے۔

Sessions بمقابلہ Tokens

لاگ اِن کے بعد ایپ کو ہر درخواست پر آپ کو پہچاننا ہوتا ہے۔ اس کے لیے دو عام طریقے ہیں۔

cookies کے لیے تین ترتیبات اہم ہیں: HttpOnly (صفحے پر JavaScript cookie نہیں پڑھ سکتا)، Secure (صرف HTTPS پر بھیجی جائے) اور SameSite (دوسری سائٹس کی درخواستوں پر اسے بھیجنے کو محدود کرتا ہے)۔ براؤزر کے localStorage میں tokens رکھنا عام ہے، مگر اس سے وہ صفحے پر چلنے والے ہر اسکرپٹ کے سامنے کھل جاتے ہیں۔

OAuth اور “Google سے سائن اِن کریں”

OAuth 2.0 تفویض شدہ اجازت کا معیار ہے: یہ کسی ایپ کو آپ کے کسی دوسری سروس کے اکاؤنٹ تک محدود رسائی دیتا ہے، مثلاً آپ کا Google Calendar پڑھنا، بغیر کبھی آپ کا Google پاس ورڈ دیکھے۔ آپ کو Google کے صفحے پر بھیجا جاتا ہے، آپ مخصوص اجازتیں منظور کرتے ہیں (جنہیں scopes کہا جاتا ہے)، اور Google ایپ کو صرف انہی اجازتوں کے لیے token دیتا ہے۔

اکیلا OAuth اس لیے بنایا گیا تھا کہ رسائی دے، یہ بتانے کے لیے نہیں کہ آپ کون ہیں۔ OpenID Connect (OIDC) OAuth 2.0 کے اوپر ایک تہہ ہے جو شناخت شامل کرتی ہے، اور یہی “Google سے سائن اِن” یا “Apple سے سائن اِن” میں استعمال ہوتی ہے۔ اسے سیٹ اپ کرنے کے لیے آپ اپنی ایپ کو فراہم کنندہ کے پاس رجسٹر کرتے ہیں اور client ID اور client secret حاصل کرتے ہیں؛ secret آپ کے سرور پر ہی رہتا ہے۔

ایک عملی مثال: کلائنٹ پورٹل کے لیے لاگ اِن

فرض کریں آپ ایک ایسا پورٹل بنا رہے ہیں جہاں ایک ڈیزائن ایجنسی کے کلائنٹس اپنے پروجیکٹس اور انوائسز دیکھتے ہیں۔

• Authentication: کلائنٹس ای میل اور magic link سے لاگ اِن کرتے ہیں، تاکہ کوئی پاس ورڈ سنبھالنا نہ پڑے۔ ایجنسی کا عملہ Google Workspace اکاؤنٹس سے لاگ اِن کرتا ہے۔
• Roles: ہر صارف کا ایک کردار ہوتا ہے: client یا staff۔
• Authorization کے اصول:

• نافذ کہاں ہوتا ہے: سرور پر، ہر درخواست کے لیے۔ سرور لاگ اِن صارف کو دیکھتا ہے، پھر صرف وہی پروجیکٹس واپس کرتا ہے جہاں project.company_id صارف کی کمپنی سے مل رہا ہو۔ صرف “ادا شدہ” بٹن چھپانا کافی نہیں؛ endpoint خود انکار کرنا چاہیے۔

عام اصطلاحات کی وضاحت

عام غلطیاں اور غلط فہمیاں

• صرف صفحے پر اجازت جانچنا۔ اگر براؤزر بٹن چھپا دے مگر API جانچ نہ کرے، تو کوئی بھی API کو براہِ راست کال کر سکتا ہے۔
• URL کے IDs پر بھروسا کرنا۔ /invoices/1042 کو جانچنا ہوگا کہ انوائس 1042 لاگ اِن صارف کی ہے۔
• اپنا crypto خود بنانا۔ معروف لائبریریاں یا فراہم کنندگان استعمال کریں؛ AI کو hashing کا اپنا طریقہ ایجاد نہ کرنے دیں۔
• کمزور پاس ورڈ ری سیٹ۔ ری سیٹ لنک ایک بار استعمال ہونے والا ہو، جلد ختم ہو، اور یہ ظاہر نہ کرے کہ ای میل کا اکاؤنٹ ہے یا نہیں۔
• اپنے لاگ اِن کو بلڈر کے لاگ اِن سے خلط ملط کرنا۔ آپ کی ایپ کے صارفین اس ٹول کے اکاؤنٹ سے الگ ہیں جس سے آپ بناتے ہیں۔
• لاگ اِن پر ریٹ لمیٹ نہ ہونا۔ اس کے بغیر حملہ آور پاس ورڈ لامحدود بار آزما سکتے ہیں۔

اپنے AI بلڈر سے کیا مانگیں

• “[کسی معروف لائبریری یا فراہم کنندہ] سے سائن اَپ اور لاگ اِن شامل کرو۔ اپنا hashing کا کوڈ نہ لکھو۔”
• “پاس ورڈز کو bcrypt یا Argon2 سے hash کر کے محفوظ کرو۔”
• “session کے لیے HttpOnly اور Secure cookies استعمال کرو۔”
• “کردار شامل کرو: admin اور member۔ ہر endpoint کی فہرست دو اور بتاؤ کہ کون سے کردار اسے کال کر سکتے ہیں۔”
• “سرور پر یقینی بناؤ کہ صارف صرف اپنے ریکارڈز پڑھ اور بدل سکیں۔ پھر دکھاؤ کہ تم نے کیسے جانچا۔”
• “پاس ورڈ ری سیٹ شامل کرو جس کے لنک ایک بار استعمال ہوں اور ایک گھنٹے میں ختم ہو جائیں۔”
• “لاگ اِن کی کوششوں کو ریٹ لمیٹ کرو۔”

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

Mythex میں Authentication

Mythex آپ کی ایپ کے صارفین کے لیے کوئی بلٹ اِن auth پروڈکٹ فراہم نہیں کرتا؛ آپ ایک طریقہ چنتے ہیں، یعنی آپ کے پروجیکٹ ڈیٹابیس میں ای میل اور پاس ورڈ، یا کسی ہوسٹڈ فراہم کنندہ کا SDK، اور ایجنٹ سے اسے شامل کرنے کو کہتے ہیں۔ فراہم کنندہ کی keys پروجیکٹ secrets میں رکھی جاتی ہیں، چیٹ میں نہیں۔ یہ اس سے الگ ہے کہ آپ خود Mythex میں کیسے سائن اِن کرتے ہیں۔ docs کی ریسیپی اپنی ایپ میں لاگ اِن شامل کرنا میں ایک شروعاتی پرامپٹ ہے جسے آپ ڈھال سکتے ہیں، اور API کیا ہے بتاتا ہے کہ وہ سرور کی جانب کی جانچیں کہاں رہتی ہیں۔

سوالات