چگونه جریان کد مجوز OAuth 2.0 رمزهای عبور را از برنامه‌های شخص ثالث ایزوله می‌کند

در اکتبر ۲۰۱۲، کارگروه مهندسی اینترنت (IETF) سند RFC 6749 را منتشر کرد؛ یک سند ۷۶ صفحه‌ای که بی‌سروصدا نحوه مدیریت مجوزها در اینترنت را بازطراحی کرد. پیش از انتشار آن، برنامه‌های شخص ثالث معمولاً از کاربران می‌خواستند نام کاربری و رمز عبور خام خود را فقط برای وارد کردن یک لیست مخاطبین یا همگام‌سازی تقویم در اختیارشان بگذارند. انتشار فریم‌ورک مجوزدهی OAuth 2.0 مکانیزمی را برای «کسب دسترسی محدود به یک سرویس HTTP» بدون افشای اطلاعات هویتی معرفی کرد و آن رویه خطرناک را با سیستم دسترسی نیابتی جایگزین ساخت. این فریم‌ورک با استانداردسازی نحوه درخواست مجوز توسط برنامه‌ها، پایه و اساس وب مدرن و به‌هم‌پیوسته را بنا نهاد.[1]

هسته اصلی این سیستم، جریان کد مجوز (Authorization Code flow) است. وقتی کاربری روی دکمه‌ای کلیک می‌کند تا یک برنامه شخص ثالث را به حساب مایکروسافت یا گوگل خود متصل کند، در واقع دنباله‌ای را آغاز می‌کند که مشخصاً برای پنهان نگه داشتن رمز عبورش از برنامه‌ای که قصد استفاده از آن را دارد، طراحی شده است. این فریم‌ورک با جداسازی فیزیکی برنامه‌ی درخواست‌کننده دسترسی از سروری که هویت کاربر را تأیید می‌کند، به این هدف دست می‌یابد. این جداسازی تضمین می‌کند که برنامه فقط داده‌های خاصی را که درخواست کرده دریافت می‌کند و نه هیچ‌چیز بیشتر.[1][2]

برخلاف آنچه ارائه‌دهندگان هویت در بازاریابی‌های پرزرق‌وبرق خود ادعا می‌کنند، OAuth 2.0 در ذات خود صرفاً یک پروتکل مجوزدهی است، نه یک پروتکل احراز هویت. همان‌طور که مستندات فنی Okta به روشنی بیان می‌کند: «OAuth 2.0 فریم‌ورکی است که مجوز دسترسی به یک منبع محافظت‌شده مانند یک برنامه یا مجموعه‌ای از فایل‌ها را کنترل می‌کند، در حالی که OpenID Connect و SAML هر دو استانداردهای صنعتی برای احراز هویت یکپارچه هستند.» احراز هویت تأیید می‌کند که کاربر واقعاً چه کسی است، در حالی که مجوزدهی تنها تعیین می‌کند یک برنامه اجازه دارد از طرف او چه کاری انجام دهد.

این تمایز اغلب در محصولات نرم‌افزاری تجاری نادیده گرفته می‌شود. شرکت‌ها به طور معمول راهکارهای «ورود با OAuth» را می‌فروشند، اما قابلیت‌های پایه فریم‌ورک OAuth 2.0 هیچ‌گونه اثبات رمزنگاری‌شده‌ای از هویت کاربر ارائه نمی‌دهد. این پروتکل تنها ثابت می‌کند که یک کاربر — هر کسی که می‌خواهد باشد — با موفقیت به یک برنامه اجازه داده تا اقدام خاصی را انجام دهد. تکیه بر OAuth 2.0 به تنهایی برای احراز هویت کاربر، یک خطای معماری بنیادین است که صنعت سال‌ها تلاش کرده تا آن را از طریق لایه‌های پروتکل اضافی اصلاح کند.[4]

جریان کد مجوز زمانی آغاز می‌شود که یک برنامه کلاینت، مرورگر وب کاربر را به نقطه پایانی تعیین‌شده /authorize در سرور مجوزدهی هدایت می‌کند. مستندات Entra مایکروسافت اشاره می‌کند که این درخواست اولیه شامل مجوزهای خاص یا «دامنه‌هایی» است که برنامه می‌خواهد به دست آورد — مانند offline_access یا mail.read. این درخواست همچنین شامل یک URI تغییر مسیر از پیش ثبت‌شده است که به سرور مجوزدهی دقیقاً می‌گوید پس از تکمیل درخواست مجوز، کاربر را به کجا بفرستد. با آغاز درخواست به این شکل، برنامه پیش از تبادل هرگونه داده‌ای، مقاصد خود را به روشنی اعلام می‌کند.[2]

