OAuth 2.0 چیست؟

OAuth 2.0 (مخفف Open Authorization 2.0) یک پروتکل و چارچوب استاندارد باز برای مدیریت دسترسی و مجوزها (Authorization) در بستر وب و APIها است. این پروتکل به برنامه‌ها یا وب‌سایت‌های ثالث (Client) اجازه می‌دهد بدون دریافت نام‌کاربری و رمز عبور اصلی کاربر، و تنها از طریق توکن‌های امن موقت (مانند Access Token)، به منابع مجاز او در یک سرور دیگر دسترسی داشته باشند. هدف اصلی OAuth 2.0، تفکیک لایه احراز هویت (Authentication) از لایه دسترسی (Authorization) و جلوگیری از افشای اطلاعات حساس کاربران است.

مقدمه

اگر امروز از شما بخواهند رمز عبور حساب گوگل خود را به یک برنامه ناشناس بدهید، احتمالاً بدون فکر کردن پاسخ می‌دهید:

«هرگز!»

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

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

این روش نه تنها ناامن بود، بلکه هیچ راهی برای محدود کردن دسترسی برنامه‌ها وجود نداشت. یا باید رمز عبور را می‌دادید یا اصلاً نمی‌توانستید از آن سرویس استفاده کنید.

امروزه تقریباً تمام سرویس‌های بزرگ دنیا مانند گوگل، مایکروسافت، GitHub، Spotify، Discord، Facebook، LinkedIn و هزاران سرویس دیگر از راهکار بسیار امن‌تری استفاده می‌کنند.

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

• ورود با Google
• ورود با GitHub
• ورود با Microsoft
• ورود با Facebook

شاید تصور کنید با کلیک روی این دکمه‌ها، وب‌سایت مقصد رمز عبور گوگل شما را دریافت می‌کند؛ اما حقیقت دقیقاً برعکس است.

هیچ‌وقت رمز عبور گوگل شما در اختیار آن وب‌سایت قرار نمی‌گیرد.

در واقع فناوری‌ای به نام OAuth 2.0 باعث می‌شود بدون اینکه رمز عبورتان را فاش کنید، فقط مجوز مشخصی برای دسترسی به اطلاعات موردنیاز صادر شود.

جالب‌تر اینکه بسیاری از برنامه‌نویسان نیز تصور می‌کنند OAuth 2.0 یک سیستم ورود کاربران یا Authentication است؛ در حالی که این تصور کاملاً اشتباه است.

OAuth 2.0 اصلاً برای احراز هویت طراحی نشده است.

هدف اصلی آن مجوزدهی (Authorization) است؛ یعنی مشخص کردن اینکه یک برنامه دقیقاً به چه بخش‌هایی از اطلاعات شما اجازه دسترسی داشته باشد.

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

در این مقاله قرار نیست فقط چند تعریف حفظی بخوانید؛ بلکه قدم‌به‌قدم یاد می‌گیریم OAuth 2.0 چگونه کار می‌کند، چرا به وجود آمد، چه مشکلاتی را حل کرده است و در چه شرایطی باید از آن استفاده کنیم.

OAuth 2.0 چیست؟

OAuth 2.0 یک استاندارد جهانی برای اعطای مجوز دسترسی (Authorization Framework) است که به یک برنامه اجازه می‌دهد بدون دریافت رمز عبور کاربر، به بخش مشخصی از اطلاعات یا سرویس‌های او دسترسی پیدا کند.

به زبان ساده، OAuth 2.0 مانند یک کارت دسترسی موقت عمل می‌کند.

فرض کنید شما در یک شرکت بزرگ کار می‌کنید. برای ورود به ساختمان، لازم نیست کلید تمام اتاق‌ها را داشته باشید. مدیر شرکت فقط کارتی در اختیار شما قرار می‌دهد که اجازه ورود به بخش‌هایی را دارد که برای انجام وظیفه‌تان لازم است.

