اپنی ایپ میں لاگ اِن کیسے شامل کریں: پاس ورڈ، میجک لنکس، Google اور رولز

ایپ میں لاگ اِن شامل کرنے کے لیے ایک طریقہ چنیں: ای میل اور پاس ورڈ، میجک لنکس (ای میل سے بھیجا گیا ایک بار استعمال ہونے والا سائن اِن لنک)، یا “Google سے سائن اِن”۔ پھر اسے کسی آزمودہ آتھ لائبریری یا ہوسٹڈ فراہم کنندہ سے نافذ کریں، شروع سے نہیں۔ اس کے بعد طے کریں کہ ہر قسم کا صارف کیا کر سکتا ہے (رولز)، اور ہر صفحے اور API درخواست پر اسے سرور پر نافذ کریں۔ سیشنز محفوظ کوکیز استعمال کریں، ان کی مدت ہو، اور لاگ آؤٹ پر صحیح طریقے سے ختم ہوں۔

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

پہلے طے کریں: کیا آپ کو لاگ اِن کی ضرورت ہے بھی؟

لاگ اِن رکاوٹ اور ذمہ داری دونوں لاتا ہے۔ آپ کو اس کی ضرورت تب ہے جب:

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

آپ کو یہ شاید نہ چاہیے ہو کسی مارکیٹنگ سائٹ، عوامی ڈائریکٹری، یا ایسے فارم کے لیے جو صرف آپ کو ای میل بھیجے۔ ویٹ لسٹ کو اکاؤنٹس کی ضرورت نہیں؛ ایک ای میل فیلڈ کافی ہے۔

چار عام لاگ اِن طریقے

بہت سی ایپس دو کو ملاتی ہیں: Google سائن اِن کے ساتھ ای میل میجک لنکس ایک مقبول جوڑا ہے جو بغیر کوئی پاس ورڈ محفوظ کیے زیادہ تر لوگوں کو کور کرتا ہے۔

ای میل اور پاس ورڈ

اگر آپ پاس ورڈز پیش کرتے ہیں تو یہ لازمی ہیں:

• پاس ورڈز کو سست پاس ورڈ hashing الگورتھم سے hash کریں۔ OWASP کی پاس ورڈ اسٹوریج رہنمائی Argon2id تجویز کرتی ہے، جبکہ scrypt، bcrypt یا PBKDF2 متبادل ہیں۔ پاس ورڈز کبھی سادہ متن میں یا تیز عمومی hash کے ساتھ نہ رکھیں۔
• پاس ورڈ ری سیٹ ایک بے ترتیب، ایک بار استعمال ہونے والا اور مدت ختم ہونے والا لنک استعمال کرے، جو تصدیق شدہ ای میل پر بھیجا جائے۔
• یہ ظاہر نہ کریں کہ کن ای میلز کے اکاؤنٹ ہیں۔ “اگر وہ ای میل رجسٹرڈ ہے تو ہم نے ری سیٹ لنک بھیج دیا ہے” بہتر ہے بجائے “کوئی اکاؤنٹ نہیں ملا” کے۔
• لاگ اِن اور ری سیٹ کی کوششوں پر ریٹ لمٹ لگائیں تاکہ پاس ورڈ کے اندازے لگانے کی رفتار کم ہو۔
• لمبے پاس ورڈز اور پاس ورڈ مینیجرز کی اجازت دیں؛ عجیب حروف کے امتزاج لازمی کرنے والے قوانین چھوڑ دیں۔

میجک لنکس اور ایک بار کے کوڈ

میجک لنک وہ سائن اِن لنک ہے جو صارف کو ای میل کیا جاتا ہے۔ اس پر کلک کرنے سے وہ لاگ اِن ہو جاتا ہے۔ ایک بار کا کوڈ اسی خیال کا ہے، مگر کلک کے بجائے ٹائپ کیا جاتا ہے۔

• لنکس اور کوڈ جلد ختم ہوں اور صرف ایک بار کام کریں۔
• لنک اس ڈیوائس پر صارف کو لاگ اِن کرے جہاں اس پر کلک ہوا، اور ٹوکن لاگز یا analytics ٹولز میں نہ رہے۔
• آپ کو قابلِ اعتماد ای میل بھیجنے کی ضرورت ہے؛ دیکھیں اپنی ایپ سے ای میلز کیسے بھیجیں۔ Gmail اور Outlook پر جانچیں، اور اسپیم فولڈر دیکھیں۔

Google سے سائن اِن (اور دوسرے OAuth فراہم کنندگان)

