Authentication و Authorization چه تفاوتی دارند؟

در گفت‌وگوی تیم‌ها «امنیت لاگین» اغلب یک سطل است: صفحهٔ ورود، نقش ادمین، توکن، و خطای دسترسی. دو مفهوم جدا داخل این سطل نشسته‌اند. Authentication (AuthN) یعنی تأیید اینکه سوژه همانی است که ادعا می‌کند. Authorization (AuthZ) یعنی تأیید اینکه آن سوژه اجازهٔ انجام عمل یا دیدن منبع مشخص را دارد. قاطی کردن این دو، هم در طراحی API و هم در پیام خطا، آسیب‌پذیری می‌سازد.

OWASP Authentication Cheat Sheet می‌گوید AuthN فرایند تأیید هویت فرد، نهاد یا وب‌سایت با اعتبارسنج‌هایی مثل رمز، اثر انگشت یا توکن امنیتی است. OWASP Authorization Cheat Sheet با ارجاع به NIST می‌گوید Authorization فرایند تأیید این است که عمل یا سرویس درخواست‌شده برای یک موجودیت مشخص تأیید شده؛ و صریح جدا می‌کند از Authentication. کاربر احراز هویت‌شده لزوماً مجاز به همهٔ منابع نیست؛ و بعضی منابع عمومی حتی بدون AuthN مجازند.

این مقاله با مثال فروشگاه، جدول مقایسه، و تفاوت 401 و 403 طبق MDN کمک می‌کند تصمیم طراحی و بازبینی کد — از جمله کد تولیدشده با AI — دقیق‌تر شود.

پاسخ کوتاه

Authentication پاسخ به «کیستی؟» است: لاگین موفق، Session معتبر، یا توکن امضاشده با هویت مشخص. Authorization پاسخ به «اجازه داری این کار را بکنی؟» است: آیا این کاربر می‌تواند سفارش ۱۲۳ را ببیند، تخفیف بزند، یا پنل ادمین را باز کند؟ اولی بدون دومی یعنی هر کاربر لاگین‌شده به دادهٔ دیگران می‌رسد؛ دومی بدون اولی روی منابع خصوصی یعنی کنترل دسترسی روی شن ماسه.

از دید HTTP: 401 یعنی اعتبارنامهٔ معتبر برای احراز هویت ندارید (یا نفرستاده‌اید). 403 یعنی سرور درخواست را فهمیده ولی به‌خاطر منطق مجوز رد کرده؛ دوباره لاگین کردن معمولاً کمکی نمی‌کند مگر نقش عوض شود. MDN این تمایز را صریح نوشته است.

لاگین فقط کارت شناسایی است. کارت شناسایی اجازهٔ ورود به اتاق بایگانی یا صندوق را به‌تنهایی نمی‌دهد.

تعریف‌ها با زبان OWASP

Authentication (AuthN)

طبق Cheat Sheet احراز هویت، شما یک یا چند Authenticator را بررسی می‌کنید تا ادعای هویت معتبر شود. هویت دیجیتال در بستر یک سرویس یکتاست؛ لزوماً به معنای شناخت فرد واقعی در جهان فیزیکی نیست مگر Identity Proofing جداگانه انجام شود. Session Management حالت تعامل بعدی را نگه می‌دارد و باید شناسهٔ نشست یکتا و سخت‌پیش‌بینی باشد — جزئیات در Cheat Sheet مدیریت نشست OWASP.

پیامد عملی: صفحهٔ لاگین، بازیابی رمز، MFA، و صدور Session/Token عمدتاً در دامنهٔ AuthN هستند. OWASP تأکید می‌کند صفحات لاگین و صفحات بعد از احراز هویت باید روی حمل امن (TLS) باشند تا اعتبارنامه و شناسهٔ نشست در مسیر نشت نکند.

Authorization (AuthZ)