اگر روزی دیگر در آن شرکت کار نکنید، کافی است همان کارت غیرفعال شود؛ نیازی نیست تمام قفل‌های ساختمان تعویض شوند.

OAuth نیز دقیقاً همین ایده را در دنیای نرم‌افزار پیاده‌سازی می‌کند.

به جای اینکه کاربر رمز عبور اصلی خود را در اختیار هر برنامه‌ای قرار دهد، یک توکن دسترسی (Access Token) دریافت می‌کند که تنها مجوزهای مشخصی دارد.

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

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

چرا OAuth 2.0 به وجود آمد؟

برای درک اهمیت OAuth باید کمی به گذشته برگردیم.

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

فرض کنید برنامه‌ای برای مدیریت ایمیل‌ها طراحی کرده‌اید.

کاربر مجبور بود چنین اطلاعاتی را وارد کند:

• آدرس ایمیل
• رمز عبور اصلی حساب

برنامه نیز این اطلاعات را ذخیره می‌کرد و هر زمان لازم بود، با همان رمز عبور به سرور ایمیل متصل می‌شد.

در نگاه اول شاید این روش ساده به نظر برسد، اما مشکلات امنیتی بسیار بزرگی داشت.

مشکل اول: افشای رمز عبور

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

در بسیاری از موارد کاربران از یک رمز عبور برای چندین سرویس مختلف استفاده می‌کنند. بنابراین افشای رمز عبور فقط یک سرویس را تحت تأثیر قرار نمی‌داد؛ بلکه ممکن بود تمام حساب‌های کاربر در خطر قرار بگیرند.

مشکل دوم: دسترسی نامحدود

وقتی رمز عبور در اختیار برنامه قرار می‌گرفت، آن برنامه دقیقاً همان سطح دسترسی‌ای را داشت که خود کاربر داشت.

یعنی اگر کاربر می‌توانست ایمیل حذف کند، برنامه هم می‌توانست.

اگر کاربر می‌توانست رمز عبور را تغییر دهد، برنامه نیز قادر به انجام آن بود.

هیچ محدودیتی وجود نداشت.

مشکل سوم: عدم امکان لغو دسترسی

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

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

اما با تغییر رمز عبور، تمام دستگاه‌ها، موبایل‌ها، لپ‌تاپ‌ها و برنامه‌های دیگر نیز از حساب خارج می‌شدند و باید دوباره وارد می‌شدید.

این کار هم زمان‌بر بود و هم تجربه کاربری بسیار بدی ایجاد می‌کرد.

مشکل چهارم: اعتماد کامل به برنامه‌های شخص ثالث

در گذشته کاربران مجبور بودند کاملاً به توسعه‌دهندگان اعتماد کنند.

اگر توسعه‌دهنده تصمیم می‌گرفت رمز عبور را ذخیره کند، نسخه پشتیبان بگیرد یا حتی آن را در اختیار شخص دیگری قرار دهد، کاربر هیچ کنترلی روی این موضوع نداشت.

امروزه چنین روشی از دیدگاه امنیت سایبری کاملاً غیرقابل قبول محسوب می‌شود.

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

نتیجه این تلاش‌ها استانداردی بود که امروزه با نام OAuth 2.0 شناخته می‌شود.

این استاندارد نه تنها امنیت کاربران را به شکل چشمگیری افزایش داد، بلکه تجربه کاربری را نیز بسیار ساده‌تر کرد.

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

Authentication چیست؟

قبل از اینکه بتوانید OAuth 2.0 را به‌طور کامل درک کنید، باید دو مفهوم بسیار مهم را از هم تفکیک کنید؛ مفاهیمی که حتی بسیاری از برنامه‌نویسان باتجربه نیز گاهی آن‌ها را با یکدیگر اشتباه می‌گیرند.

اولین مفهوم، احراز هویت (Authentication) است.

احراز هویت یعنی اثبات اینکه شما همان فردی هستید که ادعا می‌کنید.

به بیان ساده، سیستم از شما یک سؤال می‌پرسد:

«شما چه کسی هستید؟»

