احراز هویت چیست؟ ورود، نشست‌ها و OAuth توضیح داده می‌شود
احراز هویت راهی است که برنامه تأیید می‌کند کاربر کیست — معمولاً با بررسی چیزی که او می‌داند (گذرواژه)، چیزی که دارد (کدی که به تلفن یا ایمیلش فرستاده می‌شود) یا هویتی از یک سرویس معتبر دیگر (مثل «ورود با Google»). وقتی کاربر احراز هویت شد، برنامه او را با یک نشست یا توکن به خاطر می‌سپارد تا لازم نباشد در هر صفحه دوباره وارد شود. تعیین اینکه آن کاربر شناخته‌شده مجاز به چه کارهایی است، مرحله جداگانه‌ای است به نام مجوزدهی (authorization).
چرا وقتی با هوش مصنوعی می‌سازید مهم است
افزودن ورود یکی از رایج‌ترین درخواست‌هایی است که افراد از سازنده برنامه با هوش مصنوعی می‌کنند، و یکی از راحت‌ترین کارهایی که به‌طور ظریف اشتباه از آب درمی‌آید. صفحه ورود تولید کردنش ساده است. بخش سخت، همه چیزهای اطرافش است:
- آیا گذرواژه‌ها به‌صورت امن ذخیره می‌شوند؟
- آیا هر صفحه خصوصی و هر نقطه پایانی API واقعاً بررسی می‌کند چه کسی درخواست می‌دهد؟
- آیا یک مشتری واردشده می‌تواند با تغییر یک عدد در آدرس، داده‌های مشتری دیگری را ببیند؟
- وقتی کسی گذرواژه‌اش را فراموش می‌کند چه اتفاقی می‌افتد؟
یک برنامه می‌تواند کاملاً امن به‌نظر برسد و در همه این موارد شکست بخورد. فهمیدن اجزای متحرک به شما کمک می‌کند سؤال درست بپرسید و چیزهای درست را آزمایش کنید.
یک تشبیه روزمره
تصور کنید در یک هتل پذیرش می‌شوید.
در میز پذیرش شناسنامه یا کارت شناسایی‌تان را نشان می‌دهید. این احراز هویت است: اثبات اینکه کی هستید. سپس پذیرش یک کارت کلید به شما می‌دهد. این کارت نشست شماست: برای بقیه اقامت دیگر لازم نیست شناسنامه نشان دهید؛ فقط کارت را می‌زنید.
کارت در اتاق شما، باشگاه و آسانسور طبقه‌تان را باز می‌کند، اما اتاق مهمان‌های دیگر یا دفتر کارکنان را نه. این مجوزدهی است: اینکه هویت شما به چه چیزهایی دسترسی دارد. اگر کارت را گم کنید، هتل می‌تواند آن را از پذیرش غیرفعال کند (لغو نشست). وقتی تسویه می‌کنید، از کار می‌افتد (خروج از حساب، یا انقضا).
«ورود با Google» مثل این است که هتل به‌جای اینکه خودش شناسنامه‌تان را بررسی کند، نامه‌ای از یک شریک معتبر بپذیرد که بگوید «این فرد همین است».
روش‌های اصلی ورود
| روش | چطور کار می‌کند | مزایا | معایب |
|---|---|---|---|
| ایمیل + گذرواژه | کاربر گذرواژه انتخاب می‌کند؛ برنامه هش آن را ذخیره می‌کند | آشنا، بدون وابستگی بیرونی | باید هش‌ها را امن ذخیره کنید و بازنشانی را مدیریت کنید |
| لینک جادویی / کد یک‌بارمصرف | برنامه لینک یا کدی به ایمیل می‌فرستد که کاربر را وارد می‌کند | گذرواژه‌ای برای لو رفتن یا فراموش شدن ندارد | به تحویل ایمیل وابسته است؛ ورود کندتر است |
| ورود با شبکه اجتماعی (OAuth / OpenID Connect) | کاربر با Google، Apple، GitHub و غیره وارد می‌شود | برای کاربر سریع است؛ گذرواژه‌ای نزد شما ذخیره نمی‌شود | تنظیم برای هر ارائه‌دهنده؛ کاربران بدون آن حساب‌ها |
| ارائه‌دهنده احراز هویت میزبانی‌شده | سرویسی مثل Clerk، Auth0 یا Supabase Auth ثبت‌نام، ورود و بازنشانی را انجام می‌دهد | کار امنیتی کمتری برای شما | هزینه ماهانه در مقیاس بزرگ؛ یک وابستگی دیگر |
| چندعاملی (MFA / 2FA) | یک بررسی دوم پس از اولی، مثل کد برنامه احراز هویت | نفوذ به آن بسیار سخت‌تر است | کمی اصطکاک بیشتر |
گذرواژه‌ها باید چطور ذخیره شوند
یک برنامه امن هرگز گذرواژه واقعی شما را ذخیره نمی‌کند. به‌جایش یک هش ذخیره می‌کند: خروجی یک تابع یک‌طرفه که گذرواژه را به یک رشته ثابت تبدیل می‌کند. وقتی وارد می‌شوید، برنامه آنچه تایپ کرده‌اید را هش می‌کند و نتیجه را با هش ذخیره‌شده مقایسه می‌کند.
دو جزئیات این کار را امن می‌کند:
- نمک (salt) — یک مقدار تصادفی که قبل از هش‌کردن به هر گذرواژه اضافه می‌شود، تا دو نفر با گذرواژه یکسان، هش‌های متفاوت داشته باشند و جدول‌های جستجوی از پیش‌محاسبه‌شده بی‌فایده شوند.
- یک الگوریتم کند که برای گذرواژه ساخته شده — مثل Argon2، bcrypt یا scrypt. هش‌های همه‌منظوره مثل MD5 یا SHA-256 به‌تنهایی بسیار سریع‌اند؛ مهاجمان می‌توانند میلیاردها حدس بزنند.
هش‌کردن همان رمزنگاری نیست. داده رمزنگاری‌شده را می‌شود با کلید رمزگشایی کرد؛ هش گذرواژه طوری طراحی شده که اصلاً قابل برگشت نباشد.
نشست در برابر توکن
بعد از ورود، برنامه باید در هر درخواست شما را بشناسد. دو روش رایج وجود دارد.
| نشست (کوکی) | توکن (مثلاً JWT) | |
|---|---|---|
| آنچه مرورگر نگه می‌دارد | یک شناسه تصادفی نشست در کوکی | توکن امضاشده‌ای که اطلاعات کاربر و زمان انقضا را دارد |
| جایی که وضعیت ورود ذخیره می‌شود | روی سرور، در پایگاه داده یا یک انبار | داخل خود توکن |
| خروج کسی از همه جا | آسان: حذف نشست روی سرور | سخت‌تر: توکن تا انقضا معتبر می‌ماند، مگر اینکه فهرست مسدودی نگه دارید |
| کاربرد معمول | برنامه‌های وب سنتی | API ها، برنامه‌های موبایل، سرویس‌هایی که با هم حرف می‌زنند |
برای کوکی‌ها سه تنظیم مهم است: HttpOnly (جاوااسکریپت صفحه نمی‌تواند کوکی را بخواند)، Secure (فقط روی HTTPS فرستاده می‌شود) و SameSite (ارسال آن را در درخواست‌هایی از سایت‌های دیگر محدود می‌کند). ذخیره توکن در localStorage مرورگر رایج است، اما آن را در معرض هر اسکریپتی قرار می‌دهد که در صفحه اجرا شود.
OAuth و «ورود با Google»
OAuth 2.0 استانداردی برای مجوز تفویضی است: به یک برنامه اجازه می‌دهد دسترسی محدودی به حساب شما در سرویس دیگری داشته باشد — مثلاً خواندن تقویم Google شما — بدون اینکه هرگز گذرواژه Google شما را ببیند. به Google هدایت می‌شوید، مجوزهای مشخصی را تأیید می‌کنید (به آن‌ها scope گفته می‌شود)، و Google به برنامه توکنی فقط برای همان مجوزها می‌دهد.
OAuth به‌تنهایی برای دادن دسترسی طراحی شده بود، نه برای گفتن اینکه شما کی هستید. OpenID Connect (OIDC) لایه‌ای روی OAuth 2.0 است که هویت را اضافه می‌کند؛ همان چیزی که «ورود با Google» یا «ورود با Apple» از آن استفاده می‌کند. برای راه‌اندازی، برنامه‌تان را نزد ارائه‌دهنده ثبت می‌کنید و یک client ID و یک client secret می‌گیرید؛ راز روی سرور شما می‌ماند.
یک مثال کامل: ورود به یک پورتال مشتری
فرض کنید پورتالی می‌سازید که در آن مشتری‌های یک آژانس طراحی پروژه‌ها و فاکتورهایشان را می‌بینند.
- احراز هویت: مشتری‌ها با ایمیل و لینک جادویی وارد می‌شوند، پس گذرواژه‌ای برای مدیریت وجود ندارد. کارکنان آژانس با حساب‌های Google Workspace وارد می‌شوند.
- نقش‌ها: هر کاربر یک نقش دارد —
clientیاstaff. - قواعد مجوزدهی:
| عمل | مشتری | کارمند |
|---|---|---|
| دیدن پروژه‌های شرکت خودش | بله | بله |
| دیدن پروژه‌های شرکت‌های دیگر | خیر | بله |
| آپلود فایل در یک پروژه | فقط پروژه‌های خودش | بله |
| علامت‌زدن فاکتور به‌عنوان پرداخت‌شده | خیر | بله |
- جایی که اعمال می‌شود: روی سرور، برای هر درخواست. سرور کاربر واردشده را پیدا می‌کند و فقط پروژه‌هایی را برمی‌گرداند که
project.company_idآن‌ها با شرکت کاربر یکی باشد. پنهان‌کردن دکمه «علامت‌زدن به‌عنوان پرداخت‌شده» کافی نیست — خود نقطه پایانی باید درخواست را رد کند.
توضیح واژه‌های رایج
| واژه | معنی |
|---|---|
| احراز هویت (AuthN) | تأیید اینکه کسی کیست. |
| مجوزدهی (AuthZ) | تعیین اینکه مجاز به چه کارهایی است. |
| نشست (Session) | یادآوری برنامه از اینکه بین درخواست‌ها وارد شده‌اید. |
| کوکی (Cookie) | قطعه کوچکی از داده که مرورگر با هر درخواست به سایت برمی‌گرداند. |
| JWT | JSON Web Token: توکنی امضاشده و فشرده که ادعاهایی مثل شناسه کاربر و انقضا را حمل می‌کند. |
| نقش / مجوز (Role / permission) | برچسب‌هایی مثل admin یا member که دسترسی را تعیین می‌کنند. |
| MFA / 2FA | الزام به یک اثبات دوم، مثل کد برنامه احراز هویت. |
| SSO | ورود یکپارچه: یک ورود (اغلب با حساب شرکتی) برای برنامه‌های زیاد. |
| 401 در برابر 403 | «شما کی هستید؟» (احراز هویت نشده) در برابر «نمی‌توانید این کار را بکنید» (مجوز ندارید). |
اشتباهات و برداشت‌های غلط رایج
- بررسی دسترسی‌ها فقط در صفحه. اگر مرورگر یک دکمه را پنهان کند اما API بررسی نکند، هر کسی می‌تواند مستقیم API را صدا بزند.
- اعتماد به شناسه‌های داخل آدرس.
/invoices/1042باید بررسی کند که فاکتور ۱۰۴۲ متعلق به کاربر واردشده است. - ساختن رمزنگاری شخصی. از کتابخانه‌ها یا ارائه‌دهندگان شناخته‌شده استفاده کنید؛ اجازه ندهید هوش مصنوعی یک طرح هش‌کردن از خودش بسازد.
- بازنشانی ضعیف گذرواژه. لینک‌های بازنشانی باید یک‌بارمصرف باشند، سریع منقضی شوند و نشان ندهند که آیا ایمیلی حساب دارد یا نه.
- قاطی‌کردن ورود خودتان با ورود سازنده‌تان. کاربران برنامه شما جدا از حساب شما در ابزاری هستند که با آن می‌سازید.
- نبود محدودیت نرخ برای ورود. بدون آن، مهاجمان می‌توانند بی‌پایان گذرواژه امتحان کنند.
از سازنده هوش مصنوعی خود چه بخواهید
- «ثبت‌نام و ورود را با [یک کتابخانه یا ارائه‌دهنده شناخته‌شده] اضافه کن. هش‌کردن گذرواژه سفارشی ننویس.»
- «گذرواژه‌ها را با bcrypt یا Argon2 هش‌شده ذخیره کن.»
- «برای نشست از کوکی‌های HttpOnly و Secure استفاده کن.»
- «نقش‌ها را اضافه کن: admin و member. هر نقطه پایانی و اینکه کدام نقش‌ها می‌توانند آن را صدا بزنند را فهرست کن.»
- «روی سرور اعمال کن که کاربران فقط بتوانند رکوردهای خودشان را بخوانند و ویرایش کنند. سپس نشان بده چطور بررسی کردی.»
- «بازنشانی گذرواژه با لینک‌های یک‌بارمصرف که در یک ساعت منقضی می‌شوند اضافه کن.»
- «تلاش‌های ورود را محدود کن (rate limit).»
سپس خودتان آزمایش کنید: دو حساب بسازید و تلاش کنید در حالی که با یکی وارد شده‌اید به داده‌های دیگری برسید. راهنمای افزودن ورود و چک‌لیست امنیتی را هم ببینید.
احراز هویت در Mythex
Mythex یک محصول احراز هویت داخلی برای کاربران برنامه شما ارائه نمی‌دهد؛ شما یک روش را انتخاب می‌کنید — ایمیل و گذرواژه ذخیره‌شده در پایگاه داده پروژه، یا SDK یک ارائه‌دهنده میزبانی‌شده — و از عامل می‌خواهید آن را اضافه کند. کلیدهای ارائه‌دهنده در رازهای پروژه قرار می‌گیرند، نه در گفت‌وگو. این موضوع جدا از روشی است که با آن خودِ Mythex را وارد می‌شوید. دستور آماده در بخش افزودن ورود به برنامه مستندات، یک پرامپت شروع دارد که می‌توانید تطبیقش دهید، و API چیست توضیح می‌دهد که این بررسی‌های سمت سرور کجا قرار دارند.
پرسش‌ها
تفاوت احراز هویت (authentication) و مجوزدهی (authorization) چیست؟
احراز هویت بررسی می‌کند شما کی هستید، مثلاً با تأیید گذرواژه‌تان. مجوزدهی تصمیم می‌گیرد پس از شناخته‌شدن، مجاز به انجام چه کارهایی هستید، مثلاً اینکه آیا می‌توانید صفحه مدیریت را ببینید یا رزرو شخص دیگری را ویرایش کنید. برنامه‌ها به هر دو نیاز دارند.
OAuth چیست؟
OAuth 2.0 یک استاندارد است که به یک برنامه اجازه می‌دهد دسترسی محدودی به حساب شما در سرویس دیگری داشته باشد، بدون اینکه گذرواژه شما را ببیند. «ورود با Google» از OpenID Connect استفاده می‌کند، یک لایه هویت که روی OAuth 2.0 ساخته شده، بنابراین برنامه از Google می‌فهمد شما کی هستید.
آیا برنامه من باید گذرواژه‌ها را ذخیره کند؟
هرگز به شکل قابل‌خواندن. اگر ورود با ایمیل و گذرواژه دارید، گذرواژه‌ها باید به‌صورت هش نمکی (salted hash) ذخیره شوند که با یک الگوریتم کند و مخصوص گذرواژه ساخته شده باشد، مثل Argon2 یا bcrypt. بسیاری از برنامه‌ها با استفاده از یک سرویس احراز هویت میزبانی‌شده، ورود با شبکه‌های اجتماعی یا لینک‌های جادویی ایمیلی از این مسئله دوری می‌کنند.
برنامه من باید از نشست یا توکن استفاده کند؟
هر دو کار می‌کنند. نشست وضعیت ورود را روی سرور ذخیره می‌کند و یک شناسه تصادفی در کوکی به مرورگر می‌دهد که لغو کردنش آسان است. توکنی مثل JWT خودش اطلاعات امضاشده را حمل می‌کند؛ این برای API ها و کلاینت‌های موبایل مناسب است، اما پیش از انقضا لغوش سخت‌تر است. برای یک برنامه وب معمولی، نشست مبتنی بر کوکی انتخاب مطمئنی است.