Cheat Sheet مجوز می‌گوید حتی بعد از AuthN، کاربر عادی و ادمین دسترسی یکسان ندارند. Broken Access Control در OWASP Top 10:2021 به‌عنوان نگرانی برجسته مطرح شده؛ Cheat Sheet مجوز به همین زمینه و به CWEهای مرتبط با دور زدن کنترل دسترسی اشاره می‌کند. اصول کلیدی که همان سند برجسته می‌کند: حداقل امتیاز (Least Privilege)، Deny by Default، اعتبارسنجی مجوز در هر درخواست، و عدم اتکا به چک سمت‌کلاینت.

مدل‌ها: RBAC (نقش)، ABAC (ویژگی‌ها و سیاست)، ReBAC (رابطه بین موجودیت‌ها). OWASP برای بسیاری از اپ‌ها ABAC/ReBAC را نسبت به RBAC صرف ترجیح مفهومی می‌دهد چون منطق افقی («فقط سفارش خودت») را بهتر بیان می‌کنند؛ با این حال RBAC ساده هنوز نقطهٔ شروع رایج است اگر با چک مالکیت شیء همراه شود.

مثال فروشگاه: لاگین در برابر ادمین

کاربر در فروشگاه ایمیل و رمز می‌دهد و وارد می‌شود — AuthN موفق. حالا سه درخواست:

• دیدن فروشگاه عمومی و صفحهٔ محصول: اغلب بدون AuthN هم مجاز (Authorization برای مهمان).
• دیدن «سفارش‌های من» با id متعلق به خودش: AuthN لازم است و AuthZ باید مالکیت را چک کند.
• باز کردن /admin/refunds یا حذف کاربر دیگر: AuthN لازم است و AuthZ نقش/مجوز ادمین را می‌خواهد.

باگ کلاسیک IDOR: middleware فقط «لاگین هستی؟» را چک می‌کند و GET /orders/901 را برای هر Session معتبر برمی‌گرداند. کاربر B با عوض کردن عدد، سفارش کاربر A را می‌بیند. AuthN سبز است؛ AuthZ شکسته است. OWASP Authorization Cheat Sheet روی کنترل دسترسی شیء‌سطح و خطر کلید کنترل‌شده توسط کاربر هشدار می‌دهد.

401 در برابر 403

MDN برای 401 Unauthorized می‌گوید درخواست به‌خاطر نبود اعتبارنامهٔ احراز هویت معتبر برای منبع موفق نشده و معمولاً با WWW-Authenticate همراه است. برای 403 Forbidden می‌گوید سرور درخواست را فهمیده ولی پردازش را رد کرده؛ برخلاف 401، احراز هویت مجدد معمولاً تفاوتی ایجاد نمی‌کند و شکست به منطق برنامه مثل کمبود مجوز گره خورده است.

نکتهٔ نام‌گذاری: کلمهٔ Unauthorized در 401 از نظر ادبی به «مجوز» نزدیک است، اما در عمل HTTP آن را برای مشکل Authentication به‌کار می‌برد. در API خودتان پیام بدن را شفاف بنویسید («نیاز به ورود» در برابر «نقش ادمین لازم است») تا کلاینت و پشتیبان گیج نشوند. بعضی سامانه‌ها برای پنهان کردن وجود منبع از کاربر بدون مجوز، به‌جای 403 از 404 استفاده می‌کنند؛ MDN این انتخاب را به‌عنوان تصمیم مالک سرور ذکر می‌کند.

جدول AuthN در برابر AuthZ

اشتباه‌های رایج در کد و در Vibe Coding

چک فقط در فرانت: دکمهٔ ادمین مخفی شده ولی API بدون AuthZ مانده است. OWASP می‌گوید کنترل دسترسی تعیین‌کننده باید سمت سرور، gateway یا تابع سرورلس باشد؛ چک کلاینت فقط UX است.