در این مرحله از فرآیند، برنامه کلاینت کاملاً از چرخه خارج می‌شود. کاربر مستقیماً با سرور مجوزدهی — مانند مایکروسافت، گوگل یا یک ارائه‌دهنده هویت سازمانی — تعامل می‌کند تا وارد سیستم شده و مجوزهای درخواستی را بررسی کند. از آنجا که این تعامل منحصراً در دامنه خود سرور مجوزدهی اتفاق می‌افتد، برنامه شخص ثالث هرگز کلیدهای فشرده‌شده توسط کاربر، رمز عبور او یا اعلان احراز هویت چندعاملی را نمی‌بیند. برنامه نسبت به مکانیزم نحوه اثبات هویت کاربر کاملاً نابینا است.[2][5]

هنگامی که سرور مجوزدهی کاربر را تأیید کرد و مطمئن شد که او با دامنه‌های درخواستی موافق است، مرورگر کاربر را با استفاده از URI ارائه‌شده به برنامه کلاینت بازمی‌گرداند. با این حال، سرور در این تغییر مسیر، توکن حساس دسترسی را ارسال نمی‌کند. در عوض، سرور یک رشته موقت و یک‌بار مصرف به نام «کد مجوز» می‌فرستد. این کد اساساً یک سند بدهکاری رمزنگاری‌شده است که نشان‌دهنده رضایت کاربر است اما هیچ دسترسی واقعی به داده‌های او فراهم نمی‌کند. این صرفاً یک نگه‌دارنده است که پیش از دسترسی به هر منبعی باید نقد شود.[3][5]

این واگذاری اولیه از طریق «کانال جلویی» — یعنی مرورگر وب کاربر — انجام می‌شود. از آنجا که تغییر مسیرهای مرورگر می‌توانند توسط افزونه‌های مخرب، شبکه‌های محلی در معرض خطر یا بدافزارهای موجود در دستگاه رهگیری شوند، خود کد مجوز عمداً به تنهایی بی‌فایده طراحی شده است. دستورالعمل‌های پیاده‌سازی Auth0 تأکید می‌کنند که این جریان خاص «تنها می‌تواند برای برنامه‌های محرمانه استفاده شود، زیرا روش‌های احراز هویت برنامه در تبادل گنجانده شده و باید ایمن نگه داشته شوند.» مهاجمی که کد مجوز را می‌دزدد، نمی‌تواند بدون در اختیار داشتن اعتبارنامه‌های خصوصی برنامه از آن استفاده کند.[5]

برای دریافت توکن دسترسی واقعی، برنامه کلاینت یک اتصال مستقیم و سرور-به-سرور با نقطه پایانی /token سرور مجوزدهی باز می‌کند. این اتصال به عنوان «کانال پشتی» شناخته می‌شود. در طول این تبادل، برنامه کد مجوز موقت را به همراه شناسه کلاینت خود و یک رمز کلاینت به شدت محافظت‌شده ارائه می‌دهد. این مرحله هویت خود برنامه را به سرور ثابت می‌کند و تضمین می‌کند نهادی که کد را نقد می‌کند، دقیقاً همان نهادی است که در وهله اول آن را درخواست کرده بود.[3][5]

تنها پس از تأیید اعتبار کد مجوز و اعتبارنامه‌های برنامه کلاینت است که سرور مجوزدهی توکن دسترسی را صادر می‌کند. این توکن یک کلید رمزنگاری است که برنامه می‌تواند از آن برای دسترسی به منابع درخواستی از طرف کاربر استفاده کند. این توکن معمولاً در قالب یک توکن وب جیسون (JWT) قالب‌بندی می‌شود و دارای زمان انقضای دقیقی است — که اغلب به کوتاهی پانزده دقیقه است — تا در صورت به خطر افتادن نهایی توکن، آسیب احتمالی را محدود کند. سرور همچنین ممکن است یک توکن تازه‌سازی صادر کند که به برنامه اجازه می‌دهد بدون مجبور کردن کاربر به ورود مجدد، دسترسی خود را حفظ کند.[1][5]