برای پاسخ به این سؤال باید مدرکی ارائه دهید که هویت شما را اثبات کند. این مدرک می‌تواند یکی از موارد زیر باشد:

• نام کاربری و رمز عبور
• کد تأیید پیامکی (OTP)
• اثر انگشت
• تشخیص چهره
• کلید امنیتی (Security Key)
• یا ترکیبی از چند روش امنیتی (احراز هویت چندمرحله‌ای)

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

یک مثال ساده از دنیای واقعی

فرض کنید قصد دارید وارد یک فرودگاه شوید.

قبل از اینکه اجازه سوار شدن به هواپیما را داشته باشید، مأمور کنترل گذرنامه از شما کارت ملی یا پاسپورت درخواست می‌کند.

در این مرحله، او اصلاً کاری ندارد که مقصد شما کجاست یا چه امکاناتی قرار است در اختیار شما باشد.

تنها موضوعی که بررسی می‌کند این است:

آیا این شخص واقعاً همان فردی است که نامش روی بلیت ثبت شده است؟

اگر پاسخ مثبت باشد، فرآیند احراز هویت با موفقیت انجام شده است.

Authentication در وب‌سایت‌ها چگونه انجام می‌شود؟

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

معمولاً مراحل زیر انجام می‌شود:

1. آدرس ایمیل خود را وارد می‌کنید.
2. رمز عبور را وارد می‌کنید.
3. اگر احراز هویت دومرحله‌ای فعال باشد، کد ارسال‌شده به موبایل یا برنامه Google Authenticator را نیز وارد می‌کنید.

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

در همین لحظه فرآیند احراز هویت (Authentication) به پایان می‌رسد.

اما هنوز یک سؤال مهم باقی مانده است.

آیا این کاربر اجازه حذف فایل‌های Google Drive را دارد؟

آیا می‌تواند اطلاعات سایر کاربران را مشاهده کند؟

آیا مدیر سیستم است یا فقط یک کاربر عادی؟

پاسخ این سؤال‌ها دیگر به Authentication مربوط نمی‌شود؛ بلکه وارد مرحله دیگری به نام Authorization می‌شویم.

Authorization چیست؟

Authorization یا مجوزدهی مرحله‌ای است که پس از احراز هویت انجام می‌شود.

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

«شما چه کسی هستید؟»

بلکه سؤال اصلی این است:

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

به عبارت دیگر:

احراز هویت مشخص می‌کند چه کسی هستید و مجوزدهی مشخص می‌کند چه کارهایی می‌توانید انجام دهید.

یک مثال از ساختمان اداری

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

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

این مرحله همان Authentication است.

پس از ورود، کارت دسترسی شما توسط دستگاه کنترل می‌شود.

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

یا شاید بتوانید وارد اتاق توسعه نرم‌افزار شوید اما اجازه ورود به اتاق سرور یا بخش مالی را نداشته باشید.

در اینجا دیگر هویت شما تأیید شده است؛ اکنون فقط سطح دسترسی شما بررسی می‌شود.

این دقیقاً همان مفهوم Authorization است.

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

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

کاربر اول مدیر سایت است.

او می‌تواند:

1. محصولات را حذف کند.
2. کاربران را مدیریت کند.
3. تنظیمات سایت را تغییر دهد.
4. گزارش‌های مالی را مشاهده کند.

کاربر دوم اپراتور فروش است.

او اجازه دارد:

• سفارش‌ها را ثبت کند.
• وضعیت سفارش را تغییر دهد.
• با مشتریان ارتباط برقرار کند.

اما اجازه حذف کاربران یا تغییر تنظیمات اصلی سایت را ندارد.

کاربر سوم نویسنده محتوا است.

او فقط می‌تواند:

• مقاله جدید منتشر کند.
• مقاله‌های قبلی را ویرایش کند.

اما حتی اجازه مشاهده اطلاعات سفارش‌های مشتریان را هم ندارد.

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

یعنی فرآیند Authentication برای هر سه انجام شده است.