یکی‌گرفتن «authenticated» با «allowed»: میان‌افزار وجود JWT را کافی می‌داند و شناسهٔ مسیر را بدون مالکیت می‌پذیرد. برای هر عمل حساس، روی سرور نقش و مالکیت و شرایط محیطی را دوباره ارزیابی کنید.

پیام خطای لاگین که کاربر را enumerate می‌کند: OWASP AuthN می‌گوید پاسخ‌ها را عمومی نگه دارید («نام کاربری یا رمز نادرست») تا وجود حساب لو نرود. این جدا از AuthZ است ولی در همین لایهٔ هویت زیاد دیده می‌شود.

اتکای صرف به نقش درشت بدون شیء: نقش «کارمند» برای دیدن همهٔ سفارش‌ها زیاده‌روی است. Least Privilege یعنی حداقل لازم افقی و عمودی.

حداقل قواعد طراحی برای تیم

1. منابع را به عمومی، احراز هویت‌شده، و نقش‌دار/مالک‌دار تقسیم کنید و برای هر کدام تست بنویسید.
2. Deny by default: اگر قاعده جور نبود، رد کنید.
3. مجوز را در یک لایهٔ یکپارچه (middleware/policy engine) متمرکز کنید تا یک endpoint جا نماند.
4. برای اشیاء با id حدس‌پذیر، هرگز به مخفی بودن عدد تکیه نکنید؛ مالکیت را چک کنید.
5. رویدادهای شکست AuthN و AuthZ را لاگ کنید بدون ریختن Secret در لاگ.
6. برای عملیات حساس (تغییر ایمیل، پرداخت، ارتقای نقش) باز-احراز هویت یا MFA را از Cheat Sheetها جدی بگیرید.

مرز اعتماد: کجا AuthN تمام می‌شود و AuthZ شروع

بعد از اینکه Identity Provider یا ماژول لاگین شما Session یا Token معتبر ساخت، هر سرویس پایین‌دست باید دو کار کند: اعتبار امضا/نشست را بپذیرد (ادامهٔ اعتماد AuthN) و تصمیم مجوز را برای همان درخواست بگیرد (AuthZ). واگذاری کامل «چون gateway توکن را چک کرد پس همه چیز مجاز است» یعنی حذف لایهٔ دوم. در معماری میکروسرویس، Propagate کردن هویت بدون Propagate کردن زمینهٔ مجوز، همان باگ تکراری است.

منابع عمومی را هم آگاهانه تعریف کنید: صفحهٔ فرود و تصویر محصول ممکن است بدون AuthN مجاز باشند. این استثنا، مجوز است نه «بی‌خیالی». اگر بعداً همان URL دادهٔ خصوصی برگرداند، باید سیاست عوض شود نه اینکه فرض کنید مخفی بودن مسیر کافی است.

مدل نقش در برابر مدل مالکیت

RBAC می‌گوید «ادمین می‌تواند refund کند». مالکیت می‌گوید «کاربر فقط سفارش خودش را می‌بیند». بیشتر محصولات واقعی هر دو را لازم دارند. نقش بدون مالکیت به IDOR می‌انجامد؛ مالکیت بدون نقش، ابزار پشتیبانی و عملیات را فلج می‌کند. ABAC این‌ها را با ویژگی‌هایی مثل سازمان، ساعت، سطح حساسیت داده، و وضعیت آموزش امنیتی غنی می‌کند — هزینهٔ طراحی سیاست بالاتر است اما Least Privilege را واقعی‌تر می‌کند.

در فروشگاه نمونه: نقش customer برای سبد و checkout، نقش support برای دیدن سفارش با دلیل و لاگ، نقش admin برای تنظیمات سیستم. حتی support هم باید محدودیت افقی داشته باشد مگر سیاست صریح بگوید همهٔ سفارش‌ها. تست خودکار برای «کاربر A به B نرسد» ارزان‌ترین تور امنیتی است که تیم کوچک می‌تواند هر PR اجرا کند.

پیام‌ها، UX و امنیت

