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

چرا به یک پروتکل مجوزدهی نیاز داریم؟

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

چهار نقش اصلی در ساختار OAuth

استاندارد RFC 6749 چهار نقش اصلی تعریف می کند. Resource Owner معمولا همان کاربری است که اختیار داده ها را دارد. Client برنامه ای است که می خواهد از طرف کاربر به آن داده ها دسترسی پیدا کند. Authorization Server درخواست مجوز را پردازش و توکن صادر می کند. Resource Server نیز API یا منبعی است که اطلاعات محافظت شده را نگهداری می کند.
برای مثال، در اتصال یک اپلیکیشن به تقویم، کاربر صاحب داده است، اپلیکیشن نقش Client دارد و سرویس گوگل صدور مجوز و ارائه اطلاعات تقویم را مدیریت می کند.

مراحل دریافت مجوز چگونه انجام می شود؟

در جریان متداول Authorization Code، برنامه ابتدا کاربر را به صفحه مجوز سرویس اصلی هدایت می کند. کاربر در همان سرویس وارد حساب می شود و دسترسی های درخواست شده را بررسی می کند. پس از تایید، سرور مجوز یک Authorization Code کوتاه عمر را به آدرس بازگشت ثبت شده ارسال می کند.
برنامه این کد را از طریق Token Endpoint با Access Token مبادله می کند و سپس با همان توکن درخواست خود را به API می فرستد. Resource Server اعتبار توکن و سطح مجوز را بررسی می کند و فقط در صورت مجاز بودن پاسخ می دهد.

Access Token دقیقا چیست؟

Access Token یک اعتبارنامه دیجیتال است که نشان می دهد برنامه برای دسترسی مشخصی مجوز دارد. معمولا زمان اعتبار آن محدود است و سرویس دریافت کننده باید بررسی کند برای کدام منبع و عملیات صادر شده است. برنامه می تواند هنگام فراخوانی API، توکن را در هدر Authorization: Bearer ارسال کند.
هر Access Token لزوما JWT نیست. بعضی توکن ها رشته هایی هستند که معنای داخلی آن ها فقط برای سرور شناخته شده است. در توکن های Bearer، هر کسی که به مقدار معتبر توکن دسترسی پیدا کند ممکن است بتواند از آن استفاده کند؛ بنابراین محافظت از آن هنگام ذخیره سازی و انتقال ضروری است.

Refresh Token چه تفاوتی با Access Token دارد؟

توکن دسترسی معمولا عمر کوتاهی دارد تا پیامد افشای آن محدود شود. Refresh Token در بعضی جریان ها صادر می شود تا برنامه بدون درخواست ورود دوباره از کاربر، توکن دسترسی تازه بگیرد. البته صدور این توکن اجباری نیست و به سیاست سرویس بستگی دارد.
Refresh Token به دلیل توانایی دریافت دسترسی جدید، بسیار حساس است. برنامه نباید آن را در لاگ یا مکان ناامن ذخیره کند. استفاده از Rotation یا محدود کردن توکن به یک Client می تواند خطر سوء استفاده را کاهش دهد.

Scope چگونه سطح دسترسی را محدود می کند؟

Scope نام مجوزهایی است که برنامه درخواست می کند. برای مثال، یک برنامه ممکن است فقط اجازه خواندن رویدادها را بخواهد و نیازی به حذف یا ویرایش آن ها نداشته باشد. سرور می تواند همین سطح محدود را صادر کند یا درخواست بیش از حد گسترده را نپذیرد.
اصل Least Privilege می گوید هر برنامه باید فقط حداقل دسترسی ضروری را دریافت کند. اگر ابزار فقط گزارش تهیه می کند، درخواست مجوز نوشتن اطلاعات منطقی نیست. Scope به تنهایی کافی نیست و API نیز باید مجوز هر عملیات را بررسی کند.

PKCE چیست و چرا اهمیت دارد؟

PKCE مخفف Proof Key for Code Exchange است و برای محافظت از Authorization Code طراحی شده است. Client پیش از شروع فرآیند، یک مقدار تصادفی به نام Code Verifier می سازد و نسخه مشتق شده آن را به عنوان Code Challenge به سرور ارسال می کند. هنگام دریافت توکن، باید مقدار اصلی را ارائه دهد تا سرور ارتباط دو مرحله را تایید کند.
به این ترتیب، اگر مهاجم فقط کد بازگشت را به دست آورد، نمی تواند به سادگی آن را به توکن تبدیل کند. مطابق RFC 9700، استفاده از PKCE برای Clientهای عمومی الزامی و برای Clientهای محرمانه توصیه شده است.

OAuth چه تفاوتی با احراز هویت دارد؟