اما سطح دسترسی هر کدام با دیگری تفاوت دارد.

این تفاوت همان Authorization است.

تفاوت Authentication و Authorization

به دلیل شباهت ظاهری این دو اصطلاح، افراد زیادی آن‌ها را با هم اشتباه می‌گیرند.

در حالی که تفاوت آن‌ها بسیار ساده است.

Authentication (احراز هویت) یعنی:

• بررسی هویت کاربر
• تأیید اینکه کاربر واقعاً همان فرد ادعاشده است
• انجام این مرحله قبل از ورود به سیستم

در مقابل، Authorization (مجوزدهی) یعنی:

• تعیین سطح دسترسی کاربر
• مشخص کردن عملیات مجاز پس از ورود
• کنترل اینکه کاربر به چه اطلاعات یا امکاناتی دسترسی داشته باشد

اگر بخواهیم این تفاوت را تنها در یک جمله خلاصه کنیم:

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

ارتباط OAuth 2.0 با Authentication و Authorization

همان‌طور که در ابتدای مقاله اشاره کردیم، یکی از رایج‌ترین باورهای اشتباه درباره OAuth 2.0 این است که بسیاری از افراد تصور می‌کنند این استاندارد برای ورود کاربران طراحی شده است.

اما حقیقت این است که OAuth 2.0 یک سیستم احراز هویت نیست.

OAuth 2.0 یک چارچوب مجوزدهی (Authorization Framework) است.

یعنی وظیفه اصلی آن این نیست که هویت کاربر را تأیید کند، بلکه تعیین می‌کند یک برنامه دقیقاً به چه بخش‌هایی از اطلاعات کاربر دسترسی داشته باشد.

فرض کنید روی دکمه «ورود با گوگل» کلیک می‌کنید.

در پشت صحنه، دو فرآیند مستقل اتفاق می‌افتد:

1. ابتدا گوگل هویت شما را بررسی و تأیید می‌کند. (Authentication)
2. سپس از شما می‌پرسد آیا اجازه می‌دهید این وب‌سایت به اطلاعات مشخصی از حساب گوگل شما دسترسی داشته باشد یا خیر. (Authorization)

به همین دلیل است که معمولاً صفحه‌ای مانند موارد زیر را مشاهده می‌کنید:

• دسترسی به آدرس ایمیل
• دسترسی به نام و تصویر پروفایل
• دسترسی به تقویم
• دسترسی به فایل‌های Google Drive

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

دقیقاً همین موضوع، OAuth 2.0 را به یکی از مهم‌ترین استانداردهای امنیتی اینترنت تبدیل کرده است.

سناریوهای عملی پیاده‌سازی (Use Cases)

برای درک بهتر رفتار OAuth 2.0 در دنیای واقعی، سه سناریوی متداول صنعتی را بررسی می‌کنیم:

سناریوی اول: برنامه‌های Single Page (SPA) مثل React یا Angular

در برنامه‌های SPA، به دلیل اجرای سورس کد در مرورگر کاربر، ذخیره‌سازی Client Secret ممکن نیست.

• فلوی مناسب: Authorization Code همراه با PKCE.

• چالش امنیت: ذخیره توکن در localStorage یا sessionStorage برنامه را در برابر حملات XSS (Cross-Site Scripting) آسیب‌پذیر می‌کند.

• راهکار استاندارد (BFF Pattern): استفاده از الگوی Backend-For-Frontend. در این الگو، یک لایه سروری کوچک (Node.js یا ASP.NET Core) بین SPA و Identity Provider قرار می‌گیرد. توکن‌ها در سرور نگهداری شده و با مرورگر کاربر از طریق Cookieهای HttpOnly و SameSite=Strict ارتباط برقرار می‌شود.

سناریوی دوم: اپلیکیشن‌های موبایل (Native iOS / Android)

در اپلیکیشن‌های موبایل نیز به دلیل امکان Decompile شدن فایل APK/IPA، کلاینت از نوع Public محسوب می‌شود.