کاربر عادی باید بفهمد باید وارد شود یا دسترسی ندارد. اما متن و کد وضعیت نباید ابزار enumeration شوند. برای لاگین، پیام عمومی؛ برای API داخلی، کد 401/403 دقیق به کلاینت معتمد. صفحهٔ UI می‌تواند دکمهٔ ادمین را نشان ندهد، ولی API باید همان را رد کند. همسویی UX و AuthZ یعنی کاربر گیج نشود و مهاجم هم از UI به‌عنوان نقشهٔ مجوزها سوءاستفاده نکند.

در رویدادهای پرریسک — تغییر ایمیل، افزودن روش پرداخت، ارتقای نقش — OWASP AuthN باز-احراز هویت را توصیه می‌کند. این هم AuthN است هم کنترل ریسک برای AuthZ: حتی اگر Session دزدیده شده باشد، عمل حساس بدون رمز/MFA پیش نمی‌رود.

چک‌لیست بازبینی یک Pull Request

• آیا endpoint جدید پیش‌فرض رد می‌کند مگر قاعدهٔ صریح؟
• آیا فقط «توکن معتبر» چک شده یا مالکیت/نقش هم؟
• آیا تستی هست که کاربر A به id کاربر B برسد و باید شکست بخورد؟
• آیا پاسخ 401 و 403 درست و بدون نشت اطلاعات اضافه است؟
• آیا UI مخفی‌کاری را با Enforce سرور اشتباه نگرفته؟
• آیا عملیات حساس به باز-احراز هویت یا تأیید دوم نیاز دارد؟

این فهرست را کنار جدول ریسک مقالات Vibe Coding بگذارید: بسیاری از پیشنهادهای AI مسیر خوش‌بینانه را کامل می‌کنند و شاخهٔ «کاربر دیگر» را نمی‌نویسند. بازبین انسان باید صریحاً آن شاخه را بخواهد.

یک تمرین کوتاه برای محصول‌مدیر و توسعه‌دهنده با هم: سه عمل حساس را بنویسید (مثلاً مشاهدهٔ سفارش، صدور بازپرداخت، تغییر نقش). برای هر عمل مشخص کنید چه هویتی لازم است و چه مجوزی. اگر جمله‌ها یکی شدند، هنوز AuthN و AuthZ را جدا نکرده‌اید.

جمع‌بندی برای تصمیم

Authentication هویت را ثابت می‌کند؛ Authorization سقف دسترسی را. فروشگاه بدون این تفکیک یا دادهٔ مشتری را لو می‌دهد یا ادمین جعلی می‌سازد. 401 و 403 را طبق MDN در API رعایت کنید تا کلاینت بتواند درست واکنش نشان دهد. اصول OWASP — حداقل امتیاز، deny-by-default، چک در هر درخواست، عدم اتکا به UI — ترجمهٔ عملی همان تفکیک‌اند.

اگر همین هفته یک کار می‌کنید: یک endpoint با پارامتر id انتخاب کنید و با دو کاربر واقعی تست کنید که آیا کاربر اول به شناسهٔ دوم می‌رسد یا نه. اگر می‌رسد، قبل از هر ویژگی جدید، AuthZ همان مسیر را درست کنید.

برای ادامه، مکانیزم حمل نشست/توکن و خطاهای رایج وب را در مقالات مرتبط بخوانید؛ این صفحه مرز مفهومی است نه جایگزین مدل تهدید کامل برای پرداخت یا دادهٔ سلامت.

منابع و مراجع

• OWASP — Authentication Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• OWASP — Authorization Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
• MDN — 401 Unauthorized — https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401
• MDN — 403 Forbidden — https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403

اگر در بازبینی PR فقط پرسیدید «لاگین دارد؟»، نصف سؤال امنیتی را نپرسیده‌اید؛ بپرسید «برای این id و این نقش، چرا باید اجازه داشته باشد؟».