مجوزدهی مشخص می کند یک برنامه اجازه انجام چه کاری را دارد، اما احراز هویت مشخص می کند کاربر چه کسی است. پروتکل مجوزدهی OAuth 2.0 به خودی خود یک استاندارد ورود کاربر نیست. بنابراین نباید صرفا با دریافت Access Token نتیجه گرفت که هویت شخص به درستی تایید شده است.
برای قابلیت هایی مانند «ورود با گوگل»، معمولا از OpenID Connect استفاده می شود. این استاندارد یک لایه هویتی روی OAuth قرار می دهد و از ID Token برای انتقال اطلاعات تاییدشده درباره ورود کاربر بهره می برد.

Grant Typeهای مهم کدام هستند؟

Authorization Code همراه PKCE انتخاب معمول برای برنامه هایی است که کاربر در آن ها حضور دارد. در مقابل، Client Credentials برای ارتباط میان سرویس ها کاربرد دارد؛ مثلا یک سرویس Backend می خواهد به API داخلی دیگری با هویت خودش متصل شود. در این حالت معمولا کاربری وجود ندارد که صفحه تایید مجوز را مشاهده کند.
دو روش قدیمی Implicit Grant و Password Grant در استاندارد اولیه معرفی شدند، اما توصیه های امنیتی جدید استفاده از آن ها را کنار گذاشته اند. Password Grant به برنامه نیازمند رمز عبور واقعی کاربر است و خطر افشای اطلاعات را افزایش می دهد.

کاربرد در APIها، میکروسرویس‌ها و ایجنت‌ها

در یک نرم افزار سازمانی، ممکن است CRM بخواهد رویدادهای تقویم را بخواند یا یک سیستم گزارش گیری به داده های مجاز فروشگاه دسترسی پیدا کند. چارچوب مجوزدهی کمک می کند هر اتصال فقط به عملیات مورد نیاز خود دسترسی داشته باشد. در معماری میکروسرویس نیز می توان اعتبار ارتباط میان سرویس ها را با توکن های مناسب مدیریت کرد.
در ایجنت های هوش مصنوعی اهمیت این موضوع بیشتر می شود. یک Agent ممکن است به ایمیل، فایل یا ابزار مدیریت پروژه متصل شود. توسعه دهنده باید مشخص کند Agent چه داده هایی را می تواند بخواند و چه اقداماتی به تایید کاربر نیاز دارند.

اشتباهات امنیتی رایج در پیاده سازی

یکی از خطاهای خطرناک، پذیرش Redirect URI دلخواه است. آدرس بازگشت باید با مقدار ثبت شده تطبیق دقیق داشته باشد تا کد مجوز به مقصد غیرمجاز ارسال نشود. استفاده از HTTPS، نگهداری امن توکن ها و بررسی مقدار state متناسب با جریان نیز برای جلوگیری از حملات مختلف اهمیت دارند.
همچنین نباید توکن ها را در آدرس های عمومی، لاگ ها یا کد سمت کاربر به شکلی افشا کرد که امکان سرقت آن ها فراهم شود. API باید اعتبار، زمان انقضا، مخاطب و Scope توکن را بررسی کند.

برای شروع پیاده سازی از کجا اقدام کنیم؟

ابتدا باید سرویس ارائه دهنده مجوز و نوع Client مشخص شود. سپس برنامه را نزد آن سرویس ثبت می کنی و Client ID و Redirect URI معتبر دریافت می کنی. برای برنامه هایی که امکان نگهداری امن Secret ندارند، نباید Client Secret را محرمانه فرض کرد.
در مرحله بعد Authorization Code با PKCE را پیاده سازی می کنی، فقط Scopeهای مورد نیاز را درخواست می دهی و اعتبار پاسخ ها را بررسی می کنی. بهتر است از کتابخانه های معتبر و مستندات سرویس استفاده شود، نه اینکه تمام اجزای امنیتی از صفر نوشته شوند.

جمع بندی

این چارچوب استاندارد امکان دسترسی کنترل شده برنامه ها به منابع محافظت شده را فراهم می کند، بدون اینکه لازم باشد کاربر رمز عبور خود را به هر سرویس شخص ثالث بدهد. نقش های مشخص، Access Token، Refresh Token، Scope و جریان Authorization Code اجزای اصلی آن هستند.
برای ساخت اتصال امن، دریافت توکن به تنهایی کافی نیست. استفاده از PKCE، محدود کردن مجوزها، بررسی دقیق Redirect URI و محافظت از توکن ها اهمیت زیادی دارد. همچنین باید مجوزدهی را از احراز هویت جدا دانست و برای ورود کاربران در صورت نیاز از OpenID Connect کمک گرفت.