• فلوی مناسب: Authorization Code + PKCE.

• مکانیزم اجرا: باز کردن مرورگر سیستم (System Browser یا Custom Tabs) برای هدایت کاربر به صفحه لاگین، تا اپلیکیشن موبایل نتواند نام‌کاربری و پسورد کاربر را به صورت مستقیم ببیند یا کی‌لاگ (Keylog) کند.

سناریوی سوم: ارتباطات Microservices (Server-to-Server)

زمانی که دو سرویس متوالی در پس‌زمینه بدون حضور مستقیم کاربر نیاز به تبادل داده دارند (مثلاً سرویس صورت‌حساب که باید با سرویس انبارداری صحبت کند).

• فلوی مناسب: Client Credentials Grant.

• نحوه احراز هویت: سرویس مبدأ با ارسال client_id و client_secret خود به سرور Authorization، یک Access Token ویژه سرویس دریافت کرده و درخواست را به سرویس مقصد می‌فرستد.

نحوه Validation و بررسی صحت توکن‌ها در Resource Server

وقتی کلاینت درخواست خود را همراه با Access Token به فرمت JWT می‌فرستد، Resource Server باید قبل از پاسخ‌دهی، توکن را صحت‌سنجی کند. این فرآیند به دو روش انجام می‌شود:

روش اول: بررسی محلی (Local Validation / Stateless)

در این روش، Resource Server کلید عمومی (Public Key) سرور Authorization را از طریق آدرس JWKS (JSON Web Key Set) دریافت و Cache می‌کند. سپس بدون هیچ ارتباط شبکه‌ای اضافی:

1. امضای دیجیتال (Signature) توکن را با کلید عمومی چک می‌کند.

2. تاریخ انقضا (exp) را با زمان جاری سرور مقایسه می‌کند.

3. صادرکننده (iss) و گیرنده مجاز (aud) را اعتبارپذیری می‌کند.

روش دوم: Token Introspection (Stateful Validation)

اگر توکن‌ها از نوع JWT نباشند یا امکان ابطال آنی (Instant Revocation) مد نظر باشد، Resource Server در هر درخواست، توکن را به Endpoint ویژه /introspect روی سرور Authorization می‌فرستد و استعلام می‌گیرد:

POST /introspect HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic Y2xpZW50OmluZ3NlY3JldA==

token=ACCESS_TOKEN_TO_CHECK

پاسخ سرور:

{
  "active": true,
  "scope": "read:profile write:orders",
  "client_id": "mobile-app-123",
  "username": "hamid_imani",
  "exp": 1786098000
}

مدیریت توکن‌های منقضی‌شده و الگوی Refresh Token Rotation

استفاده از Refresh Tokenها اگرچه تجربه کاربری روانی ایجاد می‌کند، اما در صورت سرقت، ریسک امنیتی بالایی دارد. برای حل این مشکل، الگوی Refresh Token Rotation در OAuth 2.1 الزامی شده است:

• هر بار که کلاینت یک Refresh Token را برای دریافت Access Token جدید ارسال می‌کند، سرور Authorization علاوه بر Access Token جدید، یک Refresh Token جدید نیز صادر کرده و Refresh Token قبلی را ابطال می‌کند.

• مکانیزم کشف سرقت (Reuse Detection): اگر یک Refresh Token ابطال‌شده مجدداً توسط هکر به سرور فرستاده شود، سرور متوجه افشای توکن شده و تمام توکن‌های صادرشده برای آن خانواده (Family) و کاربر را فوراً باطل می‌کند.

مقایسه OAuth 2.0 با سایر استانداردهای امنیتی

// Program.cs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = "https://identity.imaninova.ir"; // Authorization Server
        options.Audience = "api_imaninova"; // Resource Indicator
        
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ClockSkew = TimeSpan.Zero // حذف تلورانس زمانی خطای انقضا
        };
    });

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("RequireReadProfile", policy =>
        policy.RequireClaim("scope", "read:profile"));
});