بخش 4.1 RFC 8252 جریان مجوز OAuth را برای برنامه های بومی با استفاده از مرورگر توصیف می کند (یعنی عامل کاربر خارجی). در این جریان ، برنامه بومی کد تنظیم را در مرحله 4 با تنظیم URI جهت هدایت به IP loopback دریافت می کند. البته این امر به برنامه بومی نیاز دارد تا پورتانی را در رابط حلقه باز باز کند و ما را به حمله هایی سوق دهد که برنامه های دیگر بتوانند کد مجوز را بدست آورند (مگر اینکه از چیزی مثل PKCE استفاده کنیم).
سیستم ما یک مدل سرویس دهنده سرور است. جایی که مشتری ها ابزارهای مختلف خط فرمان سفارشی و بدون رابط کاربری واقعی هستند. در استقرارهای ما ، همیشه نمی توانیم تضمین کنیم که قادر خواهیم بود یک پورت را به روی loopback باز کنیم (و ما دوست داریم از نگرانی های امنیتی اضافه شده که PKCE به آن خطاب می کند جلوگیری کنیم). ما می خواهیم جریان مورد استفاده خود را کم رنگ کنیم اما می خواهیم مطمئن شویم که در را برای مسائل امنیتی باز نمی گذاریم. در اینجا جریانی است که ما می خواهیم از آن استفاده کنیم:
- ابزار خط فرمان هدف را برای انجام جریان OAuth به سرور برنامه آغاز می کند.
- سرور برنامه یک توکن جلسه در حال پیشرفت و یک مقدار حالت جریان تصادفی جداگانه OAuth تولید می کند
- سرور برنامه هر دو مقدار را در پایگاه داده ذخیره می کند
- سرور برنامه هر دو مقدار را به ابزار خط فرمان می دهد
- ابزار خط فرمان ، عامل کاربر خارجی (به عنوان مثال ، مرورگر) را راه اندازی می کند و فرآیند احراز هویت را در مقابل سرور مجوز با استفاده از مقدار دولت OAuth ارائه شده توسط سرور برنامه
- تأیید اعتبار کاربر
- سرور مجوز هدایت مجدد به سرور برنامه به همراه ارزش دولت
- سرور برنامه کد بازیابی مجوز را بازیابی می کند و آن را در پایگاه داده ذخیره می کند. توکن جلسه در حال پیشرفت و مقدار وضعیت OAuth
- ابزار خط فرمان توکن جلسه در حال پیشرفت را به سرور برنامه ارسال می کند
- سرور کد مجوز را از دیتابیس بازیابی می کند و به گونه ای رفتار می کند که انگار ابزار خط فرمان آن را فراهم کرده است
خارج از پتانسیل سوءاستفاده DoS در ارسال تعداد زیادی از شروع OAuth و پتانسیل ابزار خط فرمان برای شروع مرحله 9 قبل از برنامه سرور مرحله 8 را به اتمام رسانده است ، آیا مسائل امنیتی دیگری وجود دارد که باید نگران باشید؟