“Google سے سائن اِن” OAuth اور OpenID Connect استعمال کرتا ہے: Google تصدیق کرتا ہے کہ صارف کون ہے، اور آپ کی ایپ کو اس کی ای میل اور نام بتاتا ہے۔ ستمبر 2026 تک سیٹ اپ Google Cloud Console کے Google Auth Platform سیکشن میں ہوتا ہے:

1. ایک پروجیکٹ بنائیں یا چنیں، اور Branding صفحہ بھریں، یعنی consent screen پر صارفین کو کیا نظر آئے گا (ایپ کا نام، سپورٹ ای میل، لوگو)۔
2. Clients صفحے پر “Web application” قسم کا ایک client بنائیں۔
3. authorized JavaScript origins اور redirect URIs شامل کریں، یعنی وہ درست پتے جن پر آپ کی ایپ چلتی ہے اور جن پر Google سائن اِن کے بعد صارفین کو واپس بھیجتا ہے۔
4. client ID اور client secret اپنی ایپ کے سیکرٹس میں محفوظ کریں۔

Google کی OAuth دستاویزات کے مطابق عام طور پر جو چیزیں غلط ہو جاتی ہیں:

• redirect_uri_mismatch: redirect پتہ بالکل میچ ہونا چاہیے، بشمول http بمقابلہ https، حروف کی حالت اور آخر میں کوئی slash۔ اپنے preview پتے اور اپنے لائیو ڈومین دونوں کے لیے ایک ایک شامل کریں۔
• HTTPS لازمی ہے: redirect URIs HTTPS استعمال کریں، سوائے ڈیولپمنٹ میں localhost کے۔
• state پیرامیٹر واپسی پر چیک ہونا چاہیے تاکہ cross-site request forgery سے بچاؤ ہو۔ اچھی لائبریریاں یہ آپ کے لیے کرتی ہیں۔

اگر آپ صرف بنیادی سائن اِن معلومات (نام، ای میل، پروفائل) مانگتے ہیں تو Google کے مطابق ایپ کی تصدیق لازمی نہیں۔ صارفین کے Gmail، Drive یا Calendar تک رسائی مانگنا مختلف ہے اور اس کے لیے تصدیق درکار ہے۔

خود بنائیں یا فراہم کنندہ استعمال کریں؟

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

رولز اور اجازتیں

لاگ اِن بتاتا ہے کہ کوئی کون ہے۔ اجازتیں طے کرتی ہیں کہ وہ کیا کر سکتا ہے۔ شروع میں سادہ رکھیں:

وہ اصول جو رول کے ناموں سے زیادہ اہم ہیں:

• ہر بار سرور پر چیک کریں۔ صفحے پر بٹن چھپانے سے کوئی شخص API کو براہ راست کال کرنے سے نہیں رکتا۔
• مالک کے حساب سے محدود کریں۔ ممبر “بکنگ 123” مانگے تو اسے صرف تب ملے جب وہ اس کی اپنی ہو۔
• صارفین خود کو ترقی نہ دے سکیں۔ پروفائل اپ ڈیٹس میں براؤزر سے آنے والے رول فیلڈز کو نظر انداز کریں۔
• ڈیفالٹ میں کوئی رسائی نہیں۔ نئے راستوں کے لیے لاگ اِن درکار ہو، جب تک آپ خود طے نہ کریں۔

دو اکاؤنٹس کے ساتھ جانچیں: ایک سے لاگ اِن کریں، کسی ریکارڈ کا ID نوٹ کریں، پھر دوسرے سے لاگ اِن کر کے اسے کھولنے کی کوشش کریں۔ مکمل ٹیسٹ کے لیے ہماری سیکیورٹی چیک لسٹ دیکھیں۔

سیشن سیکیورٹی

لاگ اِن کے بعد ایپ ایک سیشن کے ذریعے صارف کو یاد رکھتی ہے، عموماً ایک کوکی کے ذریعے۔ OWASP کی سیشن مینجمنٹ رہنمائی یہ تجویز کرتی ہے:

• سیشن کوکیز Secure (صرف HTTPS)، HttpOnly (صفحے کے اسکرپٹس کے لیے ناقابل رسائی) اور SameSite کے ساتھ سیٹ ہوں
• لاگ اِن پر نیا سیشن ID جاری ہو، اور اختیارات بدلنے پر دوبارہ
• سرور پر نافذ ایک غیر فعالیت کا ٹائم آؤٹ اور زیادہ سے زیادہ مطلق مدت
• لاگ آؤٹ سرور پر سیشن ختم کرے، نہ کہ صرف کوکی حذف کرے
• صارف پاس ورڈ بدلے تو سیشنز منسوخ ہوں

