چگونه ورود را به اپ خود اضافه کنیم: رمز عبور، لینک جادویی، Google و نقش‌ها
برای افزودن ورود به اپ، یک روش انتخاب کنید (ایمیل و رمز عبور، لینک جادویی که یک لینک ورود یک‌بارمصرف از طریق ایمیل است، یا «ورود با Google») و آن را با یک کتابخانه احراز هویت آزموده‌شده یا یک ارائه‌دهنده میزبانی‌شده پیاده‌سازی کنید، نه از صفر. سپس تصمیم بگیرید هر نوع کاربر چه کاری می‌تواند انجام دهد (نقش‌ها) و این را برای هر صفحه و هر درخواست API روی سرور اعمال کنید. نشست‌ها باید از کوکی امن استفاده کنند، منقضی شوند و هنگام خروج درست پایان یابند.
این راهنما هر انتخاب را مرور می‌کند و جزئیاتی را توضیح می‌دهد که یک ورود کارا را از یک ورود امن جدا می‌کند. برای مفاهیم پشت آن، احراز هویت چیست را ببینید.
ابتدا تصمیم بگیرید: آیا اصلاً به ورود نیاز دارید؟
ورود اصطکاک و مسئولیت اضافه می‌آورد. وقتی لازم است که:
- کاربران داده خصوصی دارند (رزروها، اسناد، فاکتورهایشان)
- کاربران چیزهایی را تغییر می‌دهند که دیگران خواهند دید
- برای دسترسی هزینه می‌گیرید
- افراد مختلف به دسترسی‌های متفاوتی نیاز دارند (مالک در برابر کارمند در برابر مشتری)
ممکن است برای یک سایت بازاریابی، یک فهرست عمومی یا فرمی که فقط برایتان ایمیل می‌فرستد، به ورود نیاز نداشته باشید. فهرست انتظار به حساب کاربری نیاز ندارد؛ یک فیلد ایمیل کافی است.
چهار روش رایج ورود
| روش | نحوه کار | مزایا | معایب |
|---|---|---|---|
| ایمیل + رمز عبور | کاربر یک رمز عبور می‌سازد؛ شما هش آن را ذخیره می‌کنید | آشنا، و بدون نیاز به ایمیل کار می‌کند | بازنشانی رمز، استفاده مجدد، نشت اطلاعات؛ باید رمز عبور را امن ذخیره کنید |
| لینک جادویی | کاربر ایمیلش را وارد می‌کند و روی لینکی که می‌فرستید کلیک می‌کند | نیازی به ذخیره یا فراموش کردن رمز عبور نیست | وابسته به تحویل ایمیل است؛ ورود کندتر است |
| کد یک‌بارمصرف | کاربر ایمیلش را وارد می‌کند و یک کد ۶ رقمی را تایپ می‌کند | وقتی لینک‌ها در مرورگر اشتباه باز می‌شوند کار می‌کند | همان وابستگی به ایمیل |
| شبکه اجتماعی / OAuth (Google، Apple، GitHub، Microsoft) | ارائه‌دهنده دیگری تأیید می‌کند کاربر کیست | سریع‌ترین روش برای کاربران؛ رمز عبوری برای ذخیره توسط شما نیست | کاربر باید آن حساب را داشته باشد؛ راه‌اندازی در سمت ارائه‌دهنده |
بسیاری از اپ‌ها دو روش را ترکیب می‌کنند: ورود با Google به‌همراه لینک جادویی ایمیلی، ترکیبی محبوب است که بیشتر مردم را پوشش می‌دهد بدون اینکه هیچ رمز عبوری ذخیره شود.
ایمیل و رمز عبور
اگر رمز عبور ارائه می‌دهید، این موارد الزامی هستند:
- رمز عبور را با یک الگوریتم هش کند هش کنید. راهنمای ذخیره رمز عبور OWASP، Argon2id را توصیه می‌کند، با scrypt، bcrypt یا PBKDF2 به‌عنوان جایگزین. هرگز رمز عبور را به‌صورت متن ساده یا با یک هش عمومی و سریع ذخیره نکنید.
- بازنشانی رمز عبور باید از یک لینک تصادفی و یک‌بارمصرف استفاده کند که منقضی می‌شود و به ایمیل تأییدشده فرستاده می‌شود.
- فاش نکنید کدام ایمیل‌ها حساب دارند. «اگر این ایمیل ثبت‌شده باشد، لینک بازنشانی ارسال شد» بهتر از «حسابی پیدا نشد» است.
- تلاش‌های ورود و بازنشانی را محدود کنید تا حدس زدن رمز عبور کند شود.
- رمز عبور طولانی و مدیر رمز عبور را بپذیرید؛ از قوانینی که ترکیب عجیب کاراکترها را اجباری می‌کنند پرهیز کنید.
لینک‌های جادویی و کدهای یک‌بارمصرف
لینک جادویی یک لینک ورود است که برای کاربر ایمیل می‌شود. کلیک روی آن او را وارد می‌کند. کد یک‌بارمصرف همان ایده است، با این تفاوت که به جای کلیک، تایپ می‌شود.
- لینک‌ها و کدها سریع منقضی می‌شوند و فقط یک بار کار می‌کنند.
- لینک باید کاربر را روی دستگاهی که روی آن کلیک کرده وارد کند و توکن نباید در لاگ‌ها یا ابزارهای تحلیل بماند.
- به ارسال ایمیل قابل‌اعتماد نیاز دارید؛ چگونه از اپ ایمیل بفرستیم را ببینید. با Gmail و Outlook آزمایش کنید و پوشه هرزنامه را بررسی کنید.
ورود با Google (و سایر ارائه‌دهندگان OAuth)
«ورود با Google» از OAuth و OpenID Connect استفاده می‌کند: Google تأیید می‌کند کاربر کیست و ایمیل و نامش را به اپ شما می‌گوید. راه‌اندازی، تا سپتامبر ۲۰۲۶، در بخش Google Auth Platform در Google Cloud Console انجام می‌شود:
- یک پروژه بسازید یا انتخاب کنید و صفحه Branding را پر کنید؛ آنچه کاربران روی صفحه رضایت می‌بینند (نام برنامه، ایمیل پشتیبانی، لوگو).
- در صفحه Clients، یک کلاینت از نوع «Web application» بسازید.
- authorized JavaScript origins و redirect URIs را اضافه کنید؛ یعنی نشانی دقیقی که اپ شما روی آن اجرا می‌شود و Google کاربران را پس از ورود به آن برمی‌گرداند.
- شناسه کلاینت و Secret کلاینت را در Secretهای اپ ذخیره کنید.
مشکلاتی که معمولاً پیش می‌آیند، بر اساس مستندات OAuth گوگل:
redirect_uri_mismatch: نشانی redirect باید دقیقاً یکی باشد، از جملهhttpدر برابرhttps، حروف بزرگ و کوچک و هر اسلش انتهایی. یکی برای نشانی پیش‌نمایش و یکی برای دامنه زنده خود اضافه کنید.- HTTPS الزامی است: redirect URIها باید از HTTPS استفاده کنند، مگر
localhostدر توسعه. - پارامتر
stateهنگام بازگشت باید بررسی شود تا از جعل درخواست بین‌سایتی (CSRF) محافظت شود. کتابخانه‌های خوب این کار را برای شما انجام می‌دهند.
اگر فقط اطلاعات پایه ورود (نام، ایمیل، پروفایل) را درخواست کنید، Google می‌گوید تأیید برنامه الزامی نیست. درخواست دسترسی به Gmail، Drive یا Calendar کاربران متفاوت است و نیازمند تأیید است.
خودتان بسازید یا از ارائه‌دهنده استفاده کنید؟
| رویکرد | نمونه‌ها | وقتی مناسب است |
|---|---|---|
| ارائه‌دهنده احراز هویت میزبانی‌شده | سرویس‌هایی که ورود، مدیریت کاربران و نشست‌ها را برای شما میزبانی می‌کنند | می‌خواهید ورود سریع کار کند با مسئولیت امنیتی کمتر |
| کتابخانه احراز هویت در اپ | کتابخانه‌های متن‌باز برای فریم‌ورک شما | می‌خواهید کاربران در پایگاه داده خودتان باشند و هزینه هر کاربر نداشته باشید |
| خودتان بنویسید | — | تقریباً هرگز. جزئیات ظریف زیاد است |
هر دو گزینه اول منطقی هستند. ارائه‌دهندگان میزبانی‌شده کارهای بیشتری برایتان انجام می‌دهند، اما یک وابستگی اضافه می‌کنند و گاهی برای هر کاربر فعال هزینه دارند؛ قیمت‌های فعلی را در سایت خودشان بررسی کنید. کتابخانه‌ها همه‌چیز را در پایگاه داده شما نگه می‌دارند، اما تنظیم درست بیشتری به عهده شماست. هر کدام را انتخاب کنید، از هوش مصنوعی بخواهید از آن استفاده کند، نه اینکه منطق رمز عبور یا نشست را دستی بنویسد.
نقش‌ها و دسترسی‌ها
ورود به شما می‌گوید چه کسی است. دسترسی‌ها تعیین می‌کنند چه کاری می‌تواند انجام دهد. در ابتدا ساده نگه دارید:
| نقش | دسترسی‌های معمول |
|---|---|
| بازدیدکننده | دیدن صفحات عمومی |
| عضو / مشتری | دیدن و ویرایش رکوردهای خودش |
| کارمند | دیدن همه رکوردهای تیم یا کسب‌وکارش؛ نمی‌تواند تنظیمات یا صورتحساب را تغییر دهد |
| مالک / مدیر | همه‌چیز، از جمله کاربران و صورتحساب |
قواعدی که از اسم نقش‌ها مهم‌ترند:
- هر بار روی سرور بررسی کنید. پنهان کردن یک دکمه در صفحه، جلوی کسی که مستقیم API را صدا می‌زند را نمی‌گیرد.
- بر اساس مالک محدود کنید. عضوی که «رزرو ۱۲۳» را می‌خواهد، فقط باید آن را دریافت کند اگر مال خودش باشد.
- کاربران نمی‌توانند خودشان را ارتقا دهند. فیلدهای نقش ارسال‌شده از مرورگر را در به‌روزرسانی پروفایل نادیده بگیرید.
- پیش‌فرض را دسترسی‌نداشتن بگذارید. مسیرهای جدید باید ورود بخواهند، مگر اینکه خلاف آن را تصمیم بگیرید.
با دو حساب آزمایش کنید: با یکی وارد شوید، شناسه یک رکورد را یادداشت کنید، سپس با دیگری وارد شوید و سعی کنید آن را باز کنید. چک‌لیست امنیتی ما آزمون کامل را دارد.
امنیت نشست
پس از ورود، اپ کاربر را با یک نشست به یاد می‌آورد، معمولاً با یک کوکی. راهنمای مدیریت نشست OWASP این موارد را توصیه می‌کند:
- کوکی‌های نشست با
Secure(فقط HTTPS)،HttpOnly(غیرقابل‌خواندن توسط اسکریپت‌های صفحه) وSameSiteتنظیم شده باشند - پس از ورود یک شناسه نشست جدید صادر شود، و دوباره وقتی دسترسی‌ها تغییر می‌کنند
- یک timeout بیکاری و یک حداکثر طول عمر مطلق تعیین و روی سرور اعمال شوند
- خروج، نشست را روی سرور پایان دهد، نه فقط کوکی را حذف کند
- نشست‌ها وقتی کاربر رمز عبورش را تغییر می‌دهد باطل شوند
ذخیره توکن‌های ورود در local storage مرورگر در آموزش‌ها رایج است، اما آن را در معرض هر اسکریپتی که روی صفحه اجرا شود قرار می‌دهد؛ برای اپ‌های وب، کوکی امن معمولاً انتخاب بهتری است.
یک پرامپت که ضروریات را پوشش می‌دهد
برای این اپ حساب کاربری اضافه کن. کاربران بتوانند با ایمیل و رمز عبور یا با Google ثبت‌نام و وارد شوند. به‌جای کد احراز هویت سفارشی از [کتابخانه یا ارائه‌دهنده] استفاده کن. رمزها را با Argon2id یا bcrypt هش کن. بازنشانی رمز عبور از طریق ایمیل با یک لینک یک‌بارمصرف که یک ساعت اعتبار دارد اضافه کن. نشست‌ها را در کوکی‌های امن و HttpOnly نگه دار. /dashboard و هر مسیر /api را محافظت کن تا فقط کاربران واردشده بتوانند از آن‌ها استفاده کنند، و مطمئن شو کاربران فقط پروژه‌های خودشان را ببینند. یک نقش «admin» اضافه کن که همه کاربران را ببیند؛ فقط مدیران بتوانند به /admin برسند، که روی سرور بررسی می‌شود.
سپس آزمایش کنید: ثبت‌نام، خروج، ورود، بازنشانی رمز عبور، باز کردن یک آدرس خصوصی در حالت خروج‌شده، و امتحان کردن رکورد کاربر دیگر.
اشتباهات رایج در ورودهای ساخته‌شده با هوش مصنوعی
- حفاظت فقط در صفحه. صفحه کاربران خروج‌شده را هدایت می‌کند، اما API داده را به هر کسی برمی‌گرداند.
- Secretها در مرورگر. Secret کلاینت OAuth و کلیدهای مدیریتی ارائه‌دهنده احراز هویت باید روی سرور باشند.
- جابه‌جایی آدرس پیش‌نمایش و زنده. redirect URI گوگل یا لینک ایمیل بازنشانی به پیش‌نمایش اشاره می‌کند، پس ورود بعد از انتشار خراب می‌شود.
- نبود تأیید ایمیل. هر کسی می‌تواند با anyone@company.com ثبت‌نام کند. قبل از دادن هر چیزی که به آن ایمیل گره خورده، ایمیل را تأیید کنید.
- آزمایش فقط مسیر موفق. رمز اشتباه، لینک منقضی‌شده و یک حساب دوم را امتحان کنید.
افزودن ورود در Mythex
در Mythex، ورود برای کاربران اپ شما چیزی است که به اپ خودتان اضافه می‌کنید؛ این با حساب Mythex خودتان جداست. Mythex یک محصول احراز هویت داخلی ارائه نمی‌دهد، بنابراین یک کتابخانه یا ارائه‌دهنده احراز هویت و کلیدهایش را خودتان می‌آورید:
- یک رویکرد انتخاب کنید؛ برای مثال ایمیل و رمز عبور ذخیره‌شده در پایگاه داده خودتان، یا SDK یک ارائه‌دهنده میزبانی‌شده.
- اگر کاربران را خودتان ذخیره می‌کنید، اپ به پایگاه داده نیاز دارد؛ آن را در چت درخواست کنید یا از
/databaseاستفاده کنید. - کلیدهای ارائه‌دهنده را در Secretهای پروژه (
/secretsیا تنظیمات پروژه) قرار دهید. - از پرامپتی مشابه بالا استفاده کنید، سپس در Preview آزمایش کنید. برای ورود با Google، redirect URIها را برای هم نشانی پیش‌نمایش و هم نشانی منتشرشده اضافه کنید.
برای جزئیات، افزودن ورود به اپ را در مستندات ببینید. اگر یک محصول پولی می‌سازید، چگونه یک MVP از SaaS بسازیم حساب‌ها و صورتحساب را با هم پوشش می‌دهد.
پرسش‌ها
ساده‌ترین روش ورود برای افزودن به یک اپ کدام است؟
استفاده از یک ارائه‌دهنده احراز هویت میزبانی‌شده یا یک کتابخانه احراز هویت خوش‌نگهداری‌شده معمولاً ساده‌ترین و امن‌ترین راه است، چون نشست‌ها، ذخیره رمز عبور و بازنشانی آن‌ها از قبل مدیریت شده‌اند. ورود با Google کم‌اصطکاک‌ترین گزینه برای کاربرانی است که حساب Google دارند.
آیا لینک‌های جادویی امن‌تر از رمز عبور هستند؟
آن‌ها استفاده مجدد از رمز عبور و رمزهای ضعیف را حذف می‌کنند، اما ریسک را به حساب ایمیل کاربر منتقل می‌کنند. لینک‌ها باید سریع منقضی شوند و فقط یک بار کار کنند. برای بیشتر اپ‌های کوچک انتخاب معقولی هستند و اغلب در کنار ورود با Google ارائه می‌شوند.
برای افزودن ورود با Google به تأیید Google نیاز دارم؟
اگر فقط اطلاعات پایه ورود (نام، ایمیل و پروفایل) را درخواست کنید، Google می‌گوید تأیید برنامه الزامی نیست، هرچند همچنان باید صفحه رضایت و کلاینت OAuth را پیکربندی کنید. درخواست دسترسی به داده حساس مانند Gmail یا Drive نیازمند تأیید برنامه توسط Google است.
تفاوت ورود و دسترسی‌ها چیست؟
ورود (احراز هویت) تأیید می‌کند کاربر کیست. دسترسی‌ها (مجوزدهی) تعیین می‌کنند آن کاربر چه چیزی را ببیند و چه کاری انجام دهد. یک اپ به هر دو نیاز دارد و دسترسی‌ها باید برای هر درخواست روی سرور بررسی شوند.