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

در بسیاری از پروژه‌های وب، دو مفهوم Authentication و Authorization در کنار یکدیگر استفاده می‌شوند؛ به همین دلیل گاهی این دو مفهوم با هم اشتباه گرفته می‌شوند.

اما این دو، دو مسئله کاملاً متفاوت را حل می‌کنند:

Authentication می‌پرسد: «تو چه کسی هستی؟»
Authorization می‌پرسد: «چه کاری اجازه داری انجام بدهی؟»

این تفاوت ساده، یکی از پایه‌های اصلی طراحی سیستم‌های امن و قابل توسعه است.

Authentication چیست؟

Authentication یا احراز هویت، فرآیندی است که سیستم توسط آن هویت یک کاربر را بررسی می‌کند.

برای مثال، وقتی کاربر شماره موبایل خود را وارد می‌کند و یک کد OTP دریافت می‌کند، سیستم در حال تلاش برای اطمینان از این موضوع است که:

«آیا این کاربر واقعاً مالک این شماره موبایل است؟»

روش‌های رایج Authentication شامل موارد زیر هستند:

• شماره موبایل و OTP

• نام کاربری و رمز عبور

• Email و Password

• ورود با Google یا سایر سرویس‌های OAuth

• Passkey

• احراز هویت چندمرحله‌ای یا MFA

یک مثال ساده

فرض کنید وارد یک فروشگاه اینترنتی می‌شوید.

شماره موبایل خود را وارد می‌کنید:

0912xxxxxxx

سپس کد ارسال‌شده را وارد می‌کنید:

483921

اگر کد صحیح باشد، سیستم هویت شما را تأیید می‌کند.

در این مرحله سیستم می‌داند:

User = 1024

یعنی:

این درخواست متعلق به کاربر شماره ۱۰۲۴ است.

اما هنوز مشخص نشده که این کاربر اجازه انجام چه کارهایی را دارد.

اینجا Authorization وارد می‌شود.

Authorization چیست؟

Authorization یا مجوز دسترسی، مشخص می‌کند کاربری که هویتش تأیید شده، به چه منابع و عملیات‌هایی دسترسی دارد.

یعنی سیستم بعد از اینکه فهمید:

«این شخص چه کسی است؟»

بررسی می‌کند:

«این شخص اجازه انجام چه کاری را دارد؟»

برای مثال ممکن است یک سیستم سه کاربر داشته باشد:

کاربرنقشعلیAdminرضاEditorساراCustomer

هر سه نفر ممکن است با موفقیت وارد سیستم شده باشند.

پس هر سه Authenticated هستند.

اما دسترسی آن‌ها یکسان نیست.

مثلاً:

Admin
├── مشاهده کاربران
├── ایجاد کاربر
├── حذف کاربر
├── مدیریت محصولات
└── مشاهده گزارش‌ها

Editor
├── مشاهده محصولات
├── ایجاد محصول
└── ویرایش محصول

Customer
├── مشاهده محصولات
├── افزودن به سبد خرید
└── مشاهده سفارش‌های خودش

بنابراین:

Authentication هویت را مشخص می‌کند.

Authorization سطح دسترسی را مشخص می‌کند.

تفاوت Authentication و Authorization در یک مثال واقعی

فرض کنید وارد پنل مدیریت یک فروشگاه اینترنتی شده‌اید.

ابتدا شماره موبایل و OTP را وارد می‌کنید.

OTP → Verification → Authentication

سیستم متوجه می‌شود که شما کاربر #1024 هستید.

حالا می‌خواهید لیست کاربران سیستم را مشاهده کنید.

در این مرحله سیستم بررسی می‌کند:

User #1024
        ↓
Authenticated?
        ↓
Yes
        ↓
Has permission "users.read"?
        ↓
Yes / No

اگر مجوز لازم را داشته باشید، درخواست اجرا می‌شود.

اگر نداشته باشید:

403 Forbidden

دریافت می‌کنید.

بنابراین ممکن است کاربر وارد سیستم شده باشد، اما اجازه دسترسی به یک بخش خاص را نداشته باشد.

یک تفاوت بسیار مهم: 401 و 403

این دو HTTP Status Code در سیستم‌های احراز هویت و مجوزدهی بسیار مهم هستند.

401 Unauthorized

معمولاً به این معنی است که درخواست، اعتبار هویتی معتبر ندارد.

مثلاً:

Access Token وجود ندارد

یا:

Access Token منقضی شده است

در چنین شرایطی سیستم نمی‌تواند هویت معتبر کاربر را تأیید کند.

403 Forbidden

در این حالت سیستم کاربر را می‌شناسد، اما کاربر اجازه انجام عملیات موردنظر را ندارد.

مثلاً:

User: Editor
Permission: users.delete

کاربر احراز هویت شده است، اما مجوز حذف کاربر را ندارد.

پس:

Authentication → چه کسی هستی؟

Authorization → چه اجازه‌ای داری؟

Authentication و Authorization چگونه در یک سیستم کنار هم قرار می‌گیرند؟

در یک معماری مدرن، جریان معمول می‌تواند چیزی شبیه این باشد:

User
  ↓
Login / OTP
  ↓
Authentication
  ↓
Session / Access Token
  ↓
Request
  ↓
Authentication Check
  ↓
Authorization Check
  ↓
Permission / Role
  ↓
Protected Resource

برای مثال:

GET /api/admin/users

سیستم ابتدا بررسی می‌کند:

مرحله اول

آیا درخواست متعلق به یک کاربر معتبر است؟

Authentication

مرحله دوم

آیا این کاربر اجازه مشاهده کاربران را دارد؟

Authorization

مرحله سوم

اگر هر دو بررسی موفق باشند:

200 OK

در غیر این صورت، درخواست متوقف می‌شود.

نقش Session و Token در این فرآیند چیست؟

یکی از اشتباهات رایج این است که تصور کنیم Token همان Authentication است.

Token خودش Authentication نیست؛ بلکه یکی از ابزارهایی است که سیستم می‌تواند برای حفظ یا انتقال اطلاعات مربوط به وضعیت احراز هویت استفاده کند.

برای مثال در یک معماری مبتنی بر Access Token:

Login
  ↓
Verify Identity
  ↓
Issue Access Token
  ↓
Client
  ↓
API Request
  ↓
Authorization Header

مثلاً:

Authorization: Bearer <access-token>

سرور Token را بررسی می‌کند و از طریق آن متوجه می‌شود درخواست متعلق به چه هویت یا Sessionای است.

بعد از آن می‌تواند وارد مرحله Authorization شود.

آیا داشتن Role به معنی داشتن همه دسترسی‌هاست؟

لزوماً نه.

در سیستم‌های ساده ممکن است Authorization فقط بر اساس Role باشد:

Admin → همه دسترسی‌ها
Editor → دسترسی محدود
Customer → دسترسی عمومی

این مدل با مفهوم RBAC یا:

Role-Based Access Control

شناخته می‌شود.

اما در سیستم‌های بزرگ‌تر، تصمیم‌گیری برای دسترسی می‌تواند به عوامل بیشتری وابسته باشد.

مثلاً:

User Role
+ Department
+ Resource
+ Resource Owner
+ Location
+ Time
+ Action

در این حالت معماری‌های پیچیده‌تری مانند ABAC یا Attribute-Based Access Control می‌توانند مطرح شوند.

برای مثال:

User: Sara
Role: Manager
Department: Finance

Resource: Financial Report
Department: Finance

Action: Read

Result: Allow

در حالی که ممکن است همان کاربر برای یک Resource متعلق به بخش دیگری مجوز نداشته باشد.

Authentication بدون Authorization کافی نیست

فرض کنید یک سیستم فقط Login داشته باشد.

کاربر وارد حساب خود می‌شود و یک Access Token دریافت می‌کند.

اگر APIهای حساس فقط بررسی کنند:

IsAuthenticated = true

ممکن است هر کاربر واردشده بتواند به منابعی دسترسی پیدا کند که نباید.

برای مثال:

DELETE /api/users/152

صرفاً اینکه کاربر Login کرده است، نباید به معنی این باشد که اجازه حذف کاربر را دارد.

سیستم باید بررسی کند:

Authenticated?
        ↓
Yes
        ↓
Authorized?
        ↓
Yes / No

این همان نقطه‌ای است که تفاوت Authentication و Authorization در معماری واقعی اهمیت پیدا می‌کند.

Authorization فقط برای Frontend نیست

یکی از اشتباهات خطرناک در توسعه Frontend این است که تصور کنیم مخفی کردن یک دکمه، یعنی جلوگیری از دسترسی.

مثلاً:

{user.role === "admin" && (
  <DeleteButton />
)}

این کار برای تجربه کاربری مفید است.

اما یک مکانیزم امنیتی محسوب نمی‌شود.

کاربر می‌تواند مستقیماً API را صدا بزند:

DELETE /api/users/152

بنابراین کنترل واقعی دسترسی باید در سمت Server و در نقطه‌ای که Resource محافظت می‌شود، اعمال شود.

Frontend می‌تواند UI را بر اساس Permission تغییر دهد، اما:

منبع حقیقت برای Authorization باید در سمت قابل اعتماد سیستم قرار داشته باشد.

در یک پروژه واقعی چه ساختاری می‌توان داشت؟

فرض کنید یک فروشگاه اینترنتی بزرگ داریم:

Authentication
│
├── Login
├── OTP
├── Session
├── Access Token
└── Refresh Token

Authorization
│
├── Roles
├── Permissions
├── Policies
└── Resource Access

مثلاً:

Roles
├── Super Admin
├── Admin
├── Product Manager
├── Content Manager
└── Customer

و Permissionها:

products.read
products.create
products.update
products.delete

orders.read
orders.update

users.read
users.update
users.delete

در این معماری، Role می‌تواند مجموعه‌ای از Permissionها را در اختیار داشته باشد:

Product Manager
│
├── products.read
├── products.create
└── products.update

در نتیجه تغییر سطح دسترسی یک کاربر، بدون نیاز به تغییر کد بخش‌های مختلف سیستم امکان‌پذیرتر می‌شود.

چرا تفکیک Authentication و Authorization مهم است؟

در پروژه‌های کوچک شاید بتوان این دو مفهوم را ساده پیاده‌سازی کرد.

اما با بزرگ‌تر شدن سیستم، تعداد کاربران، نقش‌ها، سرویس‌ها و منابع افزایش پیدا می‌کند.

مثلاً یک سیستم سازمانی ممکن است داشته باشد:

100,000+ Users
50+ Roles
500+ Permissions
Multiple Applications
Multiple APIs
Multiple Services

در چنین سیستمی اگر Authentication و Authorization به شکل درهم طراحی شوند، مدیریت دسترسی بسیار دشوار می‌شود.

تفکیک این دو مفهوم باعث می‌شود:

• مدیریت کاربران ساده‌تر شود.

• Permissionها قابل کنترل باشند.

• تغییر Roleها بدون تغییر گسترده در کد انجام شود.

• APIها راحت‌تر محافظت شوند.

• دسترسی‌ها قابل Audit باشند.

• معماری سیستم در مقیاس بزرگ قابل توسعه‌تر باشد.

یک مثال نهایی برای درک تفاوت

تصور کنید وارد یک ساختمان اداری می‌شوید.

نگهبان کارت شناسایی شما را بررسی می‌کند.

Authentication

او متوجه می‌شود:

این شخص = کارمند شرکت

اما حالا سیستم کنترل درب بررسی می‌کند که آیا شما اجازه ورود به اتاق سرور را دارید یا نه.

Authorization

ممکن است پاسخ این باشد:

Identity: Verified
Access to Server Room: Denied

یعنی:

هویت شما تأیید شده، اما مجوز ورود به آن بخش را ندارید.

دقیقاً همین منطق در نرم‌افزار نیز وجود دارد.

جمع‌بندی

Authentication و Authorization دو بخش متفاوت اما وابسته در معماری امنیتی سیستم‌ها هستند.

Authentication مشخص می‌کند کاربر چه کسی است:

Who are you?

و Authorization مشخص می‌کند کاربر چه کاری می‌تواند انجام دهد:

What are you allowed to do?

در یک سیستم حرفه‌ای، معمولاً ابتدا هویت کاربر بررسی می‌شود و سپس بر اساس Role، Permission، Policy یا Attributeهای مختلف، دسترسی او به Resource مشخص می‌شود.

بنابراین صرفاً داشتن یک سیستم Login برای ساخت یک سیستم امن کافی نیست.

یک معماری مناسب باید بتواند این دو سؤال را به شکل مستقل پاسخ دهد:

«چه کسی هستی؟»

و سپس:

«حالا که می‌دانم چه کسی هستی، دقیقاً به چه چیزهایی اجازه دسترسی داری؟»

این تفکیک، یکی از پایه‌های مهم طراحی سیستم‌های قابل توسعه و امن است.