ٹیوٹوریلز میں لاگ اِن ٹوکنز کو براؤزر کے local storage میں رکھنا عام ہے، مگر یہ صفحے پر چلنے والے کسی بھی اسکرپٹ کے سامنے انہیں کھول دیتا ہے؛ ویب ایپس کے لیے محفوظ کوکیز عموماً بہتر ڈیفالٹ ہیں۔

ضروری باتوں کو کور کرنے والا ایک پرامپٹ

اس ایپ میں صارف اکاؤنٹس شامل کرو۔ صارفین ای میل اور پاس ورڈ سے، یا Google سے سائن اپ اور لاگ اِن کر سکیں۔ کسٹم آتھ کوڈ کے بجائے [لائبریری یا فراہم کنندہ] استعمال کرو۔ پاس ورڈز کو Argon2id یا bcrypt سے hash کرو۔ ای میل کے ذریعے پاس ورڈ ری سیٹ شامل کرو، جس کا ایک بار استعمال ہونے والا لنک ایک گھنٹے میں ختم ہو۔ سیشنز محفوظ، HttpOnly کوکیز میں رکھو۔ /dashboard اور ہر /api راستے کو محفوظ کرو تاکہ صرف لاگ اِن صارف انہیں استعمال کر سکیں، اور یقینی بناؤ کہ صارفین صرف اپنے پروجیکٹس دیکھیں۔ ایک “admin” رول شامل کرو جو تمام صارفین دیکھ سکے؛ /admin تک صرف ایڈمنز پہنچیں، جو سرور پر چیک ہو۔

پھر جانچیں: سائن اپ کریں، لاگ آؤٹ کریں، لاگ اِن کریں، پاس ورڈ ری سیٹ کریں، لاگ آؤٹ حالت میں ایک نجی URL آزمائیں، اور دوسرے صارف کا ریکارڈ آزمائیں۔

AI سے بنے لاگ اِن میں عام غلطیاں

• تحفظ صرف صفحے پر۔ صفحہ لاگ آؤٹ صارفین کو ری ڈائریکٹ کرتا ہے، مگر API ہر کسی کو ڈیٹا لوٹا دیتا ہے۔
• براؤزر میں سیکرٹس۔ OAuth client secrets اور آتھ فراہم کنندہ کی ایڈمن کیز سرور پر ہونی چاہئیں۔
• preview اور لائیو URLs آپس میں مل جانا۔ Google کا redirect URI یا ری سیٹ ای میل کا لنک preview کی طرف اشارہ کرتا ہے، اس لیے پبلش کے بعد لاگ اِن ٹوٹ جاتا ہے۔
• ای میل کی تصدیق نہ ہونا۔ کوئی بھی anyone@company.com کے طور پر سائن اپ کر سکتا ہے۔ اس ای میل سے جڑی کوئی بھی چیز دینے سے پہلے ای میل کی تصدیق کریں۔
• صرف درست راستے کی جانچ۔ غلط پاس ورڈز، مدت ختم ہونے والے لنکس اور دوسرے اکاؤنٹ کو آزمائیں۔

Mythex میں لاگ اِن شامل کرنا

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

1. ایک طریقہ چنیں، مثلاً ای میل اور پاس ورڈ جو آپ کے اپنے ڈیٹا بیس میں محفوظ ہوں، یا کسی ہوسٹڈ فراہم کنندہ کا SDK۔
2. اگر آپ صارفین خود محفوظ کرتے ہیں تو ایپ کو ڈیٹا بیس چاہیے؛ چیٹ میں مانگیں یا /database استعمال کریں۔
3. فراہم کنندہ کی کیز پروجیکٹ سیکرٹس میں رکھیں (/secrets یا پروجیکٹ سیٹنگز)۔
4. اوپر جیسا پرامپٹ استعمال کریں، پھر Preview میں جانچیں۔ Google سائن اِن کے لیے، اپنے preview اور شائع شدہ پتے دونوں کے redirect URIs شامل کریں۔

دستاویزات میں ایپ میں لاگ اِن شامل کریں دیکھیں۔ اگر آپ کوئی ادائیگی والی پروڈکٹ بنا رہے ہیں تو SaaS MVP کیسے بنائیں اکاؤنٹس اور بلنگ کو ایک ساتھ بیان کرتی ہے۔

سوالات