از آنجا که توکن دسترسی منحصراً از طریق کانال پشتی منتقل می‌شود، هرگز در معرض مرورگر وب کاربر یا محیط دستگاه محلی قرار نمی‌گیرد. این تبادل دو مرحله‌ای — تحویل کد از طریق کانال جلویی و بازیابی توکن از طریق کانال پشتی — دقیقاً همان چیزی است که جریان کد مجوز را برای برنامه‌های سازمانی، پورتال‌های مراقبت‌های بهداشتی و خدمات مالی به اندازه کافی ایمن می‌سازد. این روش حساس‌ترین اعتبارنامه‌ها را از آسیب‌پذیرترین سطوح حمله ایزوله می‌کند و تضمین می‌کند که حتی یک مرورگر وب کاملاً در معرض خطر نیز نمی‌تواند به راحتی کلیدهای رمزنگاری مورد نیاز برای دسترسی به APIهای بک‌اند را فاش کند.[3]

برای پر کردن شکاف همیشگی بین مجوزدهی و احراز هویت، صنعت نرم‌افزار پروتکل OpenID Connect (OIDC) را مستقیماً روی فریم‌ورک OAuth 2.0 بنا کرد. تیم مهندسی Kantega SSO توضیح می‌دهد که OIDC تمام کارهای OAuth را انجام می‌دهد، اما یک لایه هویت استانداردشده را به پاسخ نهایی کانال پشتی اضافه می‌کند. هنگامی که یک برنامه در طول تغییر مسیر اولیه، دامنه openid را درخواست می‌کند، سرور مجوزدهی می‌داند که باید یک توکن شناسه را در کنار توکن دسترسی استاندارد تولید کند. این افزونه، یک پروتکل نمایندگی صرف را به یک راهکار جامع هویت یکپارچه تبدیل می‌کند.[4]

در حالی که توکن دسترسی OAuth 2.0 قرار است توسط یک API بک‌اند مصرف شود، توکن شناسه OIDC برای مصرف توسط خود برنامه کلاینت در نظر گرفته شده است. این توکن شناسه حاوی ادعاهای رمزنگاری‌شده قابل تأیید درباره رویداد احراز هویت است و در نهایت به این سؤال پاسخ می‌دهد که کاربر چه کسی است، نه اینکه برنامه فقط اجازه انجام چه کاری را دارد. این توکن اطلاعات پروفایل کاربر، مانند آدرس ایمیل و زمان دقیق ورود او را در اختیار برنامه قرار می‌دهد.[4]

با ادامه تکامل مدل‌های امنیتی مرورگرها، اتکای صنعت به جریان کد مجوز عمیق‌تر شده است. مکانیزم‌های قدیمی‌تر تعریف‌شده در مشخصات اصلی RFC 6749، مانند جریان ضمنی که توکن‌های دسترسی را مستقیماً از طریق تغییر مسیر مرورگر در کانال جلویی ارسال می‌کرد، اکنون به دلیل خطر شدید نشت و رهگیری توکن، توسط IETF به طور فعال منسوخ شده‌اند. بهترین شیوه‌های امنیتی مدرن دیکته می‌کنند که هیچ اعتبارنامه حساسی هرگز نباید از طریق یک قطعه URL منتقل شود، و بدین ترتیب تبادل در کانال پشتی را به عنوان تنها روش قابل قبول برای بازیابی توکن‌ها تثبیت می‌کنند.[1]

امروزه، جریان کد مجوز به عنوان خط پایه مطلق برای دسترسی نیابتی ایمن در سراسر اینترنت شناخته می‌شود. این پروتکل با اعمال یک مرز معماری دقیق بین ارائه‌دهنده هویتی که رمز عبور را تأیید می‌کند و برنامه شخص ثالثی که داده‌ها را درخواست می‌کند، تضمین می‌سازد که نفوذ به یک برنامه متصل، هویت اصلی کاربر را به خطر نمی‌اندازد. این مکانیزمی است که ایزوله‌سازی را در اولویت قرار می‌دهد و ثابت می‌کند که امن‌ترین راه برای مدیریت رمز عبور کاربر، اطمینان از این است که برنامه هرگز آن را نمی‌بیند.